Types of Agile End-to-End Planningstatic.squarespace.com/static/5046931284ae26412995236a/t/... ·...

Agile Release Planning End-‐to-‐End Project Envisioning, part-‐1 It was around 2004-‐2006 that I started to connect the dots between some traditional, but low-‐fidelity, planning techniques I’d been using and agile, or XP at the time, release planning techniques. I think it was the Kent Beck & Martin Fowler book that explored agile planning beyond the individual iteration.

Fast forward to today, and there’s a tremendous amount of discussion (and confusion) as to how release-‐level planning fits within agile methods and teams. I’m a Certified Scrum Coach (CSC) and as of the Summer of 2013, there’s still a lot of discussion in that community surrounding it. A good part of that is whether it fits into the definition of “Core Scrum” or not. I actually don’t think it does. Another part of the discussion is how it might map to Backlog Grooming, since there is estimation and workflow elaboration in grooming. Again, in my view, it’s not a grooming practice, but having a well-‐groomed Product Backlog does help your release planning.

I also think context matters when we’re talking about it. For example, if we’re leveraging Scrum or agile methods in a very small, start-‐up context, then I don’t know if Release Planning is all that useful. The teams are probably learning and pivoting frequently, so sprint-‐x-‐sprint planning is probably the right level as they triangulate towards their goals.

But there is a wide variety of contexts where sprint-‐at-‐a-‐time look ahead and planning is too simplistic of a view. Whether we like it or not, many organizations need some sort of release level planning and predictability. It’s just too hard to figure it out as you go. But at the same time, the organization needs to understand that these are flexible plans that will adjust as discovery and progress is made. They simply

need a roadmap-‐level or high-‐level view to where the team is going and what they’re planning on delivering.

What are the key focus points of Release Planning?

1. It gives the team a sense of the x-‐team and x-‐backlog interactions (dependencies) that need to be negotiated to deliver a product. This view is broad—from “release concept” to “released in production” timeframes.

2. It provides a tracking mechanism, establishing a baseline view if you will, so that every iteration or sprint can be compared against planned progress. Often this includes a “release level” burndown chart and an overarching set of release criteria or goals.

3. The thing I like most about leveraging release-‐level planning is the vision it provides everyone. It’s sort of akin to an architectural diagram at a project level. It’s the big picture and it gets everyone on the same page towards common release goals and functional targets.

In other words: you have directional awareness and a game plan before you—Let Loose the Hounds.

Release Planning – History and Approaches It turns out that folks have been doing iterative release planning since before the start of the Agile Methods. There’s quite a bit of commonality and overlap in the techniques. I view that as underscoring the value it has for the team. I thought it might be useful to highlight some of the techniques and provide follow-‐up references for each—sort of a compendium of approaches. I hope you find it useful.

Cards-‐on-‐a-‐Wall Dwayne Phillips published a Software Project Manager’s Handbook in 1998. One of the techniques he spoke to was a “Cards on a Wall” planning technique. It was a low-‐fidelity technique using 3x5 cards to represent all of the work related to a software project. You would stick the cards to a wall and move them around to represent the workflow. You would identify related work (dependencies) and often could use string to talk about critical paths within the flow.

It leveraged a whole-‐team view, so everyone (from architect to DevOps; leader to programmer; and developer to tester) participated in the session. It was truly and effort to get the Wisdom of the Crowd into a representative release plan.

I remember using the technique to plan a 100 person software project at Bell & Howell in 1998-‐99. It worked beautifully and the project came in on-‐time. The most effective part of the technique was the “shared view” it created for the team for the entire project.

References • http://www.drdobbs.com/cards-‐on-‐the-‐wall-‐sessions/184414750

• http://stickyminds.com/sitewide.asp?function=DETAILSIDX&tvniu=1&sqry=*Z%28SM%29*J%28MAGAZINE%29*R%28createdate%29*&ObjectId=5166&ObjectType=MAGAZINE&sidx=717

TSP Launch Planning Many years ago, also while at Bell & Howell I introduced the Personal Software Process to our teams. A few years after that, the SEI introduced the TSP or Team Software Process. While the PSP was focused on the individual developer, bringing rigor to their individual work, TSP looked at the team dynamics of delivering software.

