Hyperproductivity in Scrum

Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.

According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:

"We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience."

Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:

"The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of points completed is the baseline velocity."

When I first read that, I was like "what am I missing here". Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn't strike me as a very fair metric, you'd think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.

But here is their key assertion that supports the measurement:

"At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative"

I don't know about you guys, but I'm kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I'm not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren't. It might also be interesting to see the team stabilize first, and then see how much better they'd get by systematically removing impediments.

These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?

BTW - I loved the image here... seemed pretty much with the Shock Therapy theme. Check out the artists website at http://llynhunter.blogspot.com/2008/05/electricity-if.html

Subscribe to Leading Agile

Subordinating the Scrum Team

Agilists intuitively get that it's a bad idea to build an inventory of detailed specs way ahead of when they are going to get turned into software. Why? Because we know that as our product emerges, we are going to want to make changes to those requirements. There is a real risk that a lot of that work will end up being waste. That's a big part of why we document agile requirements as user stories... we want the placeholder now, but we don't need the details until we get closer to building that part of the product. It keeps our options open and our overhead low.

Building an inventory of requirements has a more insidious impact than just opening up the possibility of waste. Sure, we risk specifying stuff that the business might not need, but we also build in assumptions and risk that can't be validated. Everything that we define now, everything that can't be built and tested immediately after specification, represents something that we'll have to validate or mitigate somewhere down the road. Those uncertainties make it really hard to forecast when we are going to get to done. They make it tough to be predictable.

Furthermore, requirements gathering an analysis shouldn't be done in a vacuum. We know that we're going to want some help from our development team to discuss what's possible from a technology perspective. When we pull our team into meetings to discuss these things, we are taking their attention away from the task at hand. Our team is working on the highest priority features, and here we are pulling them away to help forecast lower priority requirements that may or may not ever make it into the product. It's a pretty solid formula for going slower than we have to.

Even though we may have some capacity to do the requirements work... and it would be nice to get ahead of the game a little... it is not something we generally do on agile projects. Managing all those requirements changes, tracking all those assumptions and risks, and absorbing all the productivity impact to the development team is just too great a cost. We KNOW it is going to cause us problems down the road. Any benefits we'd gain from getting ahead of the requirements work would be lost due to the overhead necessary to maintain our requirements inventory. That inventory slows us down and makes us more resistant to change.

We understand... in this kind of a scenario... that the team has to subordinate the requirements gathering process to the overall production cadence of the delivery team.

Now, let's extend this metaphor up a little and talk about our financial services company... and specifically our new hyper-productive Credit Card Processing Scrum team. With regard to the rest of the organization... our Scrum team is able to produce working software much faster than everyone else around them. The question we're dealing with is... SHOULD they produce working software much faster than everyone else around them? In this context, under this set of circumstances, I'm saying no.

I'm suggesting that the Scrum team in our complex product organization becomes very much like the requirements gathering function in our earlier example.

When the Credit Card Processing team builds software features faster than the rest of the organization can consume those features, they risk the possibility of waste and rework. They introduce assumptions and risks that have to be managed and mitigated throughout the life of the project. They will disrupt the other development teams around them and force those teams to multi-task. The other teams will be forced to pay attention to features that they won't be ready to build for another several months. All that code will slow us down and make us resistant to change.

While it is technically possible for the Credit Card Processing team to get a head of the game... and it might make them feel more productive... it might be great for their team morale... ask yourself what impact they are having on the rest of the organization. It might not be as positive as you think. So... for all the same reasons you might ask a PO or a BA to slow down writing requirements to fill the product backlog, you might want to ask your Scrum team to slow down building software until the rest of the organization can catch up.

It's counter-intuitive, but if you start thinking past the single team, it might be exactly what you need to do.

Subscribe to Leading Agile

There Are No Spherical Chickens!

Just in case you are wondering... I'm not suggesting that our Credit Card Processing team shouldn't do Scrum. I'm not suggesting that they shouldn't improve. What I am suggesting, is that if the organization stops with this one team, they won't get the business benefit from Scrum that they expect. All the value created by the Credit Card Processing team will be obscured by the underperformance of everyone else. Furthermore... you shouldn't be surprised when your Scrum team gets downsized, outsourced, or reorganized... just like everyone else who didn't deliver.

If you don't have the ability to influence the rest of the development organization, it probably won't make any difference if the Credit Card Processing team adopts Scrum. Sure, the team will probably enjoy their work more. Maybe if they get really good at delivery, they can jump in and help out some of the other teams. If the culture is open enough, maybe everyone else sees the benefit of Scrum, and they become the catalyst for more widespread adoption. That just hasn't been my experience with this kind of grass roots hopefulness.

Most large companies I have worked with are full of silos, full of politics, and full of protectionism and fear. Accountability structures don't necessarily reward working well across teams. Incentives are geared toward individual performance first, and team performance second... if at all. Organizational or divisional objectives are so far off people can't directly influence them. We are allowed to build empires that only serve to grow the headcount in our particular group, often at the expense of our ability to work well with those around us.

The thing we most often forget when adopting agile, is the impact that agile needs to have on the culture of our organization... and the impact it needs to have on the fundamental structures that reinforce that culture. So... I have to tell you I am a bit cynical about the whole... give agile a try and everyone will be enamored with it's goodness routine. Most people would rather try to be individually successful in the system they know, than risk being unsuccessful trying something risky and new.

In a complex product, all the pieces and parts have to work together to deliver end business value. If you agree with that fundamental premise... and you are willing to agree that team level adoption does not typically spread (unintentionally) out to the rest of the organization... you are left with two options. You can 1) subordinate your Scrum team to the delivery cadence of the rest of the enterprise... or 2) plan to systematically introduce Scrum everywhere else, and learn how to manage the flow of value across the various Scrum delivery teams.

I am clearly in the camp of option 2.

Before we wrap for the day... I want to go back to why I think this topic is so important. A year or so ago, Ken Schwaber famously said, and I paraphrase: '75% of the organizations using Scrum won't get the benefit that they hope from it". If you care about agile, and you believe in the value that it brings to people and teams, and you have seen it work, that is a really depressing statistic. Our community's response seems to be... get more dogmatic about Scrum. If you aren't doing Scrum by-the-book, that is why you are failing.

