Top 10 Issues Implementing Agile (Okay, 14)

I really hope you have enjoyed this 3 part series focused on Agile concepts for the ‘traditional’ waterfall project managers.  I truly hope this has opened your eyes to the world of Agile and that you enjoyed the first two posts by Derek and Peter.  Without delay, I want to get into to the last installment and guest contribution by Mark Levison.  Mark brings over 20 years of experience to this post and is now a Certified Scrum Trainer and Agile Coach.  Let’s get to it and don’t forget to share your thoughts, experiences, and questions.  I don’t want to talk at you, but with you.  Mark…

I’ve been practicing and coaching Agile in one guise or another for nearly a decade. After a year spent travelling in Australia and New Zealand I was interested in a fresh way of developing software. Around that time I discovered the Portland Pattern Repository with Unit Testing, Pair Programming and Test Driven Development. From that day I became a zealot, eager to share these amazing ideas with my colleagues and team mates. Amazingly inspite of some my early eagerness many people weren’t open to trying these new ideas. From that experience I’ve noticed a number of common adoption anti-patterns or Agile Smells.

1. Mindset change – when you catch yourself in the trap of saying “this is just like what we’re already doing except…” you’ve missed the key point. Agile Software development requires a complete mindset change. While some of the events (i.e. Daily Scrum) may be superficially similar the mindset is different.
2. Self Organization – self organization is messy and takes time to achieve yet its at the heart of a high performing Scrum team. So its sad to see Scrum Master, an Architect or other team member with a leadership position taking control. This problem can be obvious or subtle but either way they’re not giving the team room to grow.
3. Meetings – aka Mechanical Scrum/Agile, you can hold all the right meetings (Planning, Daily Scrum/Standup, Review and Retrospective) if the joy and spirit is missing then they will be wooden events that don’t but help the team collaborate and grow.
4. No Engineering Practices – Agile processes (Scrum, OpenAgile, Kanban etc.) tend to lead to an immediate speed up in the development process. But if there is no focus on working on Engineering practices (TDD, ATDD and Pair Programming), then the team will soon end up hip deep in Technical Debt. For more on this see: Technical Debt a Perspective for Managers
5. “We do Scrum But ….” – the daily standup is 3 times a week. Scrum (and any Agile process) work well out of the box. In the first in the first six months when we’re tempted to make changes, we’re doing it before we understand the big picture and the benefits. Many of the changes I hear about come when someone says “We’re spending too much time in meetings”. If the basic Scrum meetings are too much overhead then this is a signal that there are deeper problems at hand.
6. Retrospectives without improvement – a retrospective who’s action items are not acted on quickly becomes a meeting people will have no respect for. Take the SMART actions from your retrospective, post them on your task board and check in on them in stand-up everyday. For more on running great Retrospectives see: Agile Retrospectives.
7. Command and Control Agile – A Scrum Master, XP Coach or even Open Agile Process Facilitator isn’t a Project Manager. They don’t assign tasks or tell team members what to do. Instead they’re there to help the team achieve its goal and to help them grow into a high performing team.
8. Pre Assigned Tasks – During Sprint Planning team members often pre-assign stories/tasks to particular team members. The problem here is that we can’t foretell the future if the person to whom the task is assigned we have a bottleneck. The task is blocked until they become available. Instead of pre-assigning the best person to task, its better to wait to see who is available to tackle it. This often leads to team members learning new skills (see Handoffs and Silos).
9. Lack of Real Commitment – an Agile transition is hard work and requires time. There will be some bumpy moments during this time. Full commitment (not just $$$) is required from Management who have to demonstrate they support the change and will help to remove impediments.
10. Nothing Ever Changes Around Here – the team raises impediments but either doesn’t work on removing them or isn’t able to remove them without more help. They will quickly get the message that the organization isn’t on board. Management must support the team by helping to expose impediments and get them resolved.
11. Scrummerfall and Waterations – When teams first transition to Agile there often still handoffs from BA –> UI –> Dev –> QA. As you can see this is still waterfall only faster i.e. waterfall in two weeks. While this is an improvement the real wins in Agile come when work in parallel and blur role boundaries. Work in parallel includes Acceptance Test Driven Development, where we the acceptance tests are written before the application code. Agile encourages the blurring of role boundaries with Generalizing Specialists, in this case we might see a BA who learns enough about QA to help write tests cases or a developer who learns enough about UI work to create the initial mockup before finding the UI specialist.
12. Rushing to make the Planning Commitment – Teams that are new to Agile often overcommit in their first few sprints (aka iterations), sometimes by as 200%. When this happens they often cut corners to get all the work done, with classic statements like: “We don’t have time to write Unit Tests”, “We don’t have time to test that properly”. A good Agile team starts only a few User Stories at a time and then gets them to Done Done. That often means completing fewer stories than originally committed, its better to do this then have to rework previously “completed” stories because of corners cut.
13. Attempting to Scale at the Start – Organizations that are adopting Agile often want to work at scale (more than 3 teams) right off the bat. Its difficult to get a few teams off to a good start, without complicating matters with additional communication problems. Launching at scale can be done, but it tends to require alot of coaching support. If you’re starting on your own start small.
14. Believing that your done becoming Agile – An Agile transition is a journey, one that you never really complete. You will always find ways to improve and new experiments to be run. If you keep an open mind and are always looking for new ideas you will undoubtedly scale new heights.

While I’ve made it sound difficult and challenging (and it is), nonetheless the journey can be among the most rewarding a software development team can make. When a transition goes well I’ve seen a team undergo amazing changes in only a few short weeks.

If you want to see more transformation pitfalls read: 12 Agile Adoption Failure Modes by Jean Tabaka and 12 Key Barriers to Agile Transformation by Mike Cottmeyer.

Mark is now an Certified Scrum Trainer and Agile Coach with Agile Pain Relief Consulting. He has over twenty years experience in the IT industry, working as a Developer, Manager, Technical Lead, Architect and Consultant. As part of helping with Scrum transition at Cognos he designed a Test Driven Development adoption strategy and introduced of a number of practices to support it.  .

Mark has introduced Scrum, Lean and other Agile methods to a number of organizations including: Export Development Canada, Industry Canada, a leading payroll and HR services company, Invision Inc – A leading ad planning provider for the media industry and a leading Job Search site. He coaches from Executive level to the individual developer and tester.

Mark is an Agile Editor at InfoQ and has written dozens of articles on Agile topics and publishes a blog – Notes from a Tool User. Mark’s training benefits from his study and writing on the neuroscience of learning: Learning Best Approaches for Your Brain.