12 Things That Will Mess Up Your Agile Transformation

I found a treasure trove of notes from my attendance at Agile2012 recently on a talk given by Angela Druckman called "The Dirty Dozen - 12 Practices That Can Kill Your Agile Transformation." Here is a recap, and it has been a while, so it's just some key points:

One of the key points conveyed was that most problems are symptoms of root causes, and those are often value conflicts. The trouble with transforming your team to use agile methodologies often boil down to how managers and teammates view the nature of work.

1. Teams that don't self manage.

  • Moving "resources" around constantly prevents the team from really gelling and fostering the relationships necessary to self manage.
  • People are people, not resources, not bags of sand. You can't just plug one into another team and expect performance.

2. Product owner can't or doesn't fulfill the role.

  • The product owner says: "you should be able to figure this out."
  • Real ownership requires constantly and actively participating in the definition and clarification of acceptance criteria, requirements, and product needs.

3. Scrum masters act like our protective parents.

  • The desire to control or drive can take over and dominate the process.
  • Legacy, attitudes of command, and control butt up against the need remove impediments and coach a team to be high performing; Druckman said:

If you are a really good scrum master you will work yourself out of a job.

4. Stakeholder problems.

  • "Just this once." - An unspoken message that "my needs are more important, to the point where we can abandon discipline and process."
  • Clinging to legacy modes of work delivery will delay the transformation, and cause a slippery slope situation.

5. Organizations that don't understand commitments.

  • Negotiation arises when there is punishment for missed commitments. A culture of fear prevents realistic or real commitments.
  • Commitments are one-sided. A commitment must be a two-sided agreement; if I commit to deliver the code to you in 5 days, then you must also commit to deliver detailed requirements in 2 days.

6. Organizations can't time box.

  • Tasks can become more important than outcomes and focusing on the outcome can lead to creative solutions with a given amount of time.
  • Gandalf said it best:

All we have to decide is what to do with the time that is given to us.

7. Teams can not inspect and adapt.

  • Improvements are considered "more work" which is short-sighted, whereas they might reduce work in the future.
  • Complacency can arise when teams declare "we are already good." Strive to always make things more simple and efficient.

8. Unbalanced agile toolkit distribution.

  • The unspoken message is "Who's important? These are the people that need the tools."
  • Adoption and coaching should happen across entire teams, or some will feel ignored or disenfranchised.

9. Thinking agile is "something tech people do".

  • Agile is not just for software engineers; it has actually been shown to work effectively across many industries.
  • Each member of a team, not just developers, must embrace the methodology.

10. Lack of understanding about the behaviors you are reinforcing.

  • Cutting people slack all the time can promote a lack of discipline, while harsh punishments will promote conservative behavior that could hurt innovation.
  • An attitude that "people won't know what to do unless you tell them" can undermine the self-organization of a team.

11. Not understanding what a trade-off is.

  • Everything is a trade-off; to have one thing, you must give up another.
  • Not everything is equal, and not everything is needed. Teams and management must understand that to require one thing may necessitate giving up something else: I can commit to deliver the code in 5 days, but with only 3 of the 4 features.

12. Redefining what success looks like.

  • The ideal should be a "low drama organization": people want to be there, it's generally quiet, things just kind of get done.
  • The days of crazy deadlines and long hours are gone; by rewarding a "hero" engineer who pulled an all-nighter, you are probably rewarding hacked together code, and a lack of adequate planning.

If you were there, I hope you enjoyed the talk as much as I did!

If you enjoyed reading this or learned something, please consider sharing via , , or . Thanks!

If you enjoyed this article, you might like others related to the Agile interest.