Skip to main content

Author: Robert Galen

The Young Whippersnapper Rule

Written by Robert Galen on . Posted in Articles. 5 Comments on The Young Whippersnapper Rule

I was working with a colleague the other day and we were talking about speakers for a possible local agile conference.

I brought up a few people that I respected in the national agile community and, almost to a person, they discounted them as being “the same old…same old” presenters. From their perspective, they were looking for more:

  • Fresh meat or new blood
  • Novel or breakthrough ideas
  • Something “different”
  • Out of the Box thinkers
  • More modern and energetic

And I think I understood the point. We can certainly get repetitious in our industry. Following the same old pundits with the same old messages. But at the same time, something bothered me and for quite awhile…and I couldn’t put my finger on it.

It First Starts With Respect

Another part of me felt as if my colleague wasn’t respecting those that came before him. So if someone is “repeating a tired, old message”, we can ignore him or her as the message is old and irrelevant. It reminds me of a quote I’ve heard—

“If I have seen further than others, it is by standing upon the shoulders of giants.”
Isaac Newton 

After a bit of time, I found that I disagreed with my colleague. I think we ought to respect those that have come before us. And we should try to glean the messages and the truths independently of the age or experience level of the practitioner or the number of times they’ve given the same message.

Just to bring up a few of what I consider ‘Giants’ in our field:

  • Gerald Weinberg
  • Timothy Lister & Tom Demarco
  • Tom Gilb
  • Watts Humphrey
  • Cem Kaner
  • Fred Brooks
  • Johanna Rothman

For example, Tom Gilb is an incredibly interesting character. He’s been talking about agile methods for requirements and project management since well before the Agile Manifesto was signed. Is he the newest, latest, fad in agile? No. Is he sending new messages and delightfully new insights? Perhaps not. But is he someone that you should pay attention to? From my perspective, unarguably yes. He actually does a fair amount of disagreeing with common agile practices, for example here in a video discussing issues with User Stories. But there is worth, wisdom and learning in his words that we shouldn’t simply discount.

In a similar vein, Timothy Lister & Tom Demarco and Fred Brooks’ lessons in software projects and project management are still as fresh as when they first started talking about them. We like to think that Agile Project Management is all about new, iterative approaches to building high-value software. But again, they’ve been talking about that same endeavor for over 25 years. And again, the words contain wisdom and value for building software today.

And on the softer side of team leadership, Johanna Rothman and Gerry Weinberg are still incredibly good references for people leadership in technical contexts. Sure, Jurgen Appelo has written a book called Management 3.0. And it sounds fresh, new, and much more relevant to todays teams—doesn’t it? And while it’s a fine and valuable book, Jurgen has distilled much of his guidance from others.

The Old Lessons ARE The New Lessons

But are the lessons always fresh and new? No. But I would counter that many of the old lessons are still incredibly relevant. Why you might ask?

Because we haven’t completely solved the problems!

For example, we still haven’t found that User Stories are the be all, end all, requirement artifact for software products. Are they interesting, lightweight, communicative and valuable? Yes. But requirements are STILL a challenge and many of the approaches from the past 25 or more years can help us learn how to adapt and improve our practices.

I believe that there is another quote that highlights this—

“There are no new ideas. There are only new ways of making them felt.”
Audre Lorde

The point being that old and new ideas are equally valuable IF we listen to, engage, ponder, and learn from them.

Wrapping up

I want to present the Young Whippersnapper Rule or the Latest Shiny New Thing Phenomenon here. I believe we have a tendency to listen to the latest new ideas or trends when it comes to technology and leadership approaches.

At one point, the Agile Methodologies were in that category.

And as we consider new things, we begin to move away and discount the older approaches. For example, the comment that – “you’re Waterfall and not Agile” has come to be a terrible insult in many contexts. But I’ve instead tried to respect the things that have come before me:

  • the people;
  • the repeated learning’s;
  • the variety of approaches;
  • the old ideas focused towards old challenges.

Even something I’ve struggled with as greatly as “Waterfall practices” has shaped my experience and approaches greatly. It has made me who I am. And there are lessons and wisdoms embedded within my Waterfall projects that are just as relevant, new and useful today as they were 30 or more years ago.

So from my perspective, I continue to learn from ALL voices in our community and I certainly respect those that have come before me. I’d encourage you to consider doing the same.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Software Teams: Throughput is ALL that matters!

Written by Robert Galen on . Posted in Articles. 6 Comments on Software Teams: Throughput is ALL that matters!

galen Sept24In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.

Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.

I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.

Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.

Compensation

We got paid by something they called “piecework”. That is, only completed boilers mattered coming off of our line. If a boiler unit was completed through packaging and final inspection, then everyone on the line would get a fixed figure for the type (size) of boiler they just produced.

If I remember correctly the per station, piecework rates were around $1.50 – $3.00 per boiler. Depending on our speed and the sizes of the boilers, we would make between 5-8 boilers per hour. Even though the work was very manual and hard, in the late 1970’s, this was a very attractive hourly rate.

It was also somewhat variable depending on how hard “the line” wanted to work. I recall during each Christmas season, we would refocus and nearly double our output. It wasn’t sustainable in the long term, but we could do it for a monthly ‘burst’, which served as a Christmas Bonus of sorts.

Of course the entire line had to agree to the increased effort and stress and this didn’t always happen.

Figure 1 – Assembly line flow

Flow

It turned out that individual productivity didn’t really matter so much. We were constrained by the overall capacity of the entire line. So, the slowest team member would always be the limiting factor.

Quite often it wasn’t simply performance that limited us, but other factors. Line members would come into work ill, injured, or not feeling very energetic and they would fall below their standards of performance. So there could be quite a bit of variability in the overall line’s performance.

Even breaks were an issue. It was almost funny in that line members were extremely reluctant to take bathroom breaks because it would affect the productivity of the overall line and their compensation.

If you were fast at your station, then you could “work ahead” for a bit and create a queue so that you could take a bathroom break without affecting flow. But only if your upstream partner could produce as quickly as your increased rate.

Quality

As I said, ultimately we were only compensated by finished boilers so quality was a significant factor. One way we all compensated for that was everyone knowing each others jobs. We would rotate jobs quite often so that each of us understood the role and responsibilities of each station on the line.

We then found who was ‘best’ at each station and we would optimize for them to working in the station where they would be the most productive. But, this understanding also allowed all of us to check each other’s work along the assembly line.

You see, we were also responsible for fixing the boilers we delivered with defects and these were not compensated at a piecework level. Instead, we received a very low hourly rate for all rework. So it was in our best interest to catch errors, defects, and omissions early and fix them as soon as possible.

It was a balancing act with speed/productivity versus quality, with everyone one on the line paying attention to overall product quality.

Ideas & Continuous Improvement

It may sound counterintuitive, but we were constantly tuning our processes. Sure, we were incredibly focused on our production and throughput, but we also spent time experimenting.

I remember one experiment was when I helped my upstream partner to build base units at the beginning of our shift. The idea was to build a large queue, because his station was the most sensitive to increased work time associated with larger and larger boilers.

The downstream partners would stock the other stations while we were doing this so we had sufficient materials for a long run. This became part of our pattern when we were

We also looked for novel tools and approaches for assembly. In some cases, manual tools were actually faster than their compressed air cousins, so we were always fiddling with our techniques and approaches.

Throughput was all that Mattered!

We really had only three measures that we (and the company) cared about:

  1. How many boilers of varying sizes did we produce each shift?
  2. How much rework did we have?
  3. How much money did we make per hour? (both in piecework and rework rates)

We tried to keep our rework at zero per shift and maximize our rates. This wasn’t always possible, but it was a goal for every shift.

One of the things that a focus on throughput influenced was working across stations. I’ve already said that we learned each other’s stations. But beyond that, we would help across each other’s stations during each shift as needed to keep the flow even and balanced across the line. If someone fell behind for any reason, even if we didn’t like it, we would pitch in and help out.

Why?

Because it benefited the line, our overall throughput, and ultimately our pocketbooks. We realized the only real measure that counted was what we produced as a line or team!

Wrapping Up

First of all let me say this. I fully realize that manufacturing boilers is significantly different than the knowledge work associated with software development. I’m not trying to demean developers or boilermakers by making the comparison.

However, from an agile and lean perspective, I see lots of correlation between the two. Which is why I’ve been reflecting back to those days lately. I see agile practices like:

  • Swarming
  • Whole-team quality
  • Innovation
  • Focus on throughput
  • Rework avoidance
  • Team skill balance
  • Stretching

