Filling the Leadership Vacuum

That was a pretty bold statement I made last time around.

Here it is again in case you missed it... My premise is that the Product Owner in Scrum embodies many of the roles we see in a traditional software project; they are the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group (sales, marketing, support, etc.) all rolled into one.

A long time ago on a project far, far away...

Let me tell you guys a little story. When I was first formally introduced to agile... I was working with a team that was doing XP. These guys were responsible for working with business strategists to create new products for markets that didn't exist yet. Agile was the perfect approach because there was so much uncertainty and there was no choice but to learn by doing and adjusting based on what they learned. Static requirements just didn't exist.

I am going to oversimplify the story a bit, but this team created a product that went big time and they got sucked into the mainline business... they were no longer a research team. As the product got more and more successful, the team grew and needed some more structure and organization. They needed to scale... and that was how I got pulled in.

I was pretty open, and had some background in iterative methodologies, but had basically been schooled in the ways of traditional project management. In my early days with this team I kept feeling like they thought everyone was a developer (or at least that developers could do everything on a project... the whole generalist thing). It also seemed to me like the Product Owner was too simplistic a means of dealing with the business. There was no way that the Product Owners could make every decision that we were expecting them to make.

This agile approach had clearly worked for them so I started searching for answers and bought every book I could get my hands on to understand what was going on. I needed to know how these folks had come to these conclusions about software development methodology. I was trying to figure out how and why all this stuff was supposed to work. Along the way I formed few opinions about why agile was defined they way it was and what the movement was fundamentally trying to accomplish.

Product Owners fill the leadership vacuum...

Most businesses cannot make up their mind. Most organizations lack vision... they lack leadership... and they lack direction. Unfortunately, many development teams are on the receiving end of this void. Many development teams are asked to estimate projects with unclear requirements knowing full well the business is going to constantly change it's mind. They know these changes are going to have profound impact on the software they are building.

Furthermore, they know that while the business is changing its mind, the business will hold the team accountable for delivering on time and on budget... against a constantly shifting target. Many teams are in an impossible situation managing against unrealistic expectations.

Think about what we are really saying with agile in general, or Scrum in particular:

Give me a team full of really talented developers, give us as few constraints as possible, put us all in the same room, and don't bother us for weeks at a time. Give us a single person to make all the business decisions (the Agile Product Owner) so we don't get yanked around and we'll agree to be accountable to that person, and that person only. We'll make all the decisions about how the code gets built and how the team operates, but as a trade-off for this level of autonomy, we'll deliver working software in short bursts... and let you change your mind as much as you want.

Not a bad deal if you ask me. The cool thing too is that it works... but it has its limitations.

...but let's get back to the point

This is a great model for a single team or a group of teams that are truly autonomous. Once you scale past two, maybe three teams, or when teams have to work with each other in a coordinated fashion, the single omnipotent Product Owner model begins to break down. It is too much for a single person to wear so many hats across so many project or product teams.

Once the Product Owner delegates some of their responsibilities to other Product Owners, a Project Manager, an Analyst, or a Designer... the contract that Scrum makes with the organization breaks down. You have to have introduce coordinating processes, and this introduces waste... and reduces autonomy... and reduces agility. You no longer have a Single Wringable Neck.

Next post we'll look to explore several models I've seen work on teams of various sizes and explore some models for how we should view the Product Owner at scale. We'll begin to explore some organizational models that support the traditional Product Owner concept and some organizational models that will require you to adapt from basic Scrum. As always, I am interested in your comments.

One last thing before we close....

As I mentioned last time, Jeff Sutherland was in town last night. I was very fortunate to get an invite to dinner with Jeff and a few of the folks that hosted the event. I had a great opportunity to talk about these ideas with one of the guys that actually invented all this stuff. We talked about how teams are re-purposing some of their traditional roles for Scrum and how a few of the teams Jeff has worked with are dealing with these communication and coordination issues.

I left feeling pretty good about my approach here and validated there is a real issue that needs to be addressed. We need more people writing and talking about this stuff. Small is beautiful, but we can't pretend that big doesn't exist.

Subscribe to this blog Subscribe to Leading Agile

Product Managers and Product Owners

Last post we explored what roles fit nicely in our existing Scrum roles. We also identified a few that didn't. We explored the role of ScrumMaster and Team and talked about which roles seemed to make sense in a Scrum context. Today we'll take a look at the role of Product Owner and see if we can find a home for a few of the others.

Most teams start with the assumption that the Product Owner role should be filled by the Product Manager. I think that is a reasonable starting point but let's look at how Wikipedia defines the role of a Software Product Manager:

A Software Product Manager is responsible for researching, selecting, developing, and placing a company’s products. This role considers numerous factors such as target demographics, competition, and how well the product fits in with the company’s business model. A software product manager takes this high level understanding of market needs and translates these needs into Product Requirements Documents and Software Requirements Specifications. Product Managers ensure that the resulting product is deployed successfully and meets the initial specifications.

That captures some of what a Product Owner does, but probably not everything. Jack Milunsky posted a nice summary last week of the Top 10 Activities of the Product Owner over on Agile Software Development. I don't want to rehash Jack's post here so I recommend you hop over and take a look at that post if you need a refresher. I trust that many of my readers probably have this idea under control ;-)

When you look at all the things an agile Product Owner is doing for the team you see pretty quickly that the role of Product Owner is really much, much more than that of a traditional Product Manager. From the development teams perspective, the Product Owner has responsibility for everything from executive sponsorship to planning and scheduling. They are responsible for managing expectations, status reporting, requirements definition, and even quality and user acceptance. To quote the Scrum guys, they are the Single Wringable Neck.

That is quite a bit of responsibility for one person... for one role... on an agile project. Is it possible that we have found where Scrum put all our missing roles?

Product Owner as Project Manager

Much of what we think of as Project Management is actually assigned to the Product Owner in Scrum. They are responsible for assessing the needs of the project stakeholders and making sure those needs are documented, prioritized, and communicated effectively to the team. The Product Owner is responsible for identifying and managing tradeoffs to deliver the release within the time, cost, and scope expectations defined by the business. All pretty straightforward Project Manager stuff.

Product Owner as Analyst

The Product Owner role is expected to translate requirements, much like a traditional business analyst or designer, into language that a developer is going to understand and can build into the product. They work daily with the team to explain and clarify their emerging understanding of the requirements. They make sure the requirements meet acceptance criteria and get to decide ultimately if features are ready for release.

This sounds a whole lot like why we had Systems Analysts and Business Analysts in the first place? Is it possible that the user experience and user interface should be designed by the Product Owner as well? If not the Product Owner, who else?

NOTE: For a really cool treatment of this topic by a true expert, take a look at Jeff Patton's recent post on called the Product Owner and the Product Shaped Hole. Jeff touches on a few themes I am exploring here but I have no idea if he would agree with where I am going in this post.

Product Owner as the Business

By virtue of owning the product backlog, and having authority to set priority, the Product Owner abstracts and plays proxy for quite a group of traditional project stakeholders. The Product Owner represents in Scrum all the interested Product Managers, the marketing team, the sales team, the support organization, the implementation group, and the training organization. They are the Vice Presidents and the Division Leaders... the CIO, the CFO, and the CEO

... all rolled into one nice, neat, tidy package for the development team.

Really? You might need to unpack this a bit...

In other words... and I'll say it more explicitly this time... it is my premise that in Scrum, the Product Owner either has the responsibility for, or is an abstraction of, every other role not previously accounted for in discussing the ScrumMaster and the Team. The Product Owner is the Project Manager, the Business Analyst, the System Designer, the User Experience Architect, and every other Business Group... all rolled into one. The role is really supposed to be omnipotent and omnipresent.

What do you guys think? Have we found our missing roles? I think so. You might be thinking at this point that I have overstated my case... maybe I have. I know there are many teams out there with Project Managers and UI Designers and Analysts that probably think they are doing Scrum just fine. Maybe there are... but I bet Scrum didn't tell them how to do it, and furthermore, I bet they are assuming additional coordination and communication costs to make it happen.

Over the next few posts we'll explore when and why the single Product Owner approach works. We'll also talk a bit about when and how the Product Owner abstraction breaks down. I'll begin to share with you some of the things I have tried over the years to minimize coordination cost and a few ideas for what I might try next time. I'll also be interested to hear about some of the things you have tried and how you think about the role of Product Onwer.

Thanks for hanging with me so far...

Subscribe to this blog Subscribe to Leading Agile

ScrumMasters and Team Members

As I mentioned in my last post, Scrum only calls for three roles on a project. We get a ScrumMaster, a Team, and a Product Owner.

Pigs and Chickens

These three roles are the pigs... the ones that actually have skin in the game... the ones that are invested and will do the work. Scrum also talks about Chickens... management types that might have an interest in the project, but are not actually involved getting the work done. Never heard the story of the Pigs and Chickens? Click here to check it out.

This post we'll start with the roles of ScrumMaster and Team Member. We are going to try and sort out all these farm animals, figure out who is going to do what, and look at where some of our traditional project roles might fit in.

