Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Psychology and the Agile Methodology

03.20.2014
| 8995 views |
  • submit to reddit

The core tenants of Agile provide a sound foundation for effectiveness. One of those tenants encourages teams to "fail fast and often." This philosophy is key to rapid development and release cycles. It helps identify areas of success and failure at a faster rate. This allows a team to make small continuous course corrections through a project, helping to avoid major disruptions or mistakes. The concept extends down to the external customer. Smaller, quicker releases allow for faster feedback. This increases feature accuracy while reducing unnecessary development. Another core tenant of Agile is "don't compare teams." Teams under Agile are self organizing. For instance, in Scrum each team designs its own estimating system. In Kanban, teams design their own unique flow and maximum WIPs (work-in-process). Attempting to compare teams is a true apples to oranges analogy.

Failing fast and often is a challenging concept in Agile. It is much easier to state than accomplish. Most individuals have a natural psychological fear of failure. This irrational emotion called Atychiphobia plays a role in life. This fear may inhibit some from embracing Agile. Implementing and encouraging the Agile mindset boils down to buy-in. The facts state that people don't change by force. The decision to change must develop from within. Knowing this, there are ways to help stimulate this process:

  • Complete one-on-one discussions with team members about their feelings towards Agile. Encourage them to be open and do the same.
  • Encourage team members to openly discuss areas of concern and ensure the team finds resolution.
  • Encourage each team member to have a voice and let them know it's being heard. Don't allow discussion bullying.
  • Maintain action-item lists based on discussion resolutions.
  • Provide opportunities for team members to manage steps in the Agile process. This can aid in their understanding.
  • Provide materials to team members about common pitfalls. For instance, the article Embracing the Fear of Failure.

Discouraging correlation between teams is also a difficult Agile concept. Correlation is a part of human nature. For many, its not a conscious part of everyday life. The human brain is hard-wired to find patterns and compare. The Gestalt Principles such as Similarity and Proximity are built on this concept. Implementing new user experience relies heavily on a user's correlation of design constructs. Although comparing teams is frowned upon, comparison within teams is highly encouraged. The estimation process in Scrum relies on comparison to maintain consistency upon judging user story size. The following list contains a few guidelines to help foster proper comparisons:

  • Maintain separate graphs, spreadsheets, and slides between teams. Do not combine statistics between teams into a single report.
  • Be prepared to defend the discouragement of correlation. Individuals will ask why information cannot be combined.
  • Allow each team to determine which metrics they prefer. This will differ from team to team.
  • Identify and call out discussions involving correlation between teams. Open a dialog and actively discuss.
  • Encourage teams to explore and experiment with new team ideas.

Although teams in Agile are self organizing, enforcement of its concepts requires a joint effort among all teams. The fear of failure and lack of comparison create obstacles but they can be overcome. Agile is not an attempt to dehumanize the development process or discourage conversation. Its guidelines exist to protect individuals by protecting the larger process. This foundation provides the opportunity for a higher level of success.

Published at DZone with permission of Zac Gery, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)