It is Monday. I had quite a busy weekend so I am still halfway my sleep-cycle as I walk into the office of my client. It is busy, people are shouting, I see some small groups clustered together around their computer screens, making energetic gestured at what is displayed on it.

That weekend, they did a Release. And as many IT companies do nowadays, they release once every quarter. So it was a big release, big bang, lots of software, and one moment of truth. And it did not really work out. Fifty-six priority 1 incidents!

At the end of the week, after many retrospective meetings on the Release with developers, testers, analysts, IT management, architects, and security managers, I come to the conclusion that I need to structure their approach to line them up for Agile delivery. They already have Scrum teams, six of them, working in two-week Sprints, but they still apply a big-project-know-everything-upfront approach to software design and delivery. And Product Owners do not really feel the necessity to create a plan of their own, for their own team.

If you feel pain, go through it. Make the pain visible, ask for help, and solve it together. Do not sweep it under the carpet. This is what I see happening all the time, for instance by blurring the pain by applying tools and processes. For instance, in this Release process, we could have set up a central board, requiring ticked check boxes from all the teams for over 100 items before they are allowed to put anything in Production. Thereby making the problem invisible, most likely even delaying and amplifying the pain, but not solving it.

So step one was to visualize the pain.There are all kinds of issues and a lot of waste in this process, think about:

  • POs without a plan of their own
  • Sprints that contain waterfall blocks of work like “Functional Test x”
  • waste of talent by not letting the Scrum Masters take their role
  • steering on output which makes the teams blindly focus on pushing software
  • no transparency on who is doing what, creating chaos
  • no transparency on what is coming next with respect to planning

This client needed something that finds its origin in visual management, practiced by Lean manufacturers over the world. So we set out to visualize the pain. Together with the IT manager, I arranged for an empty wall of about 3×5 meters big. The place of the wall had to be right next to the desks of all the people who were working on the items that we were going to put on it.

 

Visueel planbord ed2.jpg

Two weeks later, another Monday, we are with the six Scrum Masters, the six POs and two delegates of IT management in front of the newly created 3×5 meter whiteboard. We start with horizontally setting out the timeline on the board. We settle with the first four columns ‘Current Sprint’, ‘Next Sprint’, ‘Next Sprint + 1’ and ‘Next Sprint + 2’.
The next columns are further in time, so we settle on three additional quarter columns, at that time labeled ‘Q2 2016, ‘Q3 2016’, and ‘Q4 2016’.
The last columns get the header ‘Ever’, and we add a ‘Done’ column to be able to show Done stuff.
To complete the board we split it in vertical swimming lanes that each represents a Scrum development team, and add a separate lane for Architecture and Security, since the people working there perform work in the process but are not part of the Scrum teams. We also add a separate swimming lane for Projects, since there are some projects that might or might not impact the Scrum teams, and we want to visualize that.

So, how does this work? We now have a giant planning board. Sticky notes or, preferably, magnetic index cards, are used to show a Product Backlog Item. Color coding is in this case used to indicate the phases of Refinement (New, In Refinement, Refined). Markers on the cards are used to indicate whether PBIs are part of a bigger Epic together, and colored magnets are used to indicate dependencies.

Next, we made some working agreements and introduced two new meetings. First and foremost, since we have top of the line facilitators in the form of Scrum Masters, we choose to let them facilitate the new meetings, so in the meetings the Scrum Masters are always present. Next, the two meetings were planned: a weekly standup meeting at the board with the POs and the chief project manager that coordinates all projects to let them update each other on progress and identify dependencies between PBIs and between PBIs and Security or Architecture. This is just a half hour standup meeting.
The second meeting is a session of two hours that is scheduled bi-weekly. In this session not only the POs and the chief project manager are present, but stakeholders are invited as well, and the CEO is there. This session is mainly used to identify and solve dependencies, and make decisions on ordering items based on value estimates.

Now that we have used this approach for a couple of weeks, I can write about the benefits:

  • There is an operational layer in this approach. It is now clearly visible who is doing what and when. The PO is now planning on capacity of the team which helps in visualizing a realistic planning. If a new item comes in, the PO can say “No” based on capacity of his team, and start the discussion of what needs to move and why, or put the item in a future Sprint or quarter to be picked up.
  • Because it is now visible when stuff and what stuff is coming, architects and security managers can now decide in which team Refinement sessions they want or need to be.
  • By letting the sessions be facilitated by Scrum Masters, you not only get good sessions, but they learn and grow. And because of the type of stakeholders that adhere these sessions, they can identify growth opportunities with respect to an Agile way of working.
  • Dependencies between teams can now easily be identified, which is input for those teams to start up Scrum of Scrums in order to align their work.
  • Dependencies between projects and teams can easily be identified and correctly ordered.
  • Attendees can now have a meaningful discussion on priority of work, taking capacity into account.
  • By making use of the first columns, it becomes immediately clear when a team has not enough ready work for the coming three Sprints. In that case, those boxes are empty immediately triggering a conversation.
  • Decisions affecting planning of other items become immediately visible. The PO for instance says ‘We cannot do that together with this, so choose’, and in face to face conversation with the CEO and stakeholders, they can decide on the best course of action.
  • There is a small step towards celebrating successes, since Done items are visible.
  • Items need to be small. Every item should ideally deliver value, which is not the case. So it triggers discussion on how to slice big Epics in such a way that they do deliver value.
  • If a team is not able to deliver value every Sprint, it is immediately visible triggering a discussion on that end.

The next step is now to incorporate value estimation and ordering on value in these sessions. When the value is put on the index cards of each PBI, it makes value steering possible.

The result is that POs take ownership of their planning and a lot of useful discussion is triggered on how to move from big-bang to Sprint releases every two weeks. And secondly, it triggers a lot of discussion on how to do the most valuable stuff first and how to know what delivers value and what not. And that is exactly where I wanted them to go!

 

 

Advertisement

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 )

Connecting to %s