ScrumMasters

The ScrumMaster is reponsible for making sure the Scrum process is followed. These folks also make sure that impediments are identified and resolved in a timely manner. You might find one of the technical guys playing this role (in addition to their day job) but unless they've got the right facilitation and leadership skills, this can get a little complicated. I've seen developers and QA analysts do very well playing ScrumMaster, I've also seen them struggle.

Some people think this is a good place to put the Project Managers. Right now our industry has a bunch of Project Managers scrambling around to get their CSM certification. Many agile methodologies, Scrum included, don't call out the role of a Project Manager. The idea is that Project Managers aren't really necessary on a self-organizing team. Sometimes you get a Project Manager that plays the role well, but for now, we just need to understand that a ScrumMaster and a Project Manager are not the same thing.

ScrumMasters are process facilitators and support for the team. Project Managers are usually responsible for managing the team and ensuring that time, cost, and scope are balanced according to predefined project constraints. Project Managers usually have ultimate accountability for delivering the project and are authorized to spend money to make that happen. This is not the same as a ScrumMaster, ScrumMasters have no authority over the team. ScrumMasters are more servants of the team... Project Managers are more like a boss.

I used to think the ScrumMaster role was a good place to tuck our Project Managers... now I am not so sure. But that begs the question, if Project Managers are not ScrumMasters, are they Team Members? If not, are we suggesting Project Managers are left out all together?

Team Members

The team should be pretty easy to understand. These are the folks that do the heavy lifting getting the product built. The team decides the implementation details... they write the software... they make sure it is sufficiently tested. The team gets to define how the product is going to be built, and how long it will take, but don't really have a say in what get's built or in what order... that's the role of the Product Owner. The team reviews their work with the Product Owner to make sure it meets their acceptance criteria.

The development team, the database guys, and QA can probably be worked nicely into the role of Team Member. These folks have direct responsibility for designing, building, and testing the code. But what about the business analysts, systems analysts, and user experience specialists we talked about in the last post? These guys don't actually write the code... they more likely play a role in helping the Product Owner translate requirements for the developers and testers. Are they part of the team too? Maybe... that's where many of them end up today, but it's not a slam dunk.

For now at least it doesn't sound like we have a good home for Project Managers. We may have also left out the traditional requirements and design oriented roles as well. We still have yet to find a home for the other chickens we talked about earlier. Hmmm, I wonder if we are getting into trouble here.

Running Out of Roles?

If these traditional roles are not ScrumMasters or Team Members... where does that leave us? The only thing left is Product Owner. There is NO WAY that Scrum could save all these roles for the Product Owner, could it? Might we need to define a few extra roles to accommodate all these missing people in the development process?