I'm sure there is some of that going on, I am sure that there are some people bending Scrum to hide their dysfunction. My take is that this complex product idea strikes more the heart of why the underlying dysfunction exists. Vanilla Scrum does not work for these organizations because the value stream is bigger than a single team. Rather than assume that we live in a world of spherical chickens, I'd like us to explore how agile works, why it fails, and most importantly... what are our options for making things better when we can't wave a magic wand and change our cultures and structures overnight.

So... in the context of our financial services organization, and our Credit Card Processing team in particular... I want to explore a bit more why, in the absence of a broader change initiative, you have to subordinate their performance to the cadence of the rest of the enterprise. After that we'll get into how to scale Scrum from the single team, to multiple teams, to projects and portfolios, and then the enterprise. We'll explore blending approaches, how to leverage Lean and Kanban, and how to deal with multi-tiered values streams. We'll talk about how to break down requirements, deal with architectural challenges, how to do planning and context setting, etc.

I might take me a while... be patient.

Subscribe to Leading Agile

Can I Do Perfect Scrum and Still Fail?

If you're not keeping up... you've got some homework to do. My last post called "What Do I Mean by a Complex Product" is required reading before you read this post. If you've got a minute, go read that post and then come back to this one... thanks! - Mike

Okay, so let's explore our Credit Card Processing team a little more. They are in a large organization that is delivering large, complex products. They know that the traditional way of planning and building software isn't really working. The big up front requirements analysis and the the big up front design is really slowing the organization down. It routinely takes 18 months or more to bring any new product offering to market. This company is at risk of having smaller, faster competitors take their market share. This team wants to do something about it.

They've heard quite a bit about Agile and Scrum and like the idea of getting to hyper-productivity in just a few iterations. Let's say that this team moves mountains and gets everything they need to be successful... they get the team through agile bootcamp and bring in a coach... they get a top-notch product owner, identify a scrum master, they build the ideal cross functional team, they do all the right XP practices, they do iteration planning, daily standup meetings, demos, and retrospectives.

This is a team that would make Ken and Jeff proud. No Scrum-but here.

The product owner does a great job working with all the stakeholders... both her external customers and the other product managers in the organization. She balances the needs of her market with the needs of the other products that are dependent on her product to be successful. She crafts a backlog that is full of the right features, in the right order, to get everyone all the features they need when they need them. The team starts building... and starts getting really good at delivering done-done software every two weeks.

Just as it should be... right?

We'll... yes and no. The PO for the Credit Card Processing team is probably doing a great job satisfying the needs of her Credit Card Processing customers... that is a good thing. It also sounds like she is doing a great job meeting the needs of her internal stakeholders. But what about that new Payment Processing product that the business is counting on for a significant part of next year's revenue? How has Scrum impacted the overall flow of value for the entire company? The short answer is... it hasn't.

Clearly, this Scrum team has done it's part. I'm not even suggesting that this is a Scrum problem. But, if the Payment Processing initiative fails, where does that leave our Scrum team? It leaves them in the same boat as everyone else... downsized, outsourced, and reorganized.

But Mike you say... what else can I do? The only part of the system I own is the Credit Card Processing engine. I'm doing the absolute best I can with what the people and resources I have been given... I have been successful to the best of my ability. You know what... you're right... you have been successful to the best of your ability. That is what is so frustrating with localized Scrum implementations, it just doesn't matter how good you do Scrum. How well your team adopts agile doesn't matter... how well you adopt Scrum doesn't matter... at the end of the day, all that matters is the value the business get's from your efforts.

In this case, they didn't get the ultimate benefit and the Scrum team suffered. Here is what you have to keep in mind... if the system is bigger that your Scrum team... if the enterprise value stream requires more teams that just yours to deliver... you need to take that into consideration as you adopt scrum. Getting good at team based agile is NOT ENOUGH when it comes to adopting agile in the enterprise... it is NOT ENOUGH when you are part of larger, more complex products. All the pieces have to work together.

We'll unpack this more over the next few posts... for now, let me know what you think.

Subscribe to Leading Agile

What if I'm Not the Constraint?

What if you are a manager that wants to do Scrum? You ask yourself if it's possible to encapsulate the entire value stream into a single Scrum team? What if you learn that the answer is no? What if you think this through even further, and discover that your team is not the constraint? Does it makes sense to even give Scrum a try?

What if give Scrum a try and are wildly successful? Your team becomes hyper-productive and potentially disrupts the overall balance of the system. Is that a good thing or a bad thing? It might be great for your team and their morale... but what about everyone else? Will everyone else benefit from your hyperproductivity... or will it actually slow them down. What did Goldratt teach us about what happens when one part of the system overproduces?

Consider this for a minute... if you are a senior leader looking to transform your organization to Scrum... where should you start? Start by figuring out how you create value, and what teams are constraining value... and pilot Scrum there. That way Scrum will be tied to something that actually helps the overall system get better at creating actual value. It's not overnight transformation, but it is a way to help deliver real value.

If you are a team that wants to do Scrum, understand your upstream processes and downstream processes. Don't produce software any faster than you can receive quality inputs from the upstream groups, or faster than your downstream customers can consume quality outputs. Building software faster than you have requirements, or faster than your software can be consumed is waste. It's might not be hyperproductive, but it is respectful of the overall system.

Ideally you want a blend of both... you want to see bottom up adoption with top down intent. What does this mean? Understand your system... understand how the system creates value... identify the constraints in your value stream... build Scrum teams around the constraints... build on your success at the single-team level to systematically spread Scrum to new teams that are focused on the newfound, value oriented constraint.

With this approach, hyperproductivity can be encouraged while we simultaneously focus on actual end-to-end value being delivered back to the business. I'm all for teams owning the entire value stream... I am all for overnight top-down, bottom-up transformations. I'm also for doing things that make sense and managing risk along the way. I'm not so big on pretending, or hoping for things to be different, without a well designed strategy for getting there.

Subscribe to Leading Agile

Vanilla Scrum and Multi-Team Value Streams

Okay... so what if my value stream isn't encapsulated within a single Scrum team? What do I do then? To some degree, I think it depends on how much of the value stream is outside the team. If external dependencies are the exception rather than the norm... or they can be easily managed and tracked... and they don't really impact the teams ability to establish a stable velocity... I might go with Vanilla Scrum and just work really hard to make sure that the dependencies were very well managed.

If external dependencies are the norm... if they can't be easily managed or tracked... if they tempt you to want to build Gantt charts or dependency spreadsheets... and they seem to impact your team's ability to establish a stable velocity or deliver value... this is where you need some serious transformation work. You really need to redesign your entire organization in such a way that the external dependencies become the exception to the rule.

