Tag Archives: Lessons Learned

Secrets of Agile Success – Minutes From Our “Success Faire”

Once again, the Agile Ottawa community did not disappoint… The evening started with an engaging session on Core Protocols, facilitated by our own Ellen Grove.  Ellen covered the basics of Core Protocols and lead a very effective exercise where the group had the chance to try out the protocols on each other.

In the spirit of this, we moved on to exercising one of these protocols in more detail… the “Brag Protocol”.  Participants shared stories of Agile success, we promptly applauded and cheered on…  and we attempted to capture the source of these successful stories.

Without further ado… here are a few secrets for achieving Agile success captured from our meetup:

1. Allow the team to express their opinions in anonymity to help reveal the truth.

2. Bring a ball to standup. Rather than “follow order” throw the ball around to choose who speaks next… this can lead to interesting conversations and new interactions.

3. Need people to take the lead? As the team for volunteers, you’ll discover that (given the opportunity) people WILL step forward.

4. The antidote to despair on a project is empowerment. Start fixing problems.

5. If you keep sharing Agile stories and lessons with the team; over time, you will find that you are transforming people in great ways that you didn’t anticipate.

6. Formulating the project “requirements” as “problems”, allows creative ideas to come forth and empowers the team.

7. Mob programming is a great way to “gel” a new team together and build Agile skills. It’s also an effective way to solve problems.

8. Creating a safe place to work allows the team to make mistakes and grow.

9. Looking at a laundry list of a backlog? Turn that list sideways and narrow it down to the most important stories.  Creating a reasonable scope of work means more work gets done… and less time is spent talking about it.

10. Transforming a team’s physical space (e.g. take down those walls) creates opportunities for the team to share and work in new and more effective ways.

11. Create opportunities for teams to share their different experiences with each other… being able to visualize work is key to making this happen on a regular basis.

12. Confront those monsters! Often problems that appear impossible or extremely hard to fix can be resolved quickly by working openly and collaboratively.

Thank you to all who participated and shared their experiences with the group.

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.”