(Jeff Sutherland is in Atlanta this week, maybe I'll have to ask him and let you guys know what he says ;-)

Next post we'll talk about the Product Owner role and see if we can figure out where to tuck all these extra project participants.

Subscribe to this blog Subscribe to Leading Agile

Are Scrum Roles Really Sufficient?

Okay... so you are making the transition to Scrum... awesome!

Let's start by taking a quick inventory of your team and figure out who is going to do what in this new methodology. Scrum defines three roles for us: ScrumMaster, Team Member, and Product Owner. Everyone's pretty excited and ready to get going, so let's take a look, and see where everyone fits in.

If your organization is like most traditional software development organizations, your team probably has a bunch of developers, several QA analysts, maybe some interaction designers, a database guy, and usually a Business Analyst and a Project Manager. You might be working with a real customer, but more often than not, you are working with a Product Manager who's job is to define your product requirements.

Is that everyone on the project? It might be everyone on your project team, but is that really everyone on your project?

When you look outside the immediate project team, the number of people with influence over your project actually gets much larger. You likely have several Product Managers, maybe a few marketing folks, a sales team, and of course your support organization. You may have a team of engineers that implement your product and probably a few consultants that train your customers on how to use new features.

Do you have any interested functional managers, directors, or vice presidents? What about the Business Development and Strategy team? Does your project have visibility at the Senior Executive level? Where do the CIO... the CFO.. the CEO all fit in? These folks not only have an interest in how the project is coming along, they might need to actually insert some requirements and shape the direction and timing of your project.

More than likely, these folks actually funded your project. Do these individuals have a defined role in Scrum? If so, what do we call them... what do they do? Is it sufficient to call them chickens and tell them to talk to the ScrumMaster?

Over the next few posts, we are going to take a look at the role of ScrumMaster, Team Member, and Product Owner and explore how many of our traditional roles play on an Scrum team. We'll examine how, from the team's perspective, many of our traditional stakeholders are abstracted behind the role of the Product Owner, what this means for the agile team, and its implications for the broader organization.

We'll assess some of the risks and suggest an alternative or two for dealing the Product Owner at scale.

Subscribe to this blog Subscribe to Leading Agile

Handling Support on Agile Teams

Anybody have a team that is responsible for both new development and support activities? I got a great question from one of my readers last week that I'd like to share.

I have a team that’s responsible for both supporting what we’ve already created and released as well as developing new features or enhancements to what’s been released. I’m about to split a scrum team up from 12 people to 2 teams of 6. Most folks have no desire to do support full-time.

With only rough estimates of potential weekly incoming product defect ticket rates, we’re trying to determine how best to deal with this situation so that we can maximize our teams’ velocities while ensuring that we can deal with incoming product defect tickets within appropriate resolution times. The natural tendency is to have a very conservative velocity, but we’re hoping for something better than that.

This is a problem not unique to agile teams. Software organizations have been struggling with this one for years. The root of the problem is that your project needs a predictable throughput. Stable velocity is essential for a well managed predictable agile project... but your support activities make establishing a stable velocity nearly impossible. Support is a variable the team can't really define or control.

I'd love to tell you to just add the support tickets to the backlog with all the new development work and prioritize them sprint to sprint along with the other product features. The problem with this approach is most times support tickets are a drop everything, get the customer working activity. Support tickets also defy estimation. You are never going to know how long they will to take... you don't know their tasks... you might not even be able to predict their relative size. Service requests just have to get done... and they have to get done now.

I don’t know that there is a magic answer to this question. Like most things, it is a matter of understanding the particulars of your environment, and of your people, and coming up with something that meets your individual needs. Here are a few approaches I have tried in the past with varying degrees of success. Would love for you guys to reply to this blog with your ideas an other approaches for dealing with this difficult issue.

Approach One

Alternate the teams between support iterations and new development iterations. The team would establish a steady velocity (every other week) based on their new development work and that steady velocity could be measured against the remaining backlog to balance the scope and end date. If the team is not 100% consumed with support during a given sprint, they can use the extra time to get ahead of the game on their upcoming development sprints.

Approach Two

Assuming you have some historical data on how much time you spend doing support, allocate a fixed amount of bandwidth to support activities each sprint. For example, each team would allocate 30% of their time to support activities and velocity would emerge based on the time they have remaining to do new development.

Assuming the support needs will vary iteration to iteration, you will have to account for that variability in your commitments to your organization. I'd track best case, worst case, and average velocity based on what the team has been able to deliver iteration over iteration. You would then express this variability to the business as either a range of delivery dates or as a range of product features that could be delivered by a fixed date.

Approach Three

The last (and maybe least desirable approach for your team) is to have one team responsible for development and one team that is responsible for support. That would allow the development team to get into a groove writing new code and the support team to establish patterns for how much and how quickly they can get through support tickets. Because no one wants to do support full time, you would rotate people in and out of the support team and back onto the new development team.

I'm interested in your thoughts. Please weigh in with how you've handled this issue on your teams and what has worked (and maybe more importantly) what hasn't.

Subscribe to this blog Subscribe to Leading Agile

My Agile Lightbulb Moment

Yesterday, Michele Sliger asked me if I would do a little writeup on my agile "lightbulb" moment... that point in time when I got it... when I was able to cast off the chains of traditional project management and accept agile as the one true way to salvation.

Okay, okay... Michele just asked me to write my "lightbulb" moment... I added all that other crap.

I find these kinds of stories fascinating... what makes one person able to see the benefits of agile when others cannot? What series of events could lead one person to look for a better way, and furthermore, be able to recognize that better way once it when it presents itself?

The switch to agile requires us to see the world in a new way.... to use a different map... to look through a new lens. Many folks who practice traditional project management fundamentally see the world through a lens of predictability. Traditionalists believe that with enough planning we can create a stable project baseline and manage the project into a successful outcome.

Agilists tend to see the world through a lens of unpredictability... they are more willing to embrace uncertainty. Agile project managers still want to manage the project into a successful outcome but they are more willing to allow the definition of success to emerge through the life of the project. The interesting question to ask is what leads someone to hold one world view over the other?

When you have been brought up in a business environment where projects are relatively predictable, the idea of predictability is reinforced. When projects go wrong, you try to track the failure back to some failed process... or some piece of missing information. The fundamental assumption is that with more planning we could have prevented the failure.

Our project management education teaches us that solutions come in the way of process, documentation, and control.

My early professional experiences were in environments of total chaos. It was not that I was working in poorly run companies (I was working in very large, very well run companies) but that I was constantly working in environments with new and emerging technologies. Furthermore, I was working with people that were knowledgeable, but not necessarily experts in the technologies we were trying to deliver.

Growing up professionally in this kind of environment taught me that uncertainty was the norm. As technology guy, working with other technology guys, I rebelled against managers that though we could standardize process around activities that were ultimately unknowable. My experience never reinforced that predictability was something that could be attained.

When I was promoted into formal project management, I tried to learn the science and best practice around my new job. We started using MS-Project to plan out our work and I got my first copy of the PMBOK Guide. The problem was that I could never get comfortable my plans ever quite reflected the reality of what was really happening on the project. The more I spent time planning, the more the projects seemed to drift off schedule.

There was a profound disconnect between what the books were telling me and what I was experiencing in real life.

To cope with uncertainty, I started laying out high level milestone plans and doing rolling wave planning to flesh out the details. I had to to trust the team to deliver. During critical times on our projects my teams would have daily meetings to talk about what we were doing and to discuss problems in real time. We started estimating in relative units and calculating how fast we were moving through our list of deliverables.

We found using these approaches that we could deliver more reliably, with less overhead, and deliver greater value to the business.

It would be a few more years before I discovered that others had already figured all this stuff out. It wasn't until I started working with a development team that was already practicing XP that I realized there was a science behind what we had been doing... that there were other practitioners out there... and that there was an informal body of knowledge that I could lean on to expand my understanding.

I have always thought of my "lightbulb" moment, not so much as the moment when I understood (my career had perfectly positioned me for understanding) but more when I found my tribe. My moment came when I discovered that there was a community out there to validate and support what I intuitively already knew to be true.

Subscribe to this blog Subscribe to Leading Agile

Mike Cottmeyer... Agile Coach

I have quite a unique opportunity...

Normally my job with VersionOne involves training and a bit of consulting. I spend most of my time on site with customers, for only a few days at a time, trying to get across as much agile knowledge... and teach as much about our product... while helping them paint a vision for their agile journey ahead.

Over the next two months I get to change things up a bit... I'm working with a client here in Atlanta as an agile coach. I get to spend some time working with a REAL team, actually putting some of the stuff I talk about into practice. It is a nice treat and it feels great to get back into the day-to-day of helping folks with live projects.

I am really looking forward to the change of pace... and the opportunity to stay out of Hartsfield-Jackson International Airport for a few weeks. As an added bonus (if the last few days are any indication) this engagement is going to provide months of stuff to write about. Nothing like getting busy to start the creative juices flowing.

Prior to my first day with the new team, there were a few things I wanted to get a handle on pretty quick. I want to share with you guys what I felt was important and see if anyone else out there wanted to contribute to my list:

• How well does the team understand agile roles. Who was doing what on the project?
• How are they managing the project? How are the critical meetings being run? What metrics is the team tracking? How well does the team facilitate meetings? Are they using collaborative approaches for estimating and planning? Is someone dealing with impediments?
• How disciplined are their engineering practices. Are there any critical practices missing?
• Is their organizational structure supportive of agile teams or is it an impediment? Do they have any alignment issues between projects, product, teams, management, or software architecture?
  
• What is their leadership style like? Are they more command and control or do they take a more participative approach?
• How strong is the product vision? How well are the user stories articulated? Do they understand the full scope of the project or expect the backlog to emerge? How much requirements churn do we expect?

What do you think? What would you need to know about a team to be an effective coach?

Subscribe to this blog Subscribe to Leading Agile

Stuck on Velocity...

Okay... so it seems I am a little stuck on velocity this week. Maybe with one more post I can get this out of my system and move on to other topics. Let's talk a little more about what velocity is, what it is not, and how it should best be used by a project team.

Traditional Estimating

Most projects I worked on prior to discovering agile would start with a long list of requirements. The project manager would reach out to each of the resource managers for an estimate. These estimates would be done in real hours and used to calculate how many people were needed for the project, and by extension, how much the project would cost. In my experience, the business almost never liked the estimate, and would always ask us to do something to lower the cost.

As a project manager, I would go back to the resource managers and start the negotiation process. The most extreme example of this I ever participated in lasted almost four months. We negotiated scope, tried to do a bunch of up front design work, made assumptions about the project, and were finally able to cut the estimate down by about 50%. The funny thing was, I had been largely negotiating with each manager individually, and none of them really had much understanding about how the other managers were thinking about solving the problem. Their estimates were fundamentally out of sync.

We literally spent four months, and a bunch of valuable time from critical resources, haggling over a number (that at the end of day) turned out to be total fiction. The reality was that we had no idea how big the project would actually be. Furthermore, we had no idea which team members would actually be doing the work, so coming up with a reliable end date was nearly impossible. The only thing we could do was create a project plan, with the estimates we had available, and hope for the best.

Agile Estimating

Agile teams do estimate projects but use mechanisms that reflect the uncertainty inherent in the process. You have probably heard about the idea of story points and planning poker. This is one of the most common methods of agile estimating but not the only method. The general idea behind agile estimating is that you start by identifying a small, relatively understood requirement and assign it an arbitrary value of one (1). Each feature in your product backlog is evaluated against the well understood requirement. We ask ourselves, as a team, do we think the new requirement is 2x, 3x, or 5x more complicated than the one we are comparing it against?

The first requirement gets a point value of 1, the next requirement might get a point value of 3, while a third requirement might get a point value of 5; all based on the team's understanding of the relative complexity of each feature.

At this point, we have the size of the backlog in points, but it doesn't really tell us anything. Since points do not equate to hours, we still don't know how long the project is going to take. Some teams will do detailed estimating on the first few features to get a general idea of the size of each backlog item, but we really won't know how many points we are able to build each iteration until we start building them.

This is where velocity comes in.

The product owner prioritizes the features based on business value, the team gets to weigh in based on technical complexity and risk. Collectively, the team sets the build order of the features and gets busy writing software. Each iteration, the team will deliver some number of features, and keep track of the point values assigned to each item. The sum total of all the point values, associated will all completed features, is the team's velocity. It is fundamentally a measure of the team's throughput iteration over iteration.

Because we know the overall size of the backlog (in story points) and how many of the features the team can build each iteration (in story points), we are able to calculate when the project will be completed:

Iterations to Complete = Backlog Size/Points per Iteration

The key concept here is that traditional estimating almost never results in a reliable project cost indicator. Only by building working software in short cycles, and measuring our progress, will we have the necessary information to know how long the project is going to take. If you didn't read my last post on progressive estimating, this might be a good time to go back and take a look. Because we won't know how much we can do, until we actually start doing it, we might have to insert a few checkpoints where the business gets to recalibrate the project or decide to pull the plug.

The traditional view of velocity is that it is specific to the team that is doing the estimate. One team might give a feature three (3) points while the next team might estimate the same feature at a five (5). As long as the team doing the estimate is the one doing the work, this is not a problem. Remember, points are estimates of relative complexity... of relative size. The actual value does not matter. The only thing I care about is the team's throughput against the overall size of their backlog. It is the only thing I need to know to determine if my project is progressing according to plan.

Normalizing Velocity

That said... what happens if I have many teams that are working together to deliver a large, complex project. If one team calls a feature a three (3), and the next team calls a similar feature a ten (10), it might get difficult to communicate performance on the overall initiative. The team that uses the larger point values would obscure the performance of the team with the smaller point values.

To answer this question, I have seen many teams normalize a point to a common unit of measure. For example, my team will often think of a point as a single person day. We are still using lightweight estimating techniques, we just use the normalization value as a starting point for conversation. This approach can level the playing field and enhance communication between teams that are working on various parts of the same initiative.

While this normalization can have benefit on large scale agile implementations, there is some risk.

As soon as we start equating a point to a standard unit of time, we start trying to do math on velocity. The discussion usually starts by asking how we can improve the velocity of the team. Well... if the team has four people that can deliver 20 points per iteration, we could add a fifth person and increase velocity to 25. Or maybe... we find that the same team of four is only delivering 17 points per iteration. We want to know what those deadbeats were doing with my missing three points of capacity.

My personal opinion is that it is perfectly okay to normalize velocity across teams. As managers, we need to recognize what velocity is measuring... and what it is not measuring. Velocity is measuring throughput against an abstract estimate, it is not measuring productivity... and certainly not time spent on task. It is very common to see situations where the point estimate was 20, the detailed estimate was 25, the actual hours spent was 30, and the features delivered was 15. The team can use these numbers to get more consistent estimates, but again... all I care about as a manager is throughput and how I can help the team improve over time.

Even in an environment where we are normalizing velocity, there are many factors that can contribute to velocity variations between teams. Team size is an obvious consideration, but what about skillset and experience? We should consider team chemistry... we should ask if the team dependent on other organizations to get their stuff done. Maybe they've encountered impediments that have slowed their progress. This is all stuff that contributes to team velocity.

I coach teams to measure velocity so we can measure what is... to get honest information about how the project is progressing... then look to the other factors to determine how to make it better. The last thing we want to do is to inadvertently incent the team to manipulate the numbers to make the data look good.

Subscribe to this blog Subscribe to Leading Agile

Progressive Estimation and Tollgates

Kelly Waters from All About Agile picked up on my post yesterday about project velocity. Kelly made a great point about how we can use a toll-gate approach for estimation and project funding.

Here is Kelly's comment:

In some methodologies - for example RUP - there is an initial stage of the project ("inception") to do some high level scoping before seeking approval for full funding. It's also quite common in waterfall projects to complete the reuirements analysis before going on to request full funding. In these cases, only the initial stages need to be funded and then the team knows more by the time they ask for the rest of the money.

This is an essential concept for large scale agile development, and here is why.... coherent software architecture, UX and UI design, and requirements are not going to just emerge from multiple small teams working independently on a significant, enterprise level initiative. Without some degree of lightweight, up-front planning (to integrate the activities of several teams working together) it is unlikely that we will converge on a well integrated product.

Schwaber talks about this when he talks about iteration 0. Leffingwell talks about this when he refers to an architectural runway. In my opinion, these guys are dancing around the idea of Inception and Elaboration. This almost has to be done because RUP is such an unpopular topic in the agile community... otherwise people tune out. Ambler is more direct explaining these concepts when he talks about the Agile Unified Process.

By introducing these higher order agile concepts, we can help teams learn to effectively structure large scale agile implementations, and furthermore, help teams understand what decisions need to made and when... from both a busines and a technical perspective. A year or so ago I did a post called the Agile Heart of the Unified Process (back when this blog had no subscribers whatsoever).

Rather than reinvent the wheel, I am going to grab some text from that article and update with some commentary to tie back to Kelly's original comments... the text in bold was added today.

Inception

The goal of Inception is to minimize business risk. This means that you have to understand the vision for what you are trying to create, have a high level understanding of the requirements, and have defined the characteristics of the systems architecture you intend to build.

Begin Inception with a single Scrum team. The team should at a minimum have a ScrumMaster, a Product Owner, an Analyst, a Quality expert, and an Architect. The product backlog will include the features necessary to create the Vision, Use Case Inventory, and Candidate Architecture. It may be necessary to include features in the Inception backlog that prove key aspects of the business vision.

Inception is the least code focused of all the RUP phases. This is due to the requirement to have an idea of where you are going before you begin the project. Since Inception is the least focused on creating working software, and without working software the team is not mitigating risk, it is in the team's best interest to make decisions quickly and get on with the business of delivering working software.

At the end of Inception, there is a business decision that must be made. Do we have a strong enough product vision, and a strong enough architectural vision, to fund the next increment of product development. This is a good time to reestimate the backlog and decide if the value proposition of the project still holds.

Elaboration

The goal of Elaboration is to minimize technical risk. This involves choosing the smallest subset of features that will prove out the significant technical assumptions made during Inception. At the end of Elaboration, the system should be fully functional with the subset of features you have chosen to build. The system should be fully tested and the team should be confident that the architecture is stable.

During Elaboration, you may still have a single Scrum team. It is likely that you will add several more senior level technical folks to help begin building the system. The product backlog includes the features necessary to prove the application architecture and to deliver any non-functional components required to build out the system. It is important that the Elaboration backlog contain features the team will need to collaborate at scale. Source control, build environments, automated testing infrastructure, instant messaging, and collaboration software should not be overlooked when preparing to scale an Agile team.

At the end of Elaboration, we have another business decision. Have we built enough of the application to validate our technical assumptions. Can we move forward with the project, scale into multiple agile teams, and move forward with confidence we have a workable and proven solution? This is the next point where you need to reestimate the backlog. After proving the solution, updating the backlog, reestimating based in what we have learned, do we have a business case for moving forward?

Construction

The goal of Construction is to mitigate logistical risk. This is where the bulk of the software is created and where the Agile team really begins to scale. The core team that helped build the foundation of the system during Elaboration is broken up to seed the newly created Scrums. Each team is organized around a major component of the architecture or a significant feature set within the overall scope. Each team is a complete cross-functional entity that is responsible for delivering its part of the system. These teams are coordinated by a master team that includes a more senior ScrumMaster, Architect, its own technical staff, and the Technical Leads and/or ScrumMasters from the component teams.

At this stage, the backlog is completely feature driven, progress is extremely measureable, and the teams are focused on delivering the bulk of the business value to the customer. As is true during every phase, the code delivered at the end of each Construction iteration is fully tested and integrated with the rest of the system.

Construction is the most like the prototypical agile project as described in most of the common literature. We have several independent feature teams working in concert. Each is tracking velocity and burndown and making product adjustments as necessary to converge into a solution that delivers the most business value possible. The business is involved actively assessing progress iteration over iteration deciding when enough of the product has been built to take the solution to market.

Transition

This phase deals with training and hand-off to the customer, final user testing, and resolving any issues that were not caught earlier in the process.

During this phase, the team should be able to scale back down to a single cross-functional team or two. The backlog is related to the remaining documentation, training, and defect resolution features remaining to get the product in the hands of the customers.

I think of transition like many talk about hardening iterations. This is the place where we clean up anything leftover. If we need any final user acceptance, doc work... whatever, this is where it goes. We are asking our customers if they are ready to accept the project deliverables.

Subscribe to this blog Subscribe to Leading Agile

Some Thoughts on Project Velocity

Companies I work with desperately want reliable estimates.

In reality, they need them so they can run their business. Businesses really want a crystal ball to look out into the future... to know pretty much what they are going to get, when they are going to get it, and some idea of what it is going to cost. The problem is that they need this information when approving projects... when making commitments to the market... and this is when we have the least reliable information about what we are building.

This need can result in pretty bad behavior on the part of both management and teams. To gain some sense of certainty, management does things like ask teams to provide estimates in real hours... and then hold the team accountable for delivering exactly according to that estimate. Faced with an impossible situation, teams are incented to game the numbers. They overestimate the project (to provide some necessary buffer) thus resulting in overinflated budgets. All this leads to a total lack of trust on both sides.

Velocity is intended to bridge the gap between management and the team. Teams get to measure project scope in relative units such as story points. Point estimates are specific to the team and measure how big one feature is relative to another in the backlog. Teams then begin building the features and measure how much of the backlog they are able to complete every iteration. After a few iterations, the team should have a pretty good idea how long it will take to complete the project.

Iterations to Complete = Backlog Size/Points per Iteration

For this equation to work, for velocity to be a meaningful metric, it has to be predictable... past performance must at some point become indicator of future performance.

Furthermore, velocity is only relevant to the business if we have a decent understanding of the overall scope of the project. That means we have to have a meaningful view into the backlog... for at least the upcoming release... sometimes the entire project. Measuring velocity against a constantly changing backlog doesn't give me a whole lot of information. If we are going to have any idea of what done looks like at the project level, we need to understand both backlog size and velocity... and understand how these metrics might change over time.

Velocity is fundamentally a measure of team throughput. How fast are we able to go... iteration over iteration... against a relatively stable queue of product features. These two metrics are the only thing standing between an agile team and total choas... at least when it comes to overall project performance.

To make all this work... both sides have to do their part. Ask not what your agile project can do for you... ask what you can do for your agile project. Here are a few thoughts on what managers and teams can keep in mind to keep velocity a reliable indicator of project performance... and maybe build a little trust while we are at it.

Responsibilities of Management

Realize that estimates are just that, estimates. As management, we can expect that estimate should get better over time, but what we get early... even in story points... is likely to change. We need to be prepared to deal with change.

Management should only use metrics like velocity as an indicator of project health and to help guide the project into a successful outcome. If management uses velocity as a lever or a performance metric, people will game the system to make the numbers look right. You'll get the numbers you want, you might just not get the product you want.

The size of the backlog has to be stable or the project is out of control. We can't just keep changing our minds indefinitely. We want to defer as many decisions, as long as possible, but we need to have a fundamental understanding of the product we are building and why. Constant churn will slow the team down and make everybody frustrated.

Responsibilities of the Team

Estimates are just that estimates. That said, we are accountable for making them better over time. At some point we have to be able to tell the business what they are going to get and when they are going to get it.

As team members we have to realize that our velocity must stabilize. Stable velocity is the life-blood of a predicable agile team. If we can't stabilize our velocity, the business will always see our project as out of control... because it is. We cannot expect the business to continue to invest never knowing what they can expect to be delivered.

We have to be honest with ourselves and our customers about what it really means to be done at the end of an iteration. Gaming the system to make the numbers look right will kill a project... hiding undone work in future iterations doesn't help either.

For Further Reading:

A little more on the idea of uncertainty and the reality of progressive estimating:
http://blog.softwarearchitecture.com/2008/03/progressive-refinement-of-estimates-aka.html

Some of my thoughts on team accountability and the need to accommodate change:
http://www.leadingagile.com/2009/01/what-about-accountability.html
http://www.leadingagile.com/2008/07/delivering-value.html

Subscribe to this blog Subscribe to Leading Agile