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