The Agile Blog is proud to present the first post from our newest contributor, Agile Coach Ken Clyne
If a team member doesn't take accountability, things can get messy
With a four year old and a six year old, familiar sayings around our house are “pick up your toys,” “pick up your clothes,” “brush your teeth,” “get dressed.” Of course, as parents we could get our short-term objectives met much faster if we just did these tasks ourselves… but we don’t.
We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.
Giora Morein takes somewhat the opposite view in a recent Agile Tip of the Month article. He proposes that ScrumMasters (or, in my extreme analogy, the “parents”) should track hours remaining on a sprint on behalf of the team members (the “kids”). Giora says:
“Team members are focused on completing tasks and delivering value. The time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important. As such, the ScrumMaster should take on the responsibility of updating burndown data.“
While I don’t question Giora’s good intentions and there is no doubt this approach is expeditious, I believe it is worth striving to have the team update their own hours remaining. There are many benefits to being a member of a self-organizing, self-managing team, but with those benefits also comes responsibility and accountability.
Here are some dangers I see in a team not taking responsibility for their hours:
They become less accountable for the number they provide
They don’t understand the mechanisms of the self-managing, self-organizing team
They become dependent on the ScrumMaster
The ScrumMaster becomes frustrated and disillusioned
The ScrumMaster morphs from a leadership role to a management role
The team starts to revert to form
How does your team update its remaining hours? Have you tried one method that worked better than another?
Before I dive into Part 3 on my series about Agile Process Overhead, I wanted to review where we are and interject a little wisdom around all of this.
You may recall that I had a client come to me with great concern (frustration?) about all the “overhead” in adopting Agile. Specifically, they wanted to address:
What goes in the Sprint Backlog?
How do you allocate your time effectively?
How do you “plan” for unplanned work?
Each of these seemed to cause a lot of overhead for their ScrumMaster and the team. That confused me and so I decided to post some ideas about them. I addressed the first bullet in Part 1 of this series, and the second bullet in Part 2.
So let’s take a break before moving on to Part 3,: “How do you ‘plan’ for unplanned work?” Here is what I want to raise as a guiding mental model: the 5 Orders of Ignorance. This may appear to have nothing to do with the perceived process overhead with Agile. I think it has everything to do with it.
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
0th Order Ignorance: Lack of Ignorance
I (probably) know something
1st Order Ignorance: Lack of Knowledge
I do not know something
2nd Order Ignorance: Lack of Awareness
I do not know that I do not know something
3rd Order Ignorance: Lack of Process
I do not know a (suitably effective) way to find out that I don’t know something
4th Order Ignorance: Meta-Ignorance
I do not know about the 5 Orders of Ignorance
Where do you think the troubled team is in the 5 Orders of Ignorance when they are struggling with Agile Process Overhead in the guise of an overloaded Sprint Backlog, allocating team members, and planning for unplanned work? How do you think Agile and Lean approaches actually directly impact the 5 Orders of Ignorance? And, in so doing, can you see ways that, in attacking the 5 Orders of Ignorance, they directly impact costs to teams and organizations in a variety of domains?
As I watched the Rockies sweep the NLCS I could not help but to think that the Rockies took advantage of Rally’s professional coaching services to help the team achieve success with their agile rollout. Let’s analyze baseball in regards to agile…
During the regular season baseball teams play in 3 or 4 game series, which can be thoughtof as an agile release. Each game in the series can be thought of an individual iteration with a timebox of 27 outs. The user stories don’t really change, a typical baseball iteration has 9 user stories (innings) with 3 story points each. The velocity of the team
really depends on the pitch count. If the pitch count is low we could consider the story to be completed faster than other stories in terms of relative sizing.
Similar to agile, the size of the team is nine players on defensive. These nine players work very closely together to complete each story and focus all of there energy on the current iteration (game). A team member grabs tasks (outs) when they feel they are able to take on more work. Team members regroup in between each inning for a quick stand-up meeting to discuss the next highest priority story (ok this is a long stretch but maybe they have a stand-up).
After the completion of the iteration there is always a retrospective (post game
conference). During the post game press conference (retrospective) the team manager acts as a scrummaster or coach and shields the team from media controversy. The manager is ultimately shielding his team from stakeholders (fans, media, owner) and focusing them on the current iteration (game).
At the end of a game (iteration) the team has completed 9 user stories and the team owner (product owner) either accepts the game or does not accept it (win/lose).
To end this fairly useless analogy we have to consider the post game celebration. Trust me the Rockies had one heck of a release party last night.
Every day, the Agile Project team meets for a short status meeting. The purpose of the meeting is to ensure that team members are aware of what others are working on, and to provide visibility for delays and obstacles. Each team member tells the others:
What they have been working on since the last standup
What they intend to do today
What obstacles are standing in their way
The ScrumMaster takes notes on each team member’s obstacles.
The Daily Standup Meeting is for status only, not discussion. If a team member wants to discuss something, they can propose a discussion in the future. For example, “I have some ideas for how we might do X—does anyone have time to talk about this today?”
Daily Standup Meetings are primarily for the team. The Customer and other stakeholders are encouraged to attend, but they aren’t allowed to speak.
The Daily Standup Meeting should be no more than 15 minutes. If all of the participants stand (rather than sitting) the meeting is over much more quickly. It is the responsibility of the Facilitator to ensure that the meeting stays on track and is over quickly.
One of the 7 Principles of Lean Development, “Amplify Learning”, specifically targets the agile practice around “Inspect and Adapt”. In fact, the Lean Principle “Amplify Learning” is the predecessor to the agile practice. At the project level, you can think about amplifying learning in a variety of ways. Daily, we check in with one another about, “What’s happening that could be blocking us from success, and how can we adapt in order to remove that block?” And, at the end of each Iteration, a team pauses in order to demonstrate releasable tested functions (RTFs) and determine how to proceed in the next Iteration. They base their plan on a review of their successes and challenges in the last Iteration. So, what happens at the Program level when agile is being applied across multiple project teams within a Program? How do we still inspect and adapt effectively? This is where revisiting the Lean Principle “Amplify Learning” comes in mighty handy.
“Amplify Learning” means planning to experiment, checking the data around the results, and then incorporating what is learned. For Programs, this means deriving metrics that can be cross-team applicable, not just intra-team optimized. How do we accomplish this? That may require “leaning” on another of the 7 Principles: “See the Whole”.
Here are seven practices that “Amplify Learning” for Programs:
Use coordinated Iterations across teams to increase inspection and adaption
Project teams within a Program manage their integration risk and sub-optimization issues by setting a common rhythm across all teams: one common Release Plan with the same number of Iterations, all of the same fixed duration, for all teams. All teams commit to the common plan in a Program-wide Release Planning meeting. Thus, at the end of each Iteration timebox, the Program Manager, Product Owner, representatives from each team, and stakeholders inspect the overall flow of the Program: Where are the bottlenecks? What resource constraints continue to grab us? What Program risks persist? Where are we slipping in quality or in function delivery at the Program level?
Increase osmotic communication
Group programming and pair programming within each project team creates flow for each team. Optimizing flow for the entire Program relies on this team-level engineering discipline. When team members amplify their learning in this way, they promote rapid osmotic emergence and convergence of the useful Program-level standards and best practices. Norms across the teams buoy the stability of the overall Program.
Create total transparency across teams everyday
Backlogs, burndown charts, and resource loading must be tooled and completely visible across the entire Program, regardless of the number of teams or locations of teams. A common automated Product Backlog coupled with an automated Iteration Backlog for each project team is a must. Programs require nothing less if they are to be able to amplify learning daily, from iteration to iteration, and from release to release.
Apply tools to maintain information and create visibility
Programs must collect data (metrics) and incorporate learning across all teams in order to take advantage of the common rhythm of the team iterations. That means implementing tools that can manage the data, distribute the data, and then track the trends of the data iteration over iteration across all teams. A team-level dashboard as well as a Program-level dashboard has to be visible to all stakeholders across all teams. QA and documentation must have high visibility across all teams in order to plan aggressively and integrate fully for product release.
Hold daily Scrum of Scrums across teams
Once each project team has had its Daily Standup, it’s time to check-in across projects via a meeting of the ScrumMasters or Coaches. In the Scrum of Scrums, a representative from each team checks in with the pulse of the team and turns to the other participants for assistance in removing impediments. Each day, the participants check-in with one another on their action commitments from the previous day. They amplify learning across teams in the Program by rigorously checking in with one another and upholding their commitments.
Hold a weekly MetaScrum across stakeholders
Issues that extend beyond the authority or “radar” of the Scrum of Scrums elevate to a weekly meeting of the Program stakeholders. So, not just inter-team issues, but high-level Program-level impacts are addressed. The stakeholders commit weekly to the gnarly issues that can extend beyond the teams, the IT organization or even across divisions. Each week, each stakeholder is held accountable for having resolved the issue for which they took ownership in the previous meeting. No excuses. In this way, stakeholders inspect and adapt in an urgent, virtuous cycle, setting and meeting audacious Program goals.
Hold a Program-wide Release Retrospection at the end of each product release
Once the set of Iterations timeboxes have completed, the entire Program must pause to evaluate the load and flow of the previous Release: What did we plan during the Release Planning meeting? What did we manage to accomplish by the end of the Release? What new practices did we invite during the Release? What worked well during the Release? What challenges hampered us during the Release? What trends in metrics did we notice over the course of the Release? What issues and concerns still exist? Given the Program team responses to these questions, the entire group then determines: What new practices should we implement in the next Release? What new priorities should be addressed in the next Release? How should we re-shuffle resources across teams? What goals should we set for the Release? What “inspect and adapt” practices need to be amplified?
Amplifying learning means attacking any issue, any risk, any impediment, any waste with a vengeance at any time. A Program that implements the seven practices of “Amplify Learning” listed above will reap the benefits of more reliable product releases through better planning and better responses to the uncertainties that may arise. Pause, refresh, retrospect, go. Do this daily, every Iteration, every Release across all teams and all stakeholders.
RallyDev.com
If we are looking at process overhead, I think applying the 5 Orders of Ignorance is great guidance:
