Personal Value Stream Mapping

September 3, 2010

As a project manager, a scrum master, a team lead, or even as an agile coach I’ve wondered from time to time about the true value that I bring to a team. You see, to me it is entirely plausible that a team could work just fine without any of the aforementioned roles being present. In fact, I know that there are many teams that are quite successful without a project manager on the team. That goes for scrum masters too. It has always been a difficult question to face with any intellectual honesty.

Recently I picked up Mary and Tom Poppendieck’s latest book, Leading Lean Software Development. She uses frames to illustrate some of the successful and unsuccessful approaches to software development over the last 40 years. She deals rather harshly with what she calls the Project Management Frame. Basically, if you accept their take on modern project management it is wrong-headed on a number of different levels and is the source of a great deal of waste and very little value in the overall business value stream. Speaking as someone who basically operates in this role, it’s a pretty harsh toke. Having spoken with her about it, I get the impression that when she talks about project management, she doesn’t make any distinction between scrum masters, XP coaches, or traditional project managers. They are all separated from the work and using “management” to manipulate or measure the teams with metrics that at best serve no useful purpose and at worst cause a great deal of harm. Now I know there are those who might argue these points vociferously, but Mary and Tom are pretty darn smart, so I think there is some merit in considering their viewpoint seriously.

What value do project managers provide to the business value stream? Please note that I’m using the term project manager very loosely. It includes Scrum Masters and other leaders of that ilk. Well, perhaps the best way to answer that question would be to build your own personal value stream map. Take a recent project and see if you can list all of the activities that you engaged in as part of delivering that project. Line ’em up in chronological order, identify the wait steps and the queues and see what your personal efficiency, from the perspective of the team value stream is. It might look something like this:

  1. Release Planning
  2. Sprint Planning
  3. Daily Standups
  4. Retrospectives
  5. Reviews/Demos
  6. Resolving Impediments
  7. Release Coordination
  8. Change Control
  9. Tracking (taskboard, etc.)

So…if I look at that list, what activities are value adding from the customer’s perspective? Oooh, that might be a pretty short list:

  1. Reviews/Demos
  2. Resolving Impediments
  3. Release Coordination

All the other stuff is just “process” overhead without any intrinsic value. That leaves a pretty darn short list. Facilitating reviews/demos is certainly not much of a unique skill. You can do that without a PM. Easy. How about resolving impediments? Well, that sort of depends on how many you resolve…and even then, resolving impediments is not the exclusive domain of the PM/Scrum Master. Finally, there is only release coordination. Some people do that, others don’t – it depends on the organization. And does release coordination represent value to the customer? Would they pay for it? Maybe…

Perhaps that’s a brutal assessment of the value of a team leader. I tend to be that way. Others may be more forgiving. What it tells me is that, at least in my case, if I’m not eliminating a LOT of impediments, I’m probably not contributing much direct value to the team. They really don’t need me for those other activities. It’s the impediment removing that represents the real value. And you don’t need a PMI certification to remove impediments…or a CSM certification…or a title…


Frequent Small Releases

July 11, 2008

With scrum, we try to deliver business value every sprint. That’s easier to do with some projects than others. If you have a mountain of technical debt facing you, delivering business value every three or four sprints can be a huge achievement. You might get lucky and find the occasional creative way of delivering business value quickly and easily, but most of the time you simply aren’t going to be able to manage it. Forget about it.

There are a lot different factors that make up a technically mature team, and they often take a long time to put together. Until you overcome those lower level issues, you won’t be able to properly address the higher level issues related to delivering business value quickly. Here is a graphic that I use to help make my point:

There are different levels of technical competence that need to be in place in order to support the rapid delivery of business value. If any one of these levels is missing, it is very unlikely that a team will be equiped to manage their work efficiently enough to deliver business value on a rapid and consistent basis. Teams need to be using source control tools and practices. Until they have source control, a team will not have the technical foundation in place to begin to put continuous integration in place. Once you have continuous integration working, you really aren’t getting the full benefit unless you can provide automated tests with every build. So on the technical side, a team has to have a lot of infrastructure in place in order to even think about delivering business value quickly.

There is another side to this issue that is very much tightly releated – how large are the releases that we make? Here is another diagram:

Here, instead of talking about technical maturity, we are looking at deliverables. At a relatively low level of process maturity, a team is really only capable of delivering files and resources with any real frequency. As the team becomes more technically adept, they are able to deliver components more frequently. As you can see, as the team becomes more and more efficient, they are able to deliver features and ultimately meaningful business value on a rapid schedule. These two hierarchies, the technical maturity and the deliverables maturity are linked tightly together.

So what’s the point? Well, if you are working on a team that is just adopting agile, don’t let anybody tell you that you are going to be delivering significant business value frequently – especially if you are like most teams and have a fair amount of technical debt accrued. It’s not that you can’t get there – you can, but it’s probably going to take a lot of work before you are able to deliver on that promise. People tend to expect immediate results when they switch to agile, and I’m here to tell you that often it just doesn’t work that way. If your teams are anything like the ones that I have worked on, you have a significant number of technical, personal, and other issues to overcome before you are going to be able to deliver the promised frequent delivery of business value. It’s definitely the way to go – I’m not saying it isn’t worthwhile, I just think expectations should be reasonable.

In the meantime, instead of trying to deliver business value every 5 mintues, why not focus on Frequent Small Releases (FSR) instead? Yeah, you heard me right. Learn how to deliver something – anything – frequently first. It’s all part of building a mindset of frequent releases that will ultimately (once the team is ready) culminate in the hallowed goal: the frequent release of business value.