The Team Software Process has a 4-‐day launch process defined that is a whole team approach to moving from a requirement list to a detailed, end-‐to-‐end plan. The final part of the launch is negotiating (resolving) the plans

References • http://en.wikipedia.org/wiki/Team_software_process • http://www.softwaresixsigma.com/Tsp_P_Launch.htm • http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=15&ved=0CD8QFjAEOAo&url

=http%3A%2F%2Fihuru.fe.up.pt%2Flgpr%2Flib%2Fexe%2Ffetch.php%3Fmedia%3D2010%3Atsp_team_organization_and_launch_process.pdf&ei=x_cZUv-‐DKYvq8gTe4IHADQ&usg=AFQjCNE1pn8MtO2ap2KF839DKqWNLrEthA&sig2=B1JGr_xdtIiMUx5kcLiz5w&cad=rja

XP & Scrum Release Planning I think many of us forget that the Extreme Programming folks had the notion of Release Planning as an adjunct to Iteration Planning. There’s also quite a bit of discussion in the Scrum community surrounding this notion. The two often “look the same” in implementation. Joe Little has written a nice “booklet” that describes his approach for it within Scrum contexts.

I think too many folks get caught up in whether it’s a “Core Scrum” practice and they lose sight that in a wide variety of contexts it can be a critical practice to guide projects as-‐scale. The envisioning, planning, tracking, and transparency aspects can be crucial for the team and leadership alike.

References • http://www.mitchlacey.com/blog/release-‐planning-‐in-‐agile-‐scrum-‐and-‐xp-‐projects • http://www.extremeprogramming.org/rules/planninggame.html • http://martinfowler.com/articles/planningXpIteration.html • http://www.techwell.com/2013/03/what-‐release-‐planning-‐and-‐it-‐still-‐needed • Joe Little’s e-‐book: http://www.leanagiletraining.com/blog/better-‐agile/latest-‐agile-‐release-‐

planning-‐ebooklet/

We’ll continue in the next post with a few additional planning techniques and then wrap things up. My hope is that you find these tools, techniques and thinking models useful in some of your agile contexts.

Stay agile my friends, Bob. * -‐ the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia. http://en.wikipedia.org/wiki/File:Chasse_a_courre.jpg

Agile Release Planning End-‐to-‐End Project Envisioning, part-‐2 Continuing on with end-‐to-‐end planning techniques within agile contexts –

Crystal Blitz Planning Alistair Cockburn’s Crystal method gets very little attention in the agile community. In many ways it’s one of the forgotten agile methodologies. So it hasn’t been well received as a method, but I like to “mine” Crystal for techniques and ideas to supplement my agile methods coaching. The notion of a “Walking Skeleton” from Crystal is useful in speaking about emergent software architecture. And in the release planning area, Crystal’s notion of Blitz Planning is useful as well.