Emerging from my experiences on the assembly line.

Beyond that though, the notion of piecework drove many of these behaviors—that and the assembly line logistics themselves. I wonder…

What if we only paid agile teams for fully done User Stories? Stories where they completely met the Definition of Done without any rework remaining? I wonder what behaviors that would inspire within the teams?

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

What Problems Are Executives Trying To Solve With Agile?

Written by Robert Galen on . Posted in Articles. 6 Comments on What Problems Are Executives Trying To Solve With Agile?

Image Source: Imdb.com

Mike Cottmeyer is one of my favorite agile coaches and leaders within our community. When he worked for VersionOne years ago, I used to read his blogs fairly often. Now that he’s been out on his own with LeadingAgile, I don’t get the chance as often to experience his thoughts.

So I was pleased when I ran into a recent post by Mike that had the same title as this post. I read it with anticipation, and as with all of his writing, Mike made me stop and think a bit. Here’s a context snippet from Mike’s post:

Well then… if empowering teams, inspecting and adapting, and handling emerging requirements isn’t the problem execs are trying to solve… what exactly *is* the problem they are trying to solve. Rather than guess, I’ve gotten in the habit of asking them. Most senior leadership teams will say something like this…

    • We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.
    • We are putting poor quality products into market, we think agile can help.
    • We need more transparency into what is going on.
    • We need more visibility into the progress we are really making on the product
    • We need to get products into market faster.
    • We don’t communicate very well, I hear agile can help us fix that.
    • It costs too much to deliver software, we want to use agile as a way to lower the cost to product the product.
    • We have way too much to do and not enough resources to get all the work done.
    • Support work is constantly interrupting new product development

Much less frequently, we’ll hear answers like the following…

    • We are trying to better understand our market and are putting out the wrong products
    • We deliver on time, on cost, and on budget but the product wasn’t successful in market.
    • We are looking for better ways of incorporating customer feedback in real time.
    • We are looking for ways to continuously improve our processes
    • We want to help people be more empowered to make decisions.

It’s not that this second group of answers aren’t important… it’s not that they never come up… it’s just that when they do, they are often secondary concerns. They are derivatives of first order concerns.

I’m actually not surprised that Mike is hearing the first list. Of course that’s what the majority of leaders are looking for. And I’m empathetic that they are searching for solutions to these challenges. When I was leading technology teams, from the late 1980’s thru 2012, I personally experienced all of them in a variety of forms. And frankly, it drove me crazy at times.

But what disappoints me a bit is the impression that they’re looking at “Agile” as a “Silver Bullet” that will address what are complex, organizational and systemic problems. These are problems that no mere framework or methodology will have a chance of resolving on its own. It’s this desire, and I may be overreaching a bit here, for a quick fix that disappoints me.

Why?

Because there are no Silver Bullets or quick fixes to hard problems. And any “fix” will require the engagement of this same leadership because most likely, they are a “part of the problem”.

To be honest, I get just as disappointed when leaders look at bringing in a tool or a consulting team as a panacea that will solve their problems as well. Sure tools can help and outside expertise is often valuable, but again, the leadership team needs to be “in the game” with the transformation and not just by paying the bills or initiating the idea.

Looking a Bit Deeper

Let’s take a few of Mike’s points that he’s hearing and drill into them a bit further…

We are constantly blowing past commitments, we need a way to fix that and do what we say we are going to do.

Absolutely. I agree. But, how are those “commitments” being made. Are your teams making them as you align them with your roadmaps and customer needs? Or are they simply being told what needs to be done by when by “management”?

You simply can’t force commitment and a simply having a job or receiving a paycheck doesn’t necessarily guarantee it either.

Instead, you want to enable a culture and environment where you support commitment and you support the process for your teams to get there. And part of commitment is acknowledging that things will change and there are no 100% guarantees. You have to be willing to trade things (scope) off as progress and discoveries are made. Remember, these are typically complex systems we are developing, which are notoriously hard to plan and predict exactly.

We are putting poor quality products into market, we think agile can help.

Why are you doing that? What do you mean by poor quality? In my experience, executives are often a factor here as they relentlessly drive the organization towards “more”, the message the team receives is that SPEED & DATES trump QUALITY. Agile will try to help with this, by reemphasizing quality deliverables at a team level. But delivering quality is typically hard work.