I think this is where most Scrum evangelists find themselves. When they talk about cross-functional feature teams that deliver value to their customers every sprint... they are really saying that we want an environment where the entire value stream is owned by the team. Product owner has unilateral decision making authority on what... the teams owns the how... and the delighted customer gets working software every sprint.

Like Glen Alleman says over on Herding Cats... that is great work if you can get it.

Most organizations aren't there... and unless you have the ability to retool the entire organization in a way where the teams can own the entire value stream... I think unmodified Scrum is going to fail. Even if the team is successful, they become that sub-obtimatization I talked about in my last post. The good news is, we have options at our disposal that go beyond just doing Vanilla Scrum and fail trying.

I find myself, more often than not, advocating for Scrum or Kanban at the team level... and almost always Kanban at the product or enterprise value stream level. Now we can start talking about managing the organization end-to-end using a flow of value metaphor... we can identify our constraints... we can choose not to start work we can't finish... and we can apply our limited resources where they are most likely to help get value out the door faster.

Like I said... I think there is a time and a place for Vanilla Scrum. I just want us to think through the problem and really look at why so many aren't getting the value they expect from Scrum. If we need to augment what we know works in Scrum with what we are learning works in Kanban... and maybe even a little about what we already know from AUP and DSDM... why not? Maybe if we can find reliable transition patterns, maybe someday we can get to our single Scrum team utopia.

For now... I think we need to be somewhat pragmatic... meet teams and organizations where they are... and help them get to where they need to be. Most of our teams need tools beyond what Vanilla Scrum is prepared to offer.

Subscribe to Leading Agile

Will Vanilla Scrum Work for You?

In the midst of all the methodology wrangling... I've always felt that there is a time and a place for Vanilla Scrum. The problem is that most of the time, folks are giving vanilla Scrum a try when Vanilla Scrum just isn't a very good fit for their organization. So that begs the question... when is it safe to apply Vanilla Scrum in your environment?

Here is my take, borrowing a little language from the Lean/Kanban community... ask yourself, can your entire value stream be encapsulated within a single Scrum team? If there are steps in your process that happen either before your team starts, after your team starts, or you have dependencies on other teams during the development lifecycle, Vanilla Scrum probably isn't going to work.

Giving Vanilla Scrum a try without understanding your entire value stream, only results in the dev team being a local optimization in the larger enterprise. When I'm talking to clients that want to do Scrum, this is the first question I ask. If more than one team is at play... chances are I need more than Scrum to be successful.

Subscribe to Leading Agile

Getting Started with Agile... Two of 'Who Knows'

Okay... way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called "Getting Started with Agile... One of Five". There is a bit of irony here around how this post came to pass.

I did almost all of this post two weeks ago. The post got really long. There were a few parts I was still hammering out, a few parts I still am as a matter of fact. The whole post sat on the shelf waiting for the unfinished parts. This morning I decided to break the post in smaller parts and start releasing it in chunks... pretty smart huh? ;-) Amazing how sometimes it is hard to eat your own dog food!

Here goes...

At last year's Scrum Gathering in Orlando, I heard Ken Schwaber make the comment that in his opinion, over 75% of all organizations using Scrum won't get the benefit they hope from it. That is a pretty depressing perspective, especially coming from one of the guys that invented Scrum. I don't know about you, but I am pretty convinced that this agile stuff works. I've seen it work, and I've seen it work well. If we know agile works, why do we have so little confidence in our ability to make it stick in most organizations?

Personally, I am not prepared to believe that Scrum's failure rate is because people don't implement Scrum properly. That's the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it's pretty hard to really do it wrong. That said, I do believe that many organizations aren't prepared to fix the organizational disfunction that Scrum is going to show them. Scrum's primary benefit is that it shows you the stuff you need to fix. If you aren't willing to fix the problems, you aren't going to get the benefit.

How many companies using Scrum are really trying to transform the entire enterprise? I'd wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber's 75% statistic.

For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn't get it. The value delivered by the Scrum team just get's lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.

So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn't performing very well? What do you do when Scrum helps you identify an impediment that can't be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn't matter how hyper-productive your team becomes... getting higher team velocity isn't your biggest problem.

The trick to adopting agile is to form a team around a business problem the organization actually cares about solving... one that will increase bottom line performance. And this is where the conversation get's interesting. Many of us aren't responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.

There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value... how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.

Next post we'll talk about a few 'units of production' that I see larger organizations really care about.

Subscribe to Leading Agile

Cory Foy Nailed It

Cory Foy does a great job giving us some insight into the recent history of the Scrum Alliance, especially as it relates to current efforts around developer certification. He also does a great job getting to the nut of the issue we are talking about here, something I am clearly struggling with. Cory's point? The Scrum community is fractured and trying to get some stuff figured out. Personally, I think that's a fair assessment.

Cory also wants us to acknowledge that most Scrum practitioners are in the software development space. He wants us to stop trying to be all things to all people. He wants us to get down down to the business of building software... the best we know how. I support that direction 100%, and in that context, totally support defining a set of developer practices that are a good idea on most projects, most of the time. I might even support a certification.

So why does all this matter? Here I am going to quote Lee Henson quoting the most recent series of Spider Man movies... "with great power comes great responsibility." Like it or not, most people equate Agile with Scrum. Many people, especially the new ones, don't realize that Scrum certification is only a two-day course. Lot's of people think that when you call yourself a master of something, you have some idea of what you are doing.

Scrum's positon as the preeminent Agile methodology... or framework... or whatever you want to call it, puts it in the position to have precious little time to dork around. I think that if the Scrum community doesn't get things figured out... and soon... we are going to see other groups rise and take Scrum's preeminent role. How many of you guys stopped watching baseball after that strike a few years ago? I did.

We don't have time for in-fighting... we have companies to run and software to build.

Subscribe to Leading Agile

Sacred Cows?

I have to say, I've been a little surprised by some of the responses to my last post on Scrum Certification. For the record, I'd like to restate my position as simply and with as few words as I possibly can:

1. Scrum is a simple framework for empirical process control. That is why it is so effective.

2. Scrum does not tell us how to write code or how to be good product owners. It is up to us to bring our knowledge and experience in ways that are unique to our context.

3. I do not believe it is right to offer certification when there is not standard or a published set of competencies. We should not certify more than Scrum is willing to include in its body of knowledge.