The best description is in the Crystal Clear book. Blitz Planning is a multi-‐part, team-‐based approach to pull together a high-‐level view to all of the work (and supporting work) to deliver on a projects goals. It doesn’t prescribe a specific release interval (period, or set # of sprints). Instead it lets the scope of work drive the # of iterations in the Blitz Plan. That and the scope of work related to creating production-‐ready product.

References • Crystal Clear book -‐ http://www.amazon.com/Crystal-‐Clear-‐Human-‐Powered-‐Methodology-‐

Small/dp/0201699478/ • http://alistair.cockburn.us/Blitz+Planning • http://www.batimes.com/robert-‐galen/agile-‐bas...-‐don-‐t-‐go-‐in-‐without-‐tools.html

User Story Mapping Jeff Patten is the creator of this practice. David Hussman and he have collaborated on a refined the practice. It’s an exception to this list in that it’s not entirely a planning approach. It sort of is and it isn’t. The primary focus is on User Stories graphically not as a functional or requirement perspective, but as how the User will see, feel and use the system as it develops. I would consider it a UX technique.

It lays out your stories in 4 levels:

1. Backbone – stories focused on major functional areas of customer usage 2. Walking Skeleton Tasks – smaller stories that support the Backbone; a minimalist view to

functional requirements 3. Sub Tasks & Task Details – smaller stories that support the Walking Skeleton or finer grained

understand (for example, acceptance criteria). 4. Infrastructure – what I might call “glue stories” that provide infrastructure and support for the

Walking Skeleton. Typically dependencies.

I actually recommend doing User Story Mapping as an adjunct to Release Planning; usually before the planning. So the sequence becomes: Backlog creation & Grooming -‐> Story Mapping -‐> Release Planning. This way you’re putting customer problem solving and functional usage before actually planning iterative and release deliverables.

References • http://www.agileproductdesign.com/presentations/user_story_mapping/ • http://www.youtube.com/watch?v=XzaCaW8c3qE • http://www.youtube.com/watch?v=OdlipKmfCO4 • http://www.uie.com/events/virtual_seminars/agileux/

SAFe – Release Train Planning A relatively recent development in the agile community is a strong focus on Enterprise-‐level, scalability models. Dean Leffingwell has introduced the Scaled Agile Framework or SAFe. Scott Ambler has introduced Disciplined Agile Delivery or DAD. Craig Larman and Bas Vodde have co-‐authored two books and are working on a third that is focused on “agile at scale” techniques and practices. Ken Schwaber is starting to talk about Agility Path and Enterprise Scrum on the Scrum.org site. And there are still others that are getting into this space.

There has always been the venerable Scrum of Scrums model. It often gets overlooked because there is so little tactical guidance on how to effectively implement it. One reference for it is in my Software Product Ownership book.

Dean has long described a release model called the Release Train. It predates all of this enterprise-‐level hoopla and was simply an iterative view towards how to build and guide a series of iterations or sprints into a “shippable product increment” instead of a “potentially shippable product increment”. It turns out that there is usually quite a lot of preparation and work to release something that isn’t all about deliver user stories or features.

SAFe describes a 2-‐day Release Planning meeting that aligns with the Release Train and a Potentially Shippable Increment (PSI)

References • http://www.scaledagileframework.com/release-‐planning/ • http://www.scaledagileframework.com/program-‐psi-‐objectives/ • http://scaledagileframework.com/agile-‐release-‐train/ • http://www.scaledagile.com/launch-‐agile-‐release-‐train/ • http://www.slideshare.net/ScaledAgile/running-‐an-‐agile-‐release-‐planning-‐meeting • http://www.jrothman.com/2011/01/not-‐ready-‐for-‐agile-‐start-‐your-‐journey-‐with-‐release-‐trains/

Agile Project Chartering If you were to ask me – where do these sorts of techniques fit within agile project management, I would probably say this:

First, for straightforward or single team agile projects, many of these longer term planning activities are unnecessary. The regular planning activities associated with your agile methodology will take care of things. But, and I mean but, if you’re working on

• A distributed project or a partially or full outsourced project • A complex project • A multi-‐team project • A project with many dependencies • A project with Waterfall dependencies • A software plus hardware project • A project within a regulated industry • A project with large scale testing requirements • A risky project • A project that required some upfront design decisions

Then you might want to strongly consider these techniques. And not simply as part of some standalone effort, please no, but instead as part of CHARTERING your project. Much of this early, release level planning occurs during traditional project chartering phases of projects.

The book LiftOff by Larson & Nies covers quite a few approaches to agile chartering.

References • http://www.infoq.com/news/2010/05/agile-‐project-‐charter • http://michaellant.com/2010/05/18/how-‐to-‐make-‐your-‐project-‐not-‐suck/ • http://www.projecttimes.com/robert-‐galen/agile-‐chartering-‐beginning-‐with-‐the-‐end-‐in-‐mind.html

And you might want to read a more “traditional” book on software project management and chartering to gain a feel for the depth and breadth of solid chartering, for example, Wysocki’s book. Starting agile projects off is something that many agile teams skip—preferring to simply “dive in” and start sprinting. It’s often a huge mistake.

Wrapping Up I hope that this “walk” through a bunch or practices has helped you to understand that there is available wisdom, in some depth and breadth, surrounding agile planning. Sometimes I think we get to be so “agile” in our thinking that we forget some of the practices we’ve learned over the years and how useful

they are in specific contexts. So I hope I’ve inspired you to do some research and study and to consider agile project chartering and release planning as one of the tools that should be in your agile toolbox.

Between us, I rarely find a company or project context nowadays that doesn’t support doing a little chartering and release planning. While I might scale it down, not doing it is normally not an option to me.

Finally, I just noticed the other day that David Hussman’s videos are no longer being sold on the Pragmatic Bookshelf. These were professionally recorded sessions that at one point he was selling. Not sure what happened, but now they’re available for free on his website. What a remarkable gift for the agile community.

David Hussman’s video’s cover quite a few of these areas: http://devjam.com/2013/07/12/cutting-‐an-‐agile-‐groove-‐overview/ Highly Recommended!

Stay agile my friends, Bob, * -‐ the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia. http://en.wikipedia.org/wiki/File:Chasse_a_courre.jpg

Agile Release Planning, part-‐3 I’m going to do something strange in this article. I’m going to ask you to read another article first. The topic is Agile Chartering, but I think that may not have been the best of titles. Truly the article is about a group of agile teams who found themselves in a bit of a mess in a project and how they leveraged release planning to get themselves realigned with their stakeholders. I published it in the Agile Record, issue #12, November 2012, so you can get it there as well. Once you have that story “under your belt”, here I want to explore release planning from two perspectives. The first one will be the ideas of Joe Little and his view towards the focus and steps of release planning. Then I’ll weigh-‐in with my own version. As it turns out, they are quite similar, but there are a few important differences. In the end, I’m not trying to tell you Joe’s or mine is better. Instead, I’m presenting two relatively mature approaches to release planning since I find that having real-‐world examples or approaches is always helpful.

Release Planning – by Joe Little Joe Little is a CST in Charlotte, NC. I’ve known Joe for a number of years because he does so much training in our local area. Joe is a solid agile generalist, if you will, but he does have some areas of “special interest”. They surround applying lean principles within agile teams, determining business value, and release planning. It’s the release planning work that I want to expand on here. Joe recently spent a couple of hours discussing Release Planning with our local ALN Chapter group here in the Raleigh, NC area. What was interesting is that he did it without PowerPoint. What was even more interesting was his approach, which I’ll get into next.

The Goal of Release Planning One of the things I was truly happy to hear is an emphasis on the goal for a release. Joe spoke a lot about first determining a vision and aligning toward some view to a Minimal Marketable Release (MMR) definition. But before that, let’s explore the goal of release planning itself. Here’s what Joe had to say in his follow-‐up blog post:

To me, the main goals include…

• Increase the motivation of the Team (fingerprints, part of the creation) • Get everyone on the same page, seeing the same elephant. • Get alignment. • Sharing the tacit knowledge • Team building

Who knew the people were most important?

So the overriding purpose of release planning was team-‐ward. It involves, using Joe’s terminology, getting the “Elephant” well defined, aligned, and broadening the tacit knowledge around how to “attack it”.

5. The hipbone is connected to the thighbone.

Meaning: Everything we do is, to some degree, connected to everything else. For example, to deal with some issues, one can talk about a solution as part of ‘agile release planning’ or as part of Pareto-izing the work in the course of the Sprints. To fully understand ‘agile release planning’ one must really understand ‘everything else.’ And yet, we never have time to describe ‘everything else.’

I think the goal-‐oriented point here is (1) gaining a big picture as a team and (2) developing a shared view on the strategy the team will be leveraging for implementation. I agree with Joe. In fact, I believe that strategy is one of the key outcomes of any release planning effort, but more on that later.

The Steps, Sequence, and Activities in Release Planning It so happens that Joe has written a small e-‐book on his release planning approach and recommendations. You can find it on Leanpub, buy it, and download it in various formats. Basically it contains the following steps for release-‐level planning:

1. Vision – produce a vision of the product in general and specifically for the release itself – a MMR if you will.

2. Product Backlog – generate a Product Backlog (using PBI’s, User Stories, whatever); at this point it isn’t really organized or ordered in any special way.

3. Business Value – determine business value by playing value poker with your stakeholders. 4. Effort – determine level of effort by playing planning poker with your team. 5. Risks, Dependencies, Learning, MMFs, and other – consider these in your determination of

effort AND for potential ordering decision-‐making. 6. Ordering the Work – in the purest sense, Joe makes the point of factoring Value against Level of

Effort in order to determine a Bang for the Buck factor for each PBI. Then using this, you order the backlog. This is your first “iteration” for the Product Backlog.

7. Drawing the Line – based on historical capacity, velocity, gut feel, or whatever you have – draw a line as to what items will fit into the time the business allocates for the release. If the two are aligned perfectly, then fine. If not, you have some ‘splaining to do.

8. “Communications Plan” – and the explanations come via the communications plan. Up to this point, you can expect that the team has come thru one complete “iteration” and has “version 1” of their release plan.

a. ===== end of Release Plan #1 =====

9. The Fix-‐It Plan – this is less a step, but rather a model for thinking, as are the next two. Here we realize that the plan is not correct. Potentially it will never be “correct” so we agree to continue to examine, explore, and adjust / fix it.

10. Other things – a big part of fixing the plan is adding other concerns to it. Joe mentioned them earlier as risks, dependencies, learning, etc. Architecture, design, infrastructural needs, and technical flow would be a part of other considerations. As would prototyping needs, external, 3’rd party concerns, and hand-‐offs. As would testing infrastructure, automation, and functional vs. non-‐functional testing needs. Regulatory and process concerns would also fall here, and the list goes on.

11. Release Plan Refactoring – Joe mentions in this blog post that he doesn’t like the term Backlog Grooming, instead preferring the term Release Plan Refactoring. So this is the ongoing, grooming equivalent practices of constantly refreshing and adjusting the release plan.

I hope you got a feel for how Joe approaches release planning, but also the overriding goals for it.

One of my concerns surrounds his base goal, that release planning is more for the team. What I mean by that is, if you were an executive interacting with Joe and his teams doing this form of release planning, when would you be able to commit to the contents for a release? That seems to be a very “wiggly” proposition. Another way of saying it – it seems to be team centric and not plan or commitment centric. But perhaps that’s ok?

Release Planning – by Bob Galen I’ve been a proponent of release planning for an incredibly long time, probably most influenced by the following points:

• Early on in my XP experiences, around 1999-‐2001, most of those teams did a form of release planning. You can see it described in this book by Beck and Fowler.

• Again early on, I was fond of Cockburn’s Crystal methodology and it’s notion/description of Blitz Planning. This aligned nicely with my historical experience with similar practices I used with Waterfall approaches.

• And finally, I must admit, that the old message to leadership that “We’ll deliver it…when we deliver it” from agile teams was never very palatable to me. I understand iterative and agile development, but we DO need to communicate SOMETHING externally about our release intentions.

My thoughts and approaches on release planning come out in the article I asked you to read in the beginning. I’ve also written about and around them in my Scrum Product Ownership book. But let’s get into some high-‐level details so you can contrast this approach against Joe’s.

The Goal of Release Planning My primary goal for release planning is perhaps best articulated as 3-‐fold:

1. Establish a view to Vision, Minimal Viable Product (MVP), and Minimal Viable Release (MVR or MMR);

2. Establish an End-‐to-‐End view to a Body of Work required for a Release with your team;

3. Align what’s feasible with what’s expected and then establish a baseline plan to get there and commit to deliver.

Now the delivery is never a blood-‐oath guarantee of scope within a specific time frame. But it IS a baseline view where the team establishes a high to mid level view of the work and then plans the details sufficiently where they feel comfortable committing to the direction, content, and timing.

The Steps, Sequence, and Activities in Release Planning My activities align broadly with where Joe takes release planning. Let’s take a look:

1. Vision – the first step for me is to establish a MVP (Minimal Viable Product) and MMR (Minimal Marketable Release) definition for the release. I usually like to do this with an “In vs. Out” chart to facilitate feature choices and trade-‐offs.

2. Brainstorm Backlog – once we have clarity around the “initial Ask” for the release, I like to brainstorm all of the stories for the release backlog. This would include ALL stories and not simply functional ones.

3. Story-‐Mapping – The next step is to align the stories leveraging Jeff Patton’s Story-‐Mapping approach. I’m looking for the “usage or functional flow”, but also trying to establish a Backbone, Walking Skeleton and Supporting Infrastructure for it. I don’t necessarily like to do value poker, so this is step is actually replacing it, in that the order of the stories implies the value and any trade-‐offs.

4. Release Swim-‐lanes Layout – the next step from my perspective is to ask the teams to layout the stories into “Sprint swim-‐lanes” on a whiteboard, wall or tool of their choice. We still haven’t estimated the stories, but instead are using “gut feel” for the amount of work the team feels reasonably fits into each sprint. This aligns perfectly with the XP Planning Game.

5. Estimate – now comes planning poker. I usually try to get the team to stay at as high a level of estimation as they’re comfortable with. A common level would be T-‐shirt sizing of S-‐M-‐L. Next I ask the team to go through the release plan and estimate all of the stories. Along the way I’m looking for them to add, drop, or change stories based on the discussions.

6. Multiple Pass(es) – I want the team to take multiple passes through the release plan thinking of specific threads or areas of concern. For example:

a. Architecture, design, technical infrastructure; b. Efficiency of workflow, hands-‐offs, and dependencies; c. Any tooling or team-‐based work supporting needs, and training; d. Testing, regulatory, process, or documentation; e. Release concerns, scripts, or deployment documentation; f. Literally thinking of ALL work required to mature the release from “concept to customer

use”. 7. Team Agreed Plan – To exit the planning I’m looking for the entire team to go “thumbs up” that

they feel they have identified all of the work to deliver on the goal for the release MMR definition.

8. Negotiation, Re-‐Plan, Alignment, and Commitment – there’s always some re-‐planning when the team communicates the “cost” of the release MMR definition. I recommend that

negotiation starts with adding/trimming the MMR definition and aligning the scope with the number of sprints (date) the stakeholder can tolerate. The negotiation occurs on the MMR (high level scope items / goals) and Time (in terms of team or multi-‐team sprints).

9. GO – starting Sprinting 10. Scrum of Scrums – continuously review delivery TO the release plan and make adjustments as

each set of sprints executes / delivers.

Probably the biggest difference in Joe and my approach is I want the team to “exit” release planning with a complete view to the high-‐mid level plan and enough details to be able to “commit” to the plan as it aligns with the MMR. In other words, I want to establish a base-‐line plan vision that everyone can then start “tracking against” and making transparent “adjustments against”.

I’ve found that getting this level of alignment early truly helps the team communicate and manage expectations.

Wrapping Up Before I go further, I want to remind everyone that “release planning” is not a practice associated with Core Scrum. I do think it’s a highly valuable practice in quite a few agile contexts, but please don’t think Joe or I are saying every agile team or Scrum team must do release planning.

I think some of my key observations of Joe’s approach are the following:

• Vision centric, Team centric; • Plan and commitment lite; exploration and understanding heavy; • Heavy focus on business value; late binding other factors; • Release planning coupled to backlog and backlog grooming.

And a few on my own approaches include:

• MVP, MVR, and Vision centric; • Plan and commitment heavy; generate a base-‐line; • More intuitive view to business value; parallel consideration of “other factors”; • Grooming is separate from the release plan; but the release plan does change.

Joe has certainly made me think about my own approach. For example, am I too focused on creating a base line that doesn’t acknowledge the amount of ambiguity that is always lurking in agile – technical projects?

I actually think both approaches work. Truly the most important thing is THAT you release plan; how you do it is much less important. So here we explored two approaches and I hope you’re up to trying one of them or inspired to create one of your own.

Thanks for listening, Bob

References • Here’s an early version of Joe’s e-‐book references in this blog post. • There are some wonderful references at the end of the article I asked you to read in the

beginning, please look them over. • The notion of MVP, MVR, MMP, MMR, MMF, etc come from the Lean Start-‐up community.

* -‐ the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia. http://en.wikipedia.org/wiki/File:Chasse_a_courre.jpg

Types of Agile End-to-End Planningstatic.squarespace.com/static/5046931284ae26412995236a/t/... ·...

Documents

Transcript of Types of Agile End-to-End Planningstatic.squarespace.com/static/5046931284ae26412995236a/t/... ·...