Learning some Agile lessons

Note: This post was actually written in 2012 but somehow was left in a draft mode and never got published. I think it still has some interesting points for people who are pursuing Agile.

I have just finished an engagement to help a client in their transformation to Agile practices. I will fill in some of the details below, but the punch line is that this company is doing a good job of it. The graph on the left is an assessment that I have done for the last four companies where I assessed Agile maturity. The horizontal axis is how many months the organization has been working at being Agile and the vertical axis is a measure of how well they are doing. This is based on forty-four Agile Practices that Dr Laurie Williams used to get the opinion of how important a practice was for their organization. I thought this represented a reasonable definition of what Agile was and have used it as a basis for assessment. A "perfect" score would be 220, meaning that the organization was performing at a high/sustainable level on all practices. If you are curious about these practices go here.

Anyway, back to my recent client.... After eight months they had achieved a score of 144 (Gold Star!)
How did they do it? I told them it was three things:

1. Engaged executive management - The CEO, the COO, the CTO and several lines of business executives would regularly go to demos. This showed the Teams that they were interested and expecting good work. The Teams were very motivated by this level of engagement.
2. A dedicated Agiile CoE - The Agile center of excellence had four full-time and three part-time members, who were training, coaching, marketing the Agile transformation. This level of support meant the Teams (15 teams with approximately 100 total headcount) were getting sustained assistance as they adopted the different practices.
3. External expertise - That's me! My experience in seeing practices applied at several companies, allowed me to offer suggestions for improvement.

One of the things I love about being a consultant is that I learn lots of new things when I am engaged with a client. Some of the really cool things that I learned while with this client are highlighted below.

Roadmap of Roadmaps

I had introduced the use of a Product Roadmap from Enthiosys. My client was developing software in a very tactical manner and the Roadmap helped force the planning out a few quarters. However another attribute of my client was an application architecture that created many dependencies between teams. They had already begun a Scrum of Scrums meeting for the Scrum Masters and had been tracking tactical dependencies. One day a Product Owner and I were chatting and he said it would be great if all the Product Owners could get together regularly and compare Roadmaps. I said "Sort of a Roadmap of Roadmaps" and from that idea the Center of Excellence developed and scheduled a meeting where all the Product Owners got together and did the follwing:

• Conveyed the major features in their roadmap over the next four quarters
• Listed questions, risks, dependencies and in that meeting and afterward worked that list.

Most places that I have worked the Product Owners are relatively independent from each other. At this client there were more dependencies. PLUS the company was in the process of a major investment in a next generation architecture and use of the Force.com platform. As new generation applications came on-line the old stuff needed to retire gracefully.

Sticky Point Burndown

The classic Scrum practice of tracking the sum of hours worked on for all tasks subtracted from the committed estimate (Burndown) was something that my client was unevenly practicing. Even for the burndown of our CoE Stories we had decided not to estimate task hours but measure burndown in Story Points as the user story was done. This resulted in a graph like that shown below

The problem with tracking done stories is that most of the time stories tend to have some lingering tasks until the last couple days of the Sprint. This resulted in a burndown that did not really tell us if we were off track.








One day I was staring at the Task board (we had lots of task moving daily from "To Do" to "In Progress" to "Done". The light bulb went off and I  summed up all the task cards (stickies) and each day subtracted those "Done". This resulted in a graph like that shown below.

So now we had a more granular burndown that we could check progress against. Still not as good as tracking hours but not so much overhead.

Story Capture Sessions

A couple of the architects I worked with had been exposed to XP and really liked the idea of a using a Story Capture session to meet directly with end-users and refine the requirements. During Sprint Planning or in a grooming session prior to Sprint Planning the team would review stories and select those that had good prospects for a successful session. A combination of how important the story was and the amount of unknown information related to the story were factors in deciding. In a couple of Sprints that I was observing the Team picked about five stories out of a two Sprint backlog of about 20 stories. The Story Capture Sessions were schedule to run for about two hours with 3-4 end-user types invited. Because this was an internal application being developed, access to the end-users was relatively easy. A lesson learned was to schedule well in advance so that delays did not occur during a Sprint. The Story Capture Sessions needed to be in the first 3-4 days of the Sprint (they were on a three week iteration) to leave enough time to complete the story.
During the Story Capture Session the Team would review the Story and Acceptance criteria, but mainly ask questions and draw on whiteboards.
Most companies I have worked with did not formalize the conversations to support a User Story. Most of the time, simple one-on-one meetings would be used between the BA and Product Owner or Developer and Product Owner. The danger of a Story Capture Session is that because the details are coming from end users they may not be what the Product Owner really wants based on several competing factors (e.g. functionality vs. cost). So the Product Owner and/or Business Analyst needs to attend each session and pay attention to the details. On the other hand, if the Product Owner is not sure of requirements, this JAD type session can quickly surface the needed information.

Agile Practitioner Lunch and Learn Event (APLLE)

At every client where I am engaged, I offer to run informal lunch and learn events where I will discuss just about any topic requested. This is usually after a standard training cycle and while the Teams are sprinting along. A very typical one is the role of the Business Analyst in Agile for those companies with a Business Analyst population.

So at my most recent client, the leader of the Agile CoE asked me if I would be willing to offer my expertise on a variety of topics in a lunch and learn format. No Problem. What was innovative was that we turned this into a regularly scheduled event, and began to use it to showcase some of our themes/initiatives of the Agile transformation.

We invited approximately 75 people and usually got 10 - 25 people to attend. We also recorded the event for streaming afterwards. I spoke on topics including:

• Agile Analysis
• Charting in Agile
• Common Pitfalls for new Agile Teams
• Estimation best practices in Agile
• Product Owners and the Stakeholder Network
• Self Governing Teams
• Technical Excellence
• The Agile Dance
• The Calibration Banner
• The Definition of Done
• The Role of Architecture in Agile

However, more recently we had presentations from other parts of the company that supported the Agile Teams, and from practitioners within the Agile Teams.

This form of community sharing of information was a strong way of both education and demonstrating to the organization as a whole that the Agile Transformation was being successfully executed.

Conclusion

We all learn from our experiences and I will take several of the things I learned at this client into my next Agile engagements.