I am all for holding classes that teach us how to be better developers and better product owners, and even better ScrumMasters. I do not believe this training should be called certification.

That is my point. If my point makes you angry, just remember... sacred cows make the best hamburgers!

Subscribe to Leading Agile

Product Owners in Practice

At the risk of being accused of bashing Scrum for the second time this week, I want to talk a little about the Product Owner role. What I want to explore a bit is why the Product Owner is such an important construct in Scrum... and furthermore, why it is difficult for so many organizations to really fill it well.

The Product Owner is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. The Product Owner gives the team unambiguous direction and ensures they don't have to worry about conflicting business priorities.

As a community, we seem to be backing away from the idea of a Product Owner as the single wringable neck... but that's really the whole point, isn't it? We need to have ONE person that is RESPONSIBLE for telling the team what to build. Without it, how are we sure we are building the right product? How do we know the person defining the backlog can singularly and authoritatively guide the output of the team?

In reality though, how often does one person really own a product? If there really is one person that owns the product, how often does that person have time to sit full time with the team? Is it realistic to ask the real Product Owner serve as Product Manager, Project Manager, and Analyst? Is it realistic we can have one person own the vision and guide the execution in any but the most trivial of organizations?

As Scrum goes more mainstream, there seems to be acknowledgement that most of the time, we have multiple people filling the role, most of whom are merely proxies for the real decision makers. If this has become the norm, if we don't have a single authoritative voice to guide the team, if we don't have a single person that decides what to build, what is the point of having a role called Product Owner anyway?

I wonder if most of us are even honoring the basic principles behind why the Product Owner role was created in the first place? Are we bending Scrum because the demands it places on us are just too great?

So again, I find myself asking questions like... if the PO doesn't really OWN the product, are we bending Scrum past it's acceptable limits? If we have several stakeholders in a PO team, are we doing Scrum-but? Do I REALLY have to empower a SINGLE person to be ACCOUNTABLE for telling the team what to build? If I don't am I really doing Scrum? Where are the limits? What defines acceptable adaptation?

So... I think what is nagging me here is a growing dissonance between what you might call textbook Scrum, and Scrum as practiced in most organizations, by most people I talk with. I don't want to bash Scrum, I want to reconcile how we teach it, how we certify it, with how it is generally practiced. And by all means, if we are going to certify these adaptations, I'd like to see us start including them in our body of knowledge, however lightweight or informal.

Subscribe to Leading Agile

Having Your Cake... Some Thoughts Around Scrum Certification

To some extent, I think that Scrum is going through an identity crisis. Part of what has made Scrum so successful is its simplicity. We've got three roles, three ceremonies, and three artifacts. That's a pretty refreshing idea to those of us that came out of much more heavyweight methodologies. Scrum has a simple elegance that is easy to communicate and easy to sell.

The Scrum community is full of some really smart people. If you've been building software for more than 10 minutes or so, you know that Scrum doesn't tell you everything you need to know to be a good software engineer, a good tester, a good business analyst, or even a good ScrumMaster. It is up to us to bring our skills and experiences to the table and fill in the gaps. We figure out how to make it work.

So here is what I want to know... if Scrum is a simple framework... if it is so clear and precise that we can talk about Scrum-But and call out those people that aren't doing it right... where is the definitive body of knowledge? Where is the documented set of stuff that is acceptable on most Scrum projects, most of the time? How do I tell the difference between when I'm bending Scrum to hide my own disfunction versus just filling in the gaps? Who gets to decide? Am I just supposed to know it when I see it?

This identity crisis becomes really apparent when we start talking about Scrum certification. What is there really to certify when the rules of Scrum are so simple? Not much. What about when we start offering specialized certifications like the Certified Scrum Product Owner? What does Scrum really teach us about being a good Product Owner? In my opinion, not a whole lot. How about a Certified Scrum Developer? That role doesn't even exist in Scrum. Furthermore, does Scrum say anything about good development practices? Not at all.

Scrum can't have it's cake and eat it too. It can't be a simple framework that is not prescriptive and then start certifying people on how to do all this stuff.

If we are going to acknowledge that there is actually a set of generally accepted practices that work well with Scrum, let's start building our body of knowledge and open up Scrum to public debate. I just can't get my head around certifying anyone on anything without at least a general definition of what we are certifying against. In the absence of some sort of accepted standard, 'Certified Scrum' anything is just a marketing gimmick.

What do you think, am I missing something?

Subscribe to Leading Agile

Rethinking Scrum and XP

Lately we've been exploring the idea of moving past the specific practices of Scrum and XP and focusing more on what we are doing rather than how we are doing it. Rather than focusing on having ScrumMasters and Product Owners, we need to start thinking about the value these roles are delivering and how we can deliver that value at scale. Meta-Scrums and Chief Product Owners might be part of the solution... but our organization might require more.

To that end... if we are going to create situationally specific strategies at scale... we can start by talking about the core capabilities these roles have to deliver at the team level:

Product Owner

• Set Product Vision
• Define Product Roadmap
• Define Requirements
• Sequence Work
• Communicate Requirements to Development
• User Acceptance Testing
• Manage Stakeholders
• Set release date

ScrumMaster

• Ensure Process Adherence
• Remove Impediments
• Ensure Internal Communication
• Ensure External Communication
• Maintain a Productive work environment
• Team Building

Development Team

• Assign work to team
• Make commitments
• Throttle work
• Design the solution
• Write software
• Maintain code quality
• Take corrective action
• Deliver features
• Deploy the Solution

Everybody

• Continuous Improvement
• Define working agreements
• Resolve Conflict
• Manage Risk
• Set delivery heartbeat

Over the next few weeks we'll explore how these core team capabilities get expressed at each of our five levels of agile adoption. For now I'd like know if you guys think we've got this list right. Is there anything we need to add? Anything that needs to be removed? Your feedback is really appreciated.

If you have a minute... head over to Dennis' blog to see his take on this. Similar content... different presentation.

ADDENDUM: Almost forgot to mark the occasion... this was my 200th post on Leading Agile!

Subscribe to Leading Agile

The Hard Reality...

We all want to be really good at what we do... we strive to get better... we want to think that we are making a contribution to the success of our organizations... we want to think that we are adding value. The hard reality... and one we NEED to really come to grips with... is that sometimes we are doing great work... sometimes even building great working software... that has NO market value.

If our activities don't result in marketable, sellable software... we are wasting time and we are wasting money.

