How NOT To Implement Agile

The following comment was submitted on one of my blog articles. It’s quite a rant about Agile, so I thought it was worth addressing as a full post.

Agile is not always implemented in a good way or at the point in the life of an application/product where it can be useful and not disruptive. Agile is chaos when it is implemented with the following being taken away:

1. Complete requirements
2. Use Cases (solely relying on 2-3 sentence user stories and NOTHING else)
3. Documented architecture (which means it has not been thought through thoroughly)
4. Any kind of POC for brand new applications being started from the ground up
5. Solution design (documented or not it is just gone start coding with that you have)
6. Project Management: no milestones, no due dates, nothing
7. Test Plans
8. Test Cases (all adhoc testing)
9. Scoping meetings.

I work in chaos.

Agile was implemented in the following manner:

1. The people doing the work do NOT manage the work or the process. It is directed from the top down (meaning Director/VP is the scrum master).
2. Retrospectives are a joke. No one talks about the elephant in the room because management is present in the meetings. All suggestions give that would actually help fall of deaf ears. Retrospectives are a way for management to communicate the changes in the process they feel will help but the decision was made without non-management team members input. Retrospectives are a way for the ScrumMaster to ask leading questions to try and convince those who are doing the work to believe in the way he thinks it should be done.
3. The management of the defect tracking process moved from the QA Manager to the Dev Manager.
4. ScrumMaster believes that one day programmers will develop code without defects and pays no attention to the increasing number of defects. ScrumMaster only watches the burn down chart created off of story points from features and enhancements and does not take into consideration the number of outstanding defects.
5. What has been developed during an iteration has NEVER been something that could have been released. Over 200 sprints on one product and the code has never been releasable. The result is releases have NEVER been on time (or even close) in three years. Working on a team that could succeed but have their hands tied by a so-called Agile methodology makes for increasing turn over rates, aggravated employees and generally un-happy people. And, by the way, no revenue is being generated!

– Sari

This would be a case study in how NOT to implement Agile. The real problem is not Agile. It is being used in an attempt to justify a variety of organizational problems. Improper User Stories, lack of documentation, lack of scoping and planning and lack of test plans are not part of the Agile practice. The problem is a lack of discipline, at all levels. All the items in the second list are symptoms of serious leadership problems. Both of these will be problems no matter what product development methodology or philosophy your company uses. These are all human issues and need human solutions.

If your hands are truly tied and you cannot influence even small changes, then I recommend you follow your colleagues and find another job at a more disciplined, better led company. At the rate your company is going, it may not be in business much longer anyway. However, if there is even the smallest hope for change, you need to push back. Compliance just fuels the real problems. At the very least, show the discipline you would like to see in others.

You seem to have some ideas of how Agile should work and could work better for you and your team. If your team agrees, then get together and start making some changes – one at a time. From the symptoms you describe, I would recommend starting with the sprint planning process. If you’re not doing it – start. Make sure all your work has a definition of done, which includes addressing bugs. It’s not done if it doesn’t work. As for the retrospectives, when the ScrumMaster is done talking, add one item that is important to the team and can be completely done by the team (doesn’t require outside help). Then DO that item in the next sprint. When it’s successful, build on it in the next retrospective. Even the poorest leaders like to look good and a team succeeding at something is the best way to do that.

For more ideas on how to influence change, I recommend reading Fearless Change: Patterns For Introducing New Ideas.

Good luck!

Related Articles:

• 4 Essentials of Agile Project Planning
• Stop Pushing All The Rocks Uphill. Focus!
• How Scrum Can Improve Team Productivity
• Visual Project Planning
• The First Rule