Lessons Learned From Our “Fail Faire”

“What an amazing evening!”, “The best Agile Ottawa event I’ve been to”, “This was great!”

These are only a few of the positive comments from the group that came together to share their failures. Anyone who wanted, which was almost everyone, got up in turn and told a story of mishap. These were not stories of greatness or accomplishment. There was no bragging or boasting. People told real stories about themselves where they did the wrong thing.

The wonderful part was what they learned from that experience. The sharing was part healing and part teaching. It would be impossible to try to recreate that evening (you really had to be there) but we have captured some lessons learned to share with the community.  I encourage anyone who was there to add their comments. 

Lessons Learned

1. Have facilitation techniques ready for talking about tough problems.
2. How you implement change is as important as the change itself. If
you mandate it – you must also be a part of it! Additional: Technical
practices are important (not optional).
3. If it isn’t Agile – call it!  Training is important for team alignment.
4. Pay attention to the parts of the system that are hard to change.
That’s where the volatility will be in your project.
5. The team must commit to at least 1 hour a day when the whole team can meet.
6. Beware of “sunk cost” – make sure your project still has value no
matter how far into it your are…
7. Don’t let process distract you away from people (e.g. creating
collaboration or a shared understanding).
8. Make sure you have a Product Owner.  An absent Product Owner is the
first sign of trouble. When in a large organization ensure that you
actually have executive buy-in as well.
9. When investing in change, ensure that you have change management in
place.  Again, ensure executive buy-in first… they also need to be
educated on change.
10. Be honest with yourself – personal retros are a very good thing.
Sometimes, you are the one who needs to change.
11. Your backlog isn’t a Christmas list. Sorry, Virginia, there is no
Santa Claus.
12. Prioritize your backlog in advance. Not all decisions need a
meeting (necessarily) – explore non-verbal prioritization.
13. Agile projects need self-organization… and not everyone
necessarily wants to self-organize.  You need buy-in from the team.
14. Don’t abandon an agreed upon practice unless you know why.
15. People need time to absorb change… they need to know the value
of the change and they need to have confidence in their own capability
for change.
16. Month long Sprints are risky.  Shorter Sprints are good for
feedback and learning and ensuring that the team is meeting
expectations.
17. Again, know your Product Owner and make sure that they are
empowered to make decisions.
18. “Cracking the whip” is a poor motivational technique.
19.  Follow-up with your team after teaching them something new.
Teaching is the “beginning of a journey”.
20. Question: How to get devs to meet / read acceptance criteria?
Idea: To achieve acceptance / commitment to deliver, ensure that all
stakeholder are on board (not just PO, BAs…  but dev and testing
too) in creating the acceptance criteria.
21. Code review. Code review. Code review. No one person is
infallible. The more the merrier… “To go fast, go alone. To go far,
go together.”

2 responses to “Lessons Learned From Our “Fail Faire”

  1. Pingback: Jamie Longmuir | Lessons in Failures to Drive Change

  2. Pingback: The Secret of Success | agile meditation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s