We might justify this to ourselves by saying that we can only control within our circle of influence... that we have to be the best we can be within the areas we can control. Maybe... but if you get really good at creating design documents for projects that get killed... it is still waste. If I build features for a system that never gets sold to a customer... it is still waste. If I build services for a component that never gets consumed by the application... it is still waste.

Anything you document... or code... or test... or even deploy... that doesn't get sold to a customer is ultimately waste. It doesn't matter how good... or how fast... or at what velocity you do your work... unless it sells... you have wasted time and money building it. And that... to me... is what makes Lean such an interesting topic right now...

Scrum really brought home some powerful ideas... revolutionary ideas that have changed how we think about product development. We've learned the value of building organizations around teams and the value of self-organization. We've learned to give the business the power decide what and empowered the team to decide how. Scrum helped us learn that real improvement comes from keeping everything visible and removing the impediments that are really slowing our teams down.

Lean brings a relentless focus on value... not just valuable software... but real delivered value to our customers. Lean expands the concept of value beyond just the product delivery organization... it recognizes that the enterprise value stream often includes other parts of IT... and other parts of the business. Lean gives us language and principles to really scale agile out to the enterprise.

Individual performance doesn't matter... team performance doesn't matter... until we can figure out how to bring it all together into something we can actually sell.

Subscribe to Leading Agile

Be a Get Things Done Guy

I don't want to be a Scrum guy. I don't want to be an XP guy. I don't want to be a Lean guy... or a Kanban guy... or a DSDM guy... or a RUP guy... or a PMI guy. For that matter... I don't even want to be an Agile guy.

As my experience has broadened over the past few years... as I have worked with more and more teams... it seems that most any process can be successful... even Waterfall... with a great team of engaged human beings... passionate... and working toward a common goal.

It seems that most of the time... when we start comparing one way of doing things with another... we tend to compare our best process implementation with the other side's worst. My last waterfall project came in exactly on time... within one percent of budget... with all the scope originally asked for.

And yes... the product was very successful in the marketplace.

Can I please just be a 'get things done' guy? To the extent I can use Scrum or XP or Lean or Kanban or DSDM or RUP or PMI to be a 'get things done' guy... that's what I really want do. To the extent that these labels... or even the processes themselves... get in the way of delivery... we'll figure something else out.

The bigger the tent... the more tools we have at our disposal... the better chance we have to be successful. At the end of the day... it's about delivery.

Subscribe to Leading Agile

Scrum or Kanban... it's not Black or White

It's been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson... this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.

One of the things I found really interesting over the weeked was the words some folks were using to describe the value of Kanban. They were using words like 'increased visibility' and 'buidling trust' with the business. While I wouldn't argue with any of that... I was struggling to figure out how the benefits of Kanban were any different from how we would describe the benefits of Scrum?

If both methods 'increase visibility' and 'build trust'... there has to be something more. In my opinion... the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.

Let me explain...

Scrum takes the approach that the team is a black box. The business puts requirements in... and after some predetermined amount of time... they get working software out. Within that black box... the team gets to self-organize... they get to self-manage. The business gets to decide what... the team gets to decide how. The processes inside the team are abstracted from the business AND from management.

Kanban takes the approach that the team is a white box. The business puts requirements in... but rather than leave it up to the team to figure out how best to deliver the work... management plays a role in defining the work. There are explicit workflows... work in process limits... and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.

One of the earliest agile books I ever read was Mary Poppendieck's 'Lean Software Development: An Agile Toolkit". Not long after that I read David Anderson's "Agile Management for Software Engineering". Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months... I found myself wondering what was so new.

We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered... we are encouraged to help them get finished before we start on something new.

Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints. For some teams... in some environments... it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That's where I am not totally sold.

For now... for me... Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.

For another view of this... go check out Dennis Steven's post on 'Uncovering Better Ways of Delivering Software and Helping Others do it'. It is a good look at how Kanban can help teams get better at delivering software without some of bad attitudes toward management that Scrum can sometimes encourage. Dennis might be a little more sold on Kanban that I am ;-)

Subscribe to Leading Agile

What Do You Value?

Sometimes I think we are missing the point.

I am becoming more and more convinced that building organizations around teams is the real secret to building agile organizations. How we setup our teams, what we have them work on, and how they work together with other teams... all determine how well value will be created for our business and ultimately our customers.

Some things are really important about teams... and some things just aren't. Getting straight about what we are are actually trying to accomplish with our teams will help us get past some of the dogma, methodology battles, and Scrumdamentalism that is preventing us from incrementally adopting agile practices. Is our goal to adopt Scrum or is our goal greater business agility?

Important Stuff about Teams...

Teams Deliver Value

Sometimes this means that teams work on cross functional threads of working software. Sometimes it means that teams deliver services that will be consumed by another part of the organization. Teams might be part of the business and handle billing... or marketing... or sales. I only care about teams being cross functional in the sense that the team needs to have what it need to deliver the value is was created to deliver.

Teams are Accountable

Teams make and meet commitments and are responsible for delivering on those commitments. They are accountable for outcomes. I don't care so much how they deliver those outcomes... assuming that they operate within moral and ethical boundaries... I care that teams do what they say they are going to do and deliver the outcomes that they promise to the business

Teams are Predictable

Over time, the business should be able to provide specific inputs and get reasonably predictable outputs. Throughput should trend up... and we should know why it is trending up. If throughput is trending down... we should be able to assess and understand why it is trending down. If throughput is variable... it should at least have a reasonably predictable rolling average. If teams aren't predictable... we can't plan anything.

Teams get Better

We need to have some mechanism in place for getting better over time. This could be a sprint retrospective... or it might be a Kanban board. We can rely on the knowledge and creativity of the team to improve... or managers can use specific tools that help make problems visible and help the correct the problems. It cannot be okay to accept mediocrity.

Teams are Transparent

The business needs to be able to understand exactly what the team is working on and how the deliverables relate to the objectives of the business. The business needs to understand what problems the team is having so that they can help get them resolved. Team performance metrics need to be visible and explainable

Not so Important Stuff about Teams...

Teams have Product Owners

I am probably going to get myself in trouble here... but I don't think that the Product Owner is all that important. It is important to have a well groomed product backlog. It is important to have someone to answer questions for the team on behalf of the business or the customers. It is important that the business is accountable for making decisions in a timely manner and giving guidance to the team.

