Agile Release Planning

Agile release planning helps team to answer the following questions about their project:

• What can customers expect?
• About when will they get it?
• And how much will it cost?

Done well it is useful tool for teams to define release themes/goals/objectives and explore early release opportunities so that they can get customer feedback and/or potentially earlier return on investments. It is also a great opportunity to do some team building especially with a distributed team. When I facilitate this event I typically include some fun team games I learnt from Simon McPherson(@SIMONMACPHERS0N and http://gamessimonplays.com/).

 

This post reflects useful tips I've gathered from facilitating these events with small (< 8) and large teams (> 50) across multiple industries (Software, Healthcare, Telecoms and Finance). It also reflects the wisdom I got from co-facilitating this event with many great individuals:

 

Plan for the Release Planning Event

• Identify a facilitator (Scrum Master or Agile Coach) for the event
• Have a Product Vision, High level goals and Objectives
• Ensure the product backlog is prioritized and relatively stable
• Check that the Team velocity is relatively stable (after 3 - 4 Iterations or so)
• Understand the key drivers for your project i.e. Trade-off matrix
• Note key event and their dates they may impact your project

 

Invite the right People

• Product Owner
• Scrum Master
• Team Members
• Domain Experts
• Architects
• Others (anyone that can help ensure your plan is a good one)

Have an Agenda for the meeting

• Establish working agreement for the event
• Product Owner presents product vision and roadmap
• Product Owner presents the project’s trade-off matrix
• Product Owner presents the prioritized product backlog
• Team asks questions to understand user stories
• Team estimates user stories at a high level (Affinity Estimating or similar technique)
• Team should split User Stories that are too large to complete within an Iteration or add new discovered ones
• Determine your MVPs/MMFs/MMFSs (Story mapping is a good technique to lay out what story set is needed to deliver value)
• Team reviews key dates, milestones and Sprint calendar
• Team discusses dependencies
• Team discusses plan risks and/or issues
• Team finalizes release plan showing what will be worked on in each Sprint and future release candidates
• Record any key decisions, assumptions, dependencies, risks and/or issues
• Team commits to Release Plan
• Product Owner communicates plan to Stakeholders/Management
• Meeting Retrospective

 Watch out for these

• Product Owner not the decision maker for your project? It will be difficult to negotiate your trade-off matrix, accetance criteria, MVPs if your PO isn't making the decisions.
• Diving into too much detail and complex design discussions: Save yourself! You will have at least two more opportunities to review each product backlog item before the team works on it (1) Backlog Grooming meeting and (2) Sprint Planning meeting

Communicate your plan to Management/Stakeholders

Your communication should include:

• Release plan: What are your deliverying and by when. Include Release candidates (MVPs)  you've identified.
• Key assumptions: State any assumptions your are making in coming up with your plan
• Dependencies list: Resolve dependencies before the team pulls stories into their Sprint backlog.
• Risks and issues: Note mitigation strategies and any adjustments to release plan

Don't let it get Stale 

• Review/Track/Update your release plan at the begining of every Sprint. The plan is only useful if you keep it updated and make adjustments based on new information from executing your Sprints

 Reference

1. Version One’s Agile Checklist.

 

Agile Will Fail Because . . .

I was at the Agile 2013 conference in Nashville, Tennessee, in August and had the opportunity to participate in the Scrum Alliance-sponsored Coaches Clinic. Two of the volunteers at the clinic, Dhaval Panchal (www.dhavalpanchal.com/) and Michael Vizdos (www.VizdosEnterprises.com), put up a poster board with a simple statement: "Agile will fail at my company because . . ." Dhaval had created similar board at the Scrum Alliance Global Gathering in Atlanta (2012) as a way to provide a venting box for conference attendees and to raise awareness about topics that can be addressed at the Coaches Clinic.

I wish I had thought of this at the time: It would have been interesting to have had a board opposite this one with the statement "Agile is succeeding at my company because . . ."

Anyway, about 50 people scribbled on the board, and I took pictures and transcribed the scribbles, hoping to get ideas for blogs and articles. Well, I have one for you now, telling the story of what the scribbles revealed to me. The groupings of items fell into the following categories (the complete list is below):

• Lack of awareness/No need for change
• Lack of support/Desire to change
• Agile is misunderstood/Ability to change

What struck me was how this aligns with the Prosci^® ADKAR^® model (http://www.prosci.com/adkar-model/overview-3/):

• Awareness of the need for change
• Desire to participate and support the change
• Knowledge of how to change
• Ability to implement required skills and behaviors
• Reinforcement to sustain the change

Using the ADKAR model, you can see that the Knowledge of how to change did not come up in the poster board notes. This is as expected, giving the volume of information, training, conferences, and consulting companies out there preaching Agile values and offering to help people acquire the necessary knowledge of how to change.

No notes made it into in the Reinforcement category. It's not clear whether this means Agile fails before companies get to reinforce its values, or that when Agile values are reinforced there is a greater chance that it will be successful.

Transcription of the notes from Agile 2013, Nashville, Tennessee:
Lack of awareness/No need for change

• We think we are "Agile."
• We have not explained the why.
• What we do already works!?
• We only fund capital projects.
• It does not support secure software (ISO 2700 or Code Analyzers).
• Because my customer prefers Waterfall.
• We are different. Just like everyone else who has done it.
• We can't show the value.
• No buy-in from the business.

Lack of support/Desire to change

• We don't want it badly enough.
• They don't want to change and no Lean leadership.
• Clashes with current (complex) business model.
• Jim.
• Insufficient support from leadership.
• Because the CEO manages with fear and intimidation.
• Strong and growing PMO. The traditional structure is being instituted.
• Duplicitous product owners (ScrumMasters).
• We lose trust in each other.
• Because of our culture.
• My leadership team no longer believes in it.
• They think it is only a development methodology.
• Only focused on changes in development teams; not looking at whole value stream (product ideation and management).
• Our egos are bigger and more important than the company goals.
• Of me.
• Because I'm writing on this wall and I think it will so it will.
• My manager has to assign work to the team.
• Adoption is done because of convenience not because of conviction.
• The company wears "Agile" as a label and yet does nothing to remove the bureaucracy and obstacles team face daily while trying to implement change.
• They won't change ("They?" Maybe this is contributing to the problem).

Agile is misunderstood/Ability to change

• Not everyone on our team understands it.
• The concept of being dedicated to one task (story) at a time is not supported!
• Because Agile is a state of being, not doing. Agile is grossly misunderstood. SADLY!
• It is counterintuitive & hard to practice.
• Because failure is good for learning.
• Too many silos with their own goals that aren't the customer's goals.
• Different parts of the biz use different types of Agile.
• Too much focus on the mechanics of the process, not enough on the motivation/passion behind it.
• Because Agile is not the goal. Agile is simply a means to an end.
• Re-org will set us back to the beginning again and again.

My overall read from the notes is this: It is not enough to simply espouse the wonders of Agile, it is not enough that we educate people on Agile practices, it is not enough to quibble over which Agile flavor is best for you. If you don't treat Agile adoption as an organizational-change management challenge, and manage it as such, there is a good chance that it will fail.

The Memoirs of a ScrumMaster

Weclome to "The Memoirs of a ScrumMaster" (credit for the title goes to Mike Sherman one of the developers on my team). After years of using several different software development methodologies and finally settling for Microsoft Solutions Framework (MSF) and the Microsoft Product Development methology, I discovered Scrum. I had read about Agile software development but never came up against a challenge that MSF did not solve, for the most part, until I came to Vorsite (http://www.vorsite.com/).

The challenges we faced at Vorsite led me to re-examine my thinking about software development. At Vorsite, we actually managed to release our products on time and with acceptable quality (eventually!!). However, I questioned if the final product actually delivered value to customers and the company, did we deliver what customers wanted today versus what they told us they wanted six months ago? How do we make our progress more visible to our stakeholders instead of the status reporting mails we send out?

Eventually, I read "Agile Project Management with Scrum" by Ken Schwaber. I've had the book since 2005 but never had the time to read or just didn't care enough to read it. What I read made sense, so off we go, we implemented Scrum and six sprints later we shipped the first version of our products using Scrum. In the next couple of posts I will chronicle our journey to becoming an Agile software development shop, the lessons learned, how it has changed software development project management at Vorsite, some of the challenges that still remain and how we are addressing them.