As a leader, you’ll need to “step down” and adjust your emphasis to be on quality over speed or dates. This may take a bit of time for your teams to realize the shift in your goals. But you’ll be surprised that when you successfully make this shift, with your teams, that you’ll get better quality and relatively increased speed as well.

We have way too much to do and not enough resources to get all the work done.

So if I get this right, a process model or type of SDLC will fix this how? This is the ultimate in Silver Bullet thinking. And beyond that, as a leader, you can actually do something here to help. You can either hire more people and/or prioritize the work so that the most important things actually align with your capacity. But clicking your heels together and hoping to “work smarter” or “get more done with less”, is never a viable strategy.

Agile, if implemented properly, it will force you to acknowledge the team capacity and ask them for the highest priority work that will fill their capacity. And yes, hold them accountable to deliver to their commitments to done software.

Support work is constantly interrupting new product development.

In many ways, support work is a side effect of our own doing. Clearly software isn’t perfect and has issues or drives usage questions. So support is indeed required. But my experience is that much of the support burden these executives are complaining about is driven because they established a culture where speed to market trumped doing things right and holding the line on product quality. Imagine that?

So when you don’t honor quality and release poor quality code, you get hit with high degrees of support and rework which derail your next release. And we all have heard of those repair cost models that discuss finding bugs by review vs. having your customers find them. It’s a pay me now or pay me later scenario. And most teams really want to deliver high quality code. It’s normally the business pressure and overall culture that forces premature releases.

What problems are executives trying to solve with agile?

All right, I may have rambled a bit too much, so back to the point.

I remember when I took my Certified Scrum Master certification with Ken Schwaber he said something along the following lines towards the end of the course:

People get frustrated with an introduction of Scrum thinking that it’s creating all of their problems. Scrum, or any of the agile methods, doesn’t create anything. But what it does do is show you your problems— often every day.

  • As a leader, it will expose to you organizational issues and other more systemic challenges.
  • As a team member, it will expose the impediments and realities of how well you’re delivering your software.
  • As a project manager, it will expose the faultiness of your planning and estimates, etc.

Then it’s up to you to do something about it. Reflect, examine root cause, and make a change. If you do you’ll improve. If you don’t, Scrum will bring it to your attention again tomorrow. It can be very frustrating—particularly if you’re looking for others to fix things for you.

So instead of creating problems, agility creates an environment where the problems are exposed and almost demand resolution. But not simply “team problems”. It will expose challenges that all levels of the organization need to face and resolve—including the leaders who have been giving Mike this feedback.

Wrapping up

Certainly I’m not dumping all of the responsibility on the leadership folks referenced in Mike’s post. I just want some of it to reside there. I’d much prefer that leaders move from silver bullet thinking to truly partnering with their teams. I’d also like them to take some personal responsibility to learn about the methods and the mindset of agility and to engage with it and their teams.

Additionally, I’d ask them to look at the problems that they identified as more holistic and systemic in nature and equally as much their problems as their teams. And finally, wouldn’t it be great if they rolled up their sleeves, with their teams, and got to work on improving things. And yes of course, as Servant Leaders and not Command-and-Control leaders.

Now is that too much to ask?

Stay agile my friends,
Bob.

Don`t forget to leave your comments below.

Project Managers Watch Your Language!

Written by Robert Galen on . Posted in Articles. 6 Comments on Project Managers Watch Your Language!

A rather long time ago I was in a meeting with a fairly senior development director and we were talking about annual roadmap planning. He was complaining about things. One of the things he brought up several times was race horses. He kept saying –

Bob, we simply don’t have enough race horses.

I became confused and a bit frustrated and I sort of lashed out saying –

What do race horses have to do with us meeting our software product goals for next year?
He said – no Bob, I’m talking about resources, not race horses.

After all these years, I still find this story both amusing and troubling at the same time. I think we often overuse the term resources as leaders, managers and project managers in software discussions.

Let me be clear. If you’re talking about people…say people. If you’re talking about facilities, equipment, and tools, then say resources. But don’t mix up the two.

Resources are often fungible. One chair is the same as another or one desk or one computer. You can list them on a spreadsheet and easily calculate how many of them you need to fill a specific space in your office. That’s fairly simple.

But people aren’t…so simple.

They’re unique. Uniquely skilled, experienced, enabled, empowered, and understood. No two are exactly alike. Oh you may think that developers, for example, are all introverted, but that’s a gross generalization that insults every software developer on your teams. And people are certainly not fungible.

You want to get away from thinking of people (or teams) as if they can simply be added or grouped together.

Another Distinction

Around 2005 I was a very seasoned software development manager who found himself looking for work. I’d been developing some highly sophisticated distributed trading system software for the global financial community—some really complex stuff. And to be clear, I was not only a good leader, but also a very good developer and architect.

But due to timing, I couldn’t find a leadership role in software development. Instead, a senior QA manager role came up at EMC and, long story short, I took it.

I remember in my first week I was invited to a design review for a complex piece of software that they were developing. I was the head of the QA team, so they wanted me to review and weigh-in on the system requirements and design.

But something strange happened in the meeting, something quite unexpected that took me aback.

The first thing I noticed that people stopped using my name. Instead they started calling me “QA” as in—what does QA think about that design decision? And how does QA plan on testing that component? It felt strange and demeaning in some way. I actually replied back that—

I didn’t know what “QA” thought about it, but here is what “Bob” thinks about it.

In that same meeting I noticed another thing. That folks were talking slowly when they tried to explain the ins and outs of their new product technically. And I mean v-e-r-y s-l-o-w-l-y. As if I’d dropped quite a few brain cells when I took the QA role or forgetting that I had a very strong product development background

Again, I attributed this to everyone laying my functional role on top of me and disassociating with the person. Now I look back and laugh about it. But at the time, it too was demeaning and frustrating. Particularly setting a bad tone for a new hire in a new culture.

And it is harder than it seems…

I remember when I was leading our teams at iContact. I tried very hard to refer to individuals or teams over functional silos. But every so often, I would refer to a function in an example or in one of my stories. I guess old habits are simply hard to break.

I would often catch myself and immediately apologize for the oversight to the group I was speaking with. I would literally correct myself right then and there.

I came up with an internal metric that I still try to hold to today. For every time I spoke to or about a “functional silo”, such as QA, I had to talk about individuals and the team for 9 times to undo the damage that the one misstatement caused.

You see I firmly believe our language matters a great deal. If we’re looking to foster highly collaborative, performing, and engaged agile teams, then we can’t talk about resources or “QA” or ‘Development”. It just reinforces silos, hand-offs, gates, and a lack of x-team collaboration.

Wrapping up

To wrap-up this article, I want to share some guidelines that might prove helpful in your interactions. While most of my stories were pre-Agile, I think the lessons and advice applies across methodologies and cultures.

  1. Stop using the term resources to apply to people. You should charge and collect a “fine” every time someone does it. Then treat folks to lunch with the proceeds.
  2. Stop referring to groups by their functional name, as in QA or Development or Architectures or Management.
  3. Stop considering individuals as being fungible in any way. Consider and discuss everyone is an individual.
  4. Stop using “magic numbers” to calculate team member availability, for example everyone is planned at 70% of their availability. Instead, ask individuals for their capacity.
  5. Stop considering one or two voices as being representative of the “opinions” of an entire group. For example, I like Planning Poker dynamics because it encourages everyone to voice their opinion.
  6. Stop allowing one group, developers in the team, to be considered done with their work independent of the entire team. Done-ness should be cross-team and cross-functional in nature. It’s a team output.
  7. When you’re approaching a near shore or outsourcing partner, don’t think in terms of resources and staff augmentation. Think in terms of partnership and put the same care as you do in hiring your own team members as your do with your partner.

The real point is that teams are composed of individuals. Let’s consider that in all of our interactions and not lose sight of the individual. I expect agile teams to behave respectfully in that way and everyone outside of the team should too.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Agile Release Planning Part 3

Written by Robert Galen on . Posted in Articles. 2 Comments on Agile Release Planning Part 3

galen March12I’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:
    1. Architecture, design, technical infrastructure;
    2. Efficiency of workflow, hands-offs, and dependencies;
    3. Any tooling or team-based work supporting needs, and training;
    4. Testing, regulatory, process, or documentation;
    5. Release concerns, scripts, or deployment documentation;
    6. 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

Don’t forget to leave your comments below.

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