If that can be done by a single person called a Product Owner... so be it. All I know is that it needs to happen.

Teams have ScrumMasters

Again... going to get in trouble. What I really need is someone to help the team stay on track... to maintain the vision... to help remove impediments... and to collaborate with the team to help them improve. If this is a ScrumMaster, great. It might be a resource manager that fills this role... it might be a project manager. It might be a good dev lead or a product architect.

Teams do Daily Standup Meetings

What I really need is communication between team members. I have worked with teams that all sat in the same space... worked together daily... and always knew what was going on. If a daily standup meeting adds value... do it. Just remember why you are doing it and if you are getting the outcome that you need. Communication... transparency... shared accountability... those are the important things.

Teams have Planning Rituals

The team needs time to plan. They need time to get their head around the problem and coordinate the work. They need a time to inspect and adapt. This might come in the form of a sprint planning meeting and a sprint review. It might be done ad-hoc as a individual requirement is moved from the backlog into the in-process queue.

Do We Care About What or How?

When folks are just getting started with Agile... it is easy to get caught up in the how. How are we going to plan... how are we going to meet... how are we going to review outcomes... how are we going to ensure accountability. We need to focus on what the team is going to deliver, and the attributes of that delivery that are important to the business.

It is extremely important that a team delivers something of value on short cycles... that they are accountable... that they value predictability... that they get better over time... and that they are transparent to the business. To the extent that Product Owners, ScrumMasters, daily stand-up meetings, and planning meetings help me get there... they are useful tools might get included.

These things could be out of sync with your organization and actually impede your ability to adopt agile. You might need to think about what you're really trying to accomplish and come up with some situationally specific strategy to build teams... and to get teams predictable.

It might be unreasonable to ask the business to take a Product Manager and turn them into a Product Owner. It should be perfectly reasonable to ask them to make sure teams have the requirements they need to build software... requirements that accommodate change... help mitigate risk... and deliver value better and faster back to the business

So my question... are you more concerned about adopting specific agile practices or doing what it takes to build well functioning teams?

Subscribe to Leading Agile

Subscribe to Leading Agile

More Second Order Agile Scaling...

In my post Second Order Agile Scaling, I suggested that building teams around capabilities was the first step toward untangling our portfolio management mess. The second step... and equally as critical... involves having the discipline not to start projects we don't have the capacity to finish. We know from our experience with small team agile that writing requirements we can't develop is waste. The exact same thing goes for building capabilities that can't be consumed by the project team or the business.

Agile portfolio management involves identifying our most pressing business problems... or most lucrative market opportunities... and coordinating the capabilities of the organization to deliver the highest return on investment with the least amount of risk to the business. Our agile organization is going to organize around capabilities... understand and measure the throughput of each team... and focus on delivering the highest priority projects first.

Let's consider a simplified model for what this kind of project intake and decomposition might look like...

Figure 1 shows how a project is identified, broken down, and assigned to teams through progressive elaboration of the requirements and design

Here is the idea behind this diagram... the business is constantly looking for things to fix and opportunities to take advantage of... opportunities that will align with overall strategy and objectives of the enterprise. The business knows that these opportunities are going to leverage the combined capabilities of several teams within the organization... but early in the life of the project... we are not quite sure which ones. How do the strategic planners know what the organization can deliver... and when... so they know how to make commitments to customers?

The answer lies in progressive elaboration of requirements... the progressive elaboration of the solution architecture... while restraining our tendency to over-specify the solution too early. We need to make commitments... while keeping our options open... while we figure out the details. Let's look at this in a little more detail...

Circle 1: Strategy and Enterprise Architecture

When projects arise for consideration by the business... there must be a team in place that is responsible for assessing the set of possible business solutions (requirements) and the set of possible technical solutions (design). This teams job is to consider the objectives of the business to identify a high level solution that can be delivered within the time and cost constraints necessary to deliver the expected value with minimal risk to our investment.

See my post called Software Requirements Balancing Act for a little more around what I am talking about here. Putting this into more day to day terms... we need to identify the major epics and themes that will make up the product requirements. We also... and this is really important.. need to identify the organizational capabilities (feature teams, component teams, or services teams) that will be leveraged to deliver those high level requirements. In my mind... I call this enterprise architecture... the set of big block decisions that the organization makes to constrain the set of possible technology outcomes.

Circle 2: Product Management and Software Architecture

Once the business has decided what it wants to do... it needs to engage the capabilities of the organization to deliver. The themes and epics are assigned to the Product Owner team to break down into user stories. If there is a need to manage technical dependencies between component teams or services teams... this is where you begin to establish the high level software architecture. Admittedly... I'm not talking much about building software yet... but I fully expect this level of the organization to explore options... and validate decisions... by building out and delivering working code.

The goal at this stage of the planning process is to bring our understanding of the problem space and the solution space down to the next level of granularity. Just as the strategy team and the enterprise architecture team collaborate to keep the requirements and solution in balance... the Product Owner Team and the architect collaborate to keep the user stories and software architecture in balance with the constraints established by the strategy and EA teams.

Circle 3: Product Ownership and Detailed Design

At this point, I am sure that you can see where we are going here....just like themes and enterprise architecture constrain the decisions of the Product Owner team... user stories and software architecture constrain the decisions of the capability teams. We are taking the problem from a very high level of abstraction... through progressive elaboration... to the point we are ready to assign user stories to a capability team where user stories can be specified, designed, and coded at the detailed level.

This is where the rubber really meets the road. This is where the actual capabilities of the business are delivered. You have a team of engineers collaborating with a product owner on a day to day basis... making the daily trade-offs to deliver within the constraints established by the Product Owner team and the Software Architect. Again... each higher order team constrains the decisions of the lower order teams... not in a vacuum... but collaboratively with an established feedback mechanism.

Constraints and Feedback

Figure 2 shows the flow of constraints down the chain with feedback flowing back up the chain.

In this model... business decisions have to be made up front at a pretty high level of abstraction... that's reality and we have to deal with it. Enterprise teams do not get a free pass to deliver whatever they want... after all... most business do not have an emergent business model... they operate under a goal oriented model. Teams deliver on the goals and strategic objectives of the larger enterprise.

These business decisions though need to be made at the appropriate level of abstraction so that the teams can inspect and adapt their way to delivery. The business establishes the constraints but the team is free to be agile within those constraints... they can do what they need to do to deliver on the higher order objectives.

Okay... so what if the constraints are invalid or limit our options in an inappropriate way?

