There Are Many Pitfalls to Agile Adoption
Do you want to try Scrum, XP, Kanban or any other agile approach and see how it goes? Great, go for it — just be sure to implement it in a sustainable fashion. Too often, teams try a new approach but don’t prepare fully, don’t execute well, and don’t get the results they want.
Here are some examples of approaches that are not sustainable:
Providing the team with little or no agile training and expecting them to hit the ground running.
Whether you follow Scrum, XP, Kanban or another agile approach, there will be major differences in how the team and the organization operate. It is not just a matter of writing software differently. Train at least two key contributors to the project in the approach you plan to follow. Also consider onsite coaching for the entire team.
Diving right into a distributed team project without the benefit of prior experience.
It’s easy to assume that because you have delivered large projects before, you can change your approach and go right on delivering large projects. Success is unlikely and diving right in should be avoided. Build up some experience on small and simple projects before taking on the large and complex.
Demanding that team members work odd hours to facilitate communication with geographically dispersed team members.
Teams will have to put in odd hours and/or weekend time on occasion. Asking them to do so routinely is a big mistake. Be sure everyone on the team is comfortable with the team environment and the project logistics.
Scheduling daily stand-ups in the early morning despite the preference of some members to arrive at work later.
There is a tendency to want to schedule the daily stand-up meeting first thing in the morning. Some folks like to arrive at work in the early morning and leave in the mid to late afternoon. Others like to arrive later in the morning and work into the evening. Be open-minded. This meeting can occur at any time of day. Just be consistent about the time and place.
Selecting someone to be “Product Owner” who has no authority to make any product decisions.
If the “Product Owner” is nothing more than a liaison between the software development team and the business, delays are inevitable. Developers will get frustrated. The business folks will get aggravated by all the questions. No one will be happy. Insist on a product owner than can make most decisions independently.
Assigning a traditional “Project Manager” as “Scrum Master” and expecting her to produce the usual waterfall artifacts.
While Project Managers can transition to being Scrum Masters, it is not an easy chasm to cross. The expectations of a Scrum Master are not the same. The rules and the deliverables are different. It is not the same role. Forget waterfall. Move on.
Agile approaches to software development can work if you put in the effort and set appropriate expectations with your team and the business stakeholders. Your thoughts?