In her ongoing Agile Blog Series, Agile Practioner Michele Eichhorn shares her insights, experiences and best practices to Agile success.
Agile development methodologies are a set of approaches to software development that share a common philosophy but are sharply distinguished in the details of their implementations.
Agile development methodologies tend to be adapted to different sorts of problems.
Still, an organization – even a sophisticated one – can get Agile all wrong.
What are the biggest Agile mistakes?
Mistake #1 – Not delighting the client!
Traditional management has not changed significantly over the last 20-30 years, but the client has changed - significantly. A million years ago when I was a desktop engineer, software version updates were approximately every 18 months. New software applications made an appearance about every two years. Now there's hardly a week that goes by when one of our applications does not need an update. And we install the updates ourselves. In the Jurassic period I worked in no one would admit it but the customer's opinion was really inconsequential. They got the software that was developed and it was installed by a technical team - which, by the way, heightened the mystery. That 18 to 24 month development cycle really eliminated the need for customer feedback; who really remembers two years from now what was actually requested. As development cycles decrease, client feedback becomes even more important. So while I may not remember what I asked for two years ago, I’ll certainly remember a request I made last month. Ignoring client feedback and satisfaction is a path you cannot afford follow.
Read Also: 12 Principles of Agile Methodology
Mistake #2 – You do not enable your teams!
This might be the hardest for managers that are used to controlling each aspect of their project and the team. However, putting the control in the hands of the people who have the expertise produces a far superior product. Enablement involves trust but not blind trust. You know the team’s abilities; after all, you chose them. Hopefully you had a hand in selecting your team members. This speaks to hiring well. Teams go through Tuckman’s four stages of group development: Forming, Storming, Norming and Performing. Finally, you need to be patient as this is a learning process. There are no shortcuts.
Mistake #3 – The working environments are not ready!
This seems so simple and intuitive but I cannot tell you how many times I’ve seen teams create their user stories, work to prioritize their backlog, pull stories into the iteration only to find the platforms they must use to conduct their work are not ready. Besides the obvious impact on the work that needs to be completed, the impact to team morale is almost worse. The teams are geared up and ready to go only to come to a screeching halt. Needless to say, you should not proceed with your project until you have the tools required by the teams.
Mistake #4 – You don't fully understand the financial benefit of Agile!
Cost accounting is a process of collecting, analyzing, summarizing and evaluating various alternative courses of action. Its goal is to advise the management on the most appropriate course of action based on cost efficiency and capability with cost efficiency typically taking the form of squeezing out costs, especially labor costs. This form of accounting, while necessary for traditional external reporting, ignores the increase in value to the customer. The speed with which incremental solutions are delivered to the client ensures continuous value-add as opposed to months of traditional waterfall development before a solution is delivered. In his article CFO’s Case for Frequent Releases, Trond Wingård poses a fictional project with a project rate of return of 20%. For both an Agile project and a Waterfall project, a four month project internal rate of return on the Agile project is barely affected while the Waterfall rate of return drops from 20% to less than 0% return - pretty significant!
Mistake #5 – Lack of Constructive Disagreement!
I’m not sure why but there seems to be a reluctance to push back - to disagree - to challenge. Constructive disagreement is one of the best methods you can use to arrive at a spectacular solution. In fact, without constructive disagreement you run the risk of not achieving the best solution possible. In her book, Coaching Agile Teams, Lyssa Adkins lists several characteristics of high performance teams. Two of those characteristics speak directly to the role of constructive disagreement and the need for a safe environment to disagree.
- Teams are consensus-driven, with full divergence and then convergence.
Full divergence (arguing and debating a solution) and convergence (coming together and final agreement on a solution) increase a team's commitment to the final solution.
- Teams live in a world of constant constructive disagreement.
Many books have been written about team dysfunction and most of the issues stem back to avoiding conflict (or constructive disagreement) and not having an environment where you feel free to disagree, challenge the status quo or ask probing questions.
Establishing a safe environment for team members to ask those difficult questions is important and one of the best things you can do to further your team’s ability to collaboratively communicate.
Agile Is Teamwork
Agile is about teamwork, transparency, and technical excellence. No matter what your experience with Agile practices and techniques, the foundation for Agile methodologies is rooted in best practices positioned to enable collaborative environments where diverse teams can continuously learn, improve, grow and produce.