The idea is to mitigate the issue within the capability team... or if possible... at the current layer of abstraction. When the problem transcends the ability of that layer to resolve... it gets escalated up the abstraction hierarchy and mitigated at the next higher level. As deep or as wide as your agile enterprise is... constraints come down the hierarchy... and feedback goes up the hierarchy. Each level is responsible for managing trade offs until you reach a point where the issue has to be taken up to the next level.

Subscribe to Leading Agile Subscribe to Leading Agile

First Order Agile Scaling

When we talk about scaling agile... we are really talking about how to coordinate the activities of many small teams to do the business of the enterprise. The interesting thing is that we don't have to go from 6-8 people to thousands in one giant intellectual leap. There are plenty of problems to solve moving from only one team to as few as three or four.

How are we going to make sure that each of our teams are working on the right stuff and in the right order... how are we going to establish context and coordination? This post I want to explore a few models I've used over the years to try and solve this problem.

Scrum of Scrums

This seems to be the standard answer for scaling agile projects. Do you have more than one team? Easy... do a Scrum of Scrums. Great... but what does that mean? Who participates? How often do they meet? What are they tasked to do? If you have ever tried to answer this question for a real company... the idea can begin to break down pretty quickly.

The simplest implementation of a Scrum of Scrums involves the ScrumMasters from each of the teams getting together to deal with any cross-functional issues the teams can't deal with locally. This group meets daily and answers the same type of questions the team members answers during the daily stand-up... what did your team do yesterday... what did your team do today... are there any organizational impediments that will prevent your team from delivering the sprint? This group usually meets sometime after all the other Scrum teams have had their daily stand-up.

This is a pretty useful collaboration tool if the teams are largely independent from each other. Remember.... independent means that they share few dependencies. If the teams do not need to operate in a coordinated fashion, from either a requirements perspective or a technology perspective, this model can work pretty well. It can be used to manage minor dependencies, but the goal of the Scrum of Scrums is primarily to communicate between teams and provide support for other teams that might be struggling to meet their objectives.

Product Owner Team

We've talked about the idea of a Product Owner team at the single-team level. We established that the role of the Product Owner was often too big, and an abstraction of too many roles, for a single person to do effectively. This is a pretty common problem in a mid-size organization because there are lots of stakeholders. It is even more common in an organization when you have more than one team working to deliver an integrated product.

In this case, you might want to consider pulling the Product Owner team out of the single team and have them work across several teams at one time. In this scenario, the Product Owner team might have a Chief Product Owner, the Project Manager, the Business Analyst, and UX designers. Just like in the small team scenario, this team is responsible for grooming the backlog for each of the Scrum teams and making sure that there is sufficient information ready for the team to consume during sprint planning.

In this model, each Scrum team would have a proxy for the Product Owner team and likely its own ScrumMaster.

The Product Owner team would be a team of its own with a prioritized backlog and full time team membership although they will likely have responsibilities outside the team as well. The Product Owner team works with each of the proxies and ScrumMasters to make sure that they have sufficient information to act on their behalf. The members of the Product Owner team are available to all the Scrum teams... just not allocated full time like the proxies and ScrumMasters.

This model works best primarily when its requirements that need to be synchronized across Scrum teams. You'd probably use this approach with feature based teams that can work across the entire software stack. We are in effect building a team of folks that are responsible for all the requirements decisions that cannot or should not be made at the individual team level.

Product Owner Team with Architects

This is a variation of the Product Owner team that is really geared more toward Leffingwell's component team model. Because component teams don't work across the entire software stack... there are technical decision that will have to be made across teams. Interfaces will have to be defined... software contracts will have to be established... complementary technologies will have to be chosen.

Irregardless of component teams or feature teams... I tend to like this model.

From my point of view... it is always a good idea to have the technical folks collaborate with the requirements folks to make sure that the requirements space and the solutions space are kept in balance. Technical collaboration with the business is built into the very fabric of our small team model but has to be explicitly accounted for when we start scaling technical decision across multiple teams.

Just like the Product Owner team is responsible for the decisions that cannot or should not be made at the team level... adding the Software Architect to the Product Owner team creates accountability for those technical decisions that cannot or should not be made by the team.

And by all means... drive as many technical decisions down to the team as possible. This group of folks should only deal with the decisions that you don't want made by the team... because they are bigger than the team... because they are primarily strategic business decisions masquerading as technical decisions. I'll also add that these decisions should not be made in vacuum... they should be made in collaboration with the teams that are actual doing the work.

Integration Teams

If you've come this far... you might find yourself in a situation where you need not only requirements context and coordination... and technical context and coordination... you might need a team of folks that can glue it all together once it is built. You need a team that can integrate the components and you need a team of folks that make sure it all works together when you are all done. Not a trivial problem, huh?

Context and Coordination

You'll notice in these models... the more dependencies you have... the greater the context and coordination costs. And remember... at this scale we are only talking about 3 or 4 or 5 teams.

When you build your organization around small independent teams... where each team has autonomy to do what it needs to do to deliver against it's objectives... you really just have a special case of 'small team agile'. Product Owner or Product Owner teams don't make all that much difference to the enterprise. Your concerns are not making sure that everyone is working on the right stuff in the right order... you are more concerned with making sure that we are communicating and cooperating. This is not a trivial problem... it's just that the solution is not all that expensive.

When you start introducing dependencies between requirements, you have to make sure that everyone is working together to build the same product. At this point the Product Onwer or Product Owner team discussion becomes much more critical. You need a group of people that are charged with making sure all the teams are working together to build the right features, in the right order, and with the right level of common specification. Your context and coordination costs just went up a notch.

If your organization is so big, or so complicated, that you are really building systems of systems... you have a tremendous amount of dependence and interdependence across the product landscape. Each system may be a product in its own right and has to balance its own priorities against the priorities of the cross component features. Its no longer just that requirements are dependent on each other... your software architecture and technical infrastructure all has to be aware of what's going on. Your context and coordination costs have just gone through the roof.

Can this still be agile?

It depends on how you define agility. I believe that you can build your organizations around small self-organized agile teams. Where I get hung up is on the single wringable Product Owner making all the decisions. A few posts ago I made the distinction between Product Owners and Product Ownership. We need Product Owners... but more than that... we need organizational Product Ownership. Each team can be independent and agile within the boundaries established by the broader organizational objectives.

Agile organizations build capabilities around small self-managed agile teams. Product Owners and ScrumMasters guide those teams. That DOES NOT mean that these teams get to build whatever the heck they want with no guidance from the larger organizational entity. Product Ownership involves establishing the broader requirements context and coordinating how our small agile teams work together to deliver the business value expected from a larger, more complex enterprises.

Subscribe to Leading Agile Subscribe to Leading Agile

Getting Back in the Game

Okay... time to recap where we are with this whole Scrum Roles/Product Owner/Scaling Agile discussion. My hope was to drop in this morning with a new post... to finish an article I started writing before leaving for the Scrum Gathering. I've got to be honest... I was lost. I needed to get my head around where I'd been and where I was headed. I figured you guys might need a refresher as well... so here we are... a recap of my last 10 posts ;-)

Are Scrum Roles Really Sufficient?
http://www.leadingagile.com/2009/02/are-scrum-roles-really-sufficient.html

This was the first post in our series, and I have to admit... I wasn't sure exactly where we were going at this point. Every team I work with or coach is trying to map their existing organization to Scrum and there just aren't enough places to put everyone. Maybe I am making this too hard. Maybe everyone gets this but me. I am getting a sense that the simplicity of Scrum is actually making things hard on people. It seems we need someone to tell us where all our current team members fit... or at least how they might fit and how their jobs are changing.

ScrumMasters and Team Members
http://www.leadingagile.com/2009/02/scrummasters-and-team-members.html

I've been thinking about the role of ScrumMaster for a while and tended to equate it with the role of the Agile Project Manager. So many traditional project managers think this is where they fit in Scrum... but ScrumMaster is not always the right role. In some ways the ScrumMaster has part of the job of the traditional Project Manager, but not all the job. If it is not all the job... where did the rest of the PM job go? This post also touches a bit of the Team Member role. The team has always been pretty straightforward to me... developers and testers... but what about the BA? The designer? The UX folks?

Product Managers and Product Owners
http://www.leadingagile.com/2009/02/product-managers-and-product-owners.html

Much like the ScrumMaster/Project Manager dilemma, many organizations want to equate the Product Owner and the Product Manager. Again... the roles here are really different. Trying to force fit the Product Manager into the Product Owner role is causing trouble on most of the teams I work with. In this post I introduce that the Product Owner is actually one big abstraction for everything outside the development team. They are everything the development team doesn't want to deal with.

Filling the Leadership Vacuum
http://www.leadingagile.com/2009/02/filling-leadership-vacuum.html

I've been wanting to say this one out loud for a long time. Many teams are struggling because the business wants certainty from the developers but they themselves don't have much of a clue about what they want to take to market. That's fine... they don't have to know exactly what they want... they shouldn't have to have that figured out up front.... they just can expect to know exactly what they are going to get and when they are going to get it. Close customer collaboration between agile teams and the business helps solve this problem. The role of Product Owner is there to provide direction to the team... to be accountable for making business decisions... to make the hard trade-offs.

The Reluctant Product Owner
http://www.leadingagile.com/2009/03/reluctant-product-owner.html

Here we introduce a theme that I plan to carry forward into all the remaining posts in this series... the idea of context and coordination. Context provides information about what we are doing... coordination provides information about who is doing it and when it needs to be done. This is a pretty simple problem at the team level and is the sole responsibility of the Product Owner. The challenge that most enterprises face is that they are solving a scaling-agile problem at the same time they are trying to adopt agile. As an industry, we don't have much experience at this, and we don't have much experience doing it well.

Product Owner by Proxy
http://www.leadingagile.com/2009/03/product-owner-by-proxy.html

As we scale into the enterprise, the role of the Product Owner gets too big for a single person. We have talked about the role of Product Owner containing elements of Product Management, Business Analysis, Project Management, and UX design. They are abstracting the needs of the business stakeholders from the team and translating those needs into actionable requirements. One of the scaling patterns I often see is to name a Product Owner proxy for the team. Typically this is the BA or tactical Product Manager but I have also seen the Dev Manager, Architect, Team Lead, or Project Manager play this role.

The Product Owner Team
http://www.leadingagile.com/2009/03/product-owner-team.html

Here we introduce the idea that the Product Owner role often needs to be a team of people... all responsible for making sure the team has actionable user stories that can be consumed in the sprint. This team can be led by a Chief Product Owner that delegates responsibility. I tend to want this group to be part of the team, working with the developers and QA folks on a day to day basis. This team has the additional responsibility of making sure the product backlog is groomed and ready for sprint planning. On some teams that responsibity might be held by a single Product Owner... on some a Product Owner and BA... on some teams a Product Manager, BA, Project Manager, and several designers. It's all very situationally specific.

Feature Teams or Component Teams
http://www.leadingagile.com/2009/03/feature-teams-or-component-teams.html

This post get's off the core topic a bit... but I have a good reason for going here now. We have to decide what are teams are going to build. Do they build features or do they build components. The answer to this question is going to depend heavily on the scale of the product you're taking to market. Smaller teams... smaller organizations... it is much simpler if you can use the feature team approach. At some scale though... you will have to figure out how to do agile using component teams. The idea of having a small team of people capable of working across the entire architecture breaks down at scale for many reasons.

How you answer this question is going to impact how you ultimately scale the Product Owner role.

Teams are the Building Blocks of Agile Organizations
http://www.leadingagile.com/2009/03/teams-are-building-blocks-of-agile.html

Many teams struggle adopting agile because they can't or won't enforce the team concept... they want to optimize the organization's resource utilization rather than maximize the team's throughput. Any conversation about scaling agile has to begin with the idea that team's have capabilities and teams have throughput... not individuals. The Product Owner role becomes about making sure that the teams have the right context and the right coordination... that they are working on the right things in the right order.

Product Owner or Product Ownership
http://www.leadingagile.com/2009/03/product-owner-or-product-ownership.html

If you can buy that the Product Owner does not have to be a single person... you can start to think less about finding a single Product Owner. You can think more about aligning your business around its most important objectives... you can start thinking about product ownership. Decide first if you need feature teams or component teams... next realize that teams have capacity, not individuals... understand that teams have throughput. At that point we are left with deciding how we are going to apply our teams to solve our most pressing business problems.

Product Ownership at scale becomes less about a person... less about a particular role... and more about business alignment and prioritization... more about context and coordination.

Okay... now I'm ready to take this thing forward!

Subscribe to this blog Subscribe to Leading Agile