Agile Chronicles

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.

Product Owners and Product Managers

Oops! This blog post has moved to the Agile Management Blog. Click here to read it: Product Owners and Product Managers

ScrumMasters and Team Members

Oops! This post has moved to the Agile Management Blog. Click here to read it: ScrumMasters and Team Members

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.

For the Love of Agile

With Valentines Day quickly approaching, I thought it might be fun to quickly blog about why I love Agile. Not everyone can honestly say they Love Agile. It does tend to expose your organizations shortcomings and makes you feel like you have just been betrayed by the solution that was designed to pull you through.

 

Sometimes Love is a bitter sweet emotion... I believe Mariah said that, or was it Whitney. Nonetheless, Agile Methods are designed to help us succeed in Product & Project design and implementation. The key to success in this endeavor is almost the same as what many face in their marriages. Long story short, you reap what you sow!

 

Being Agile is not just the cool thing to do, it is an investment. It is a relationship which needs to be cultivated and constantly made better. I for one can say I love my wife more every day that passes. I can say this because each day I work a little harder to be a better husband and father. The burning question still remains, am I doing all I can do be better in my agile role? Am I taking the time to study through inspection, adaptation, and retrospectives to make things better? Am I doing all I can to contribute and really make a difference.

 

On this holiday where we focus on Love, take a moment to focus on the things you love as well as the things you could do better. Take the time to inspect and adapt. Do not leave for work without letting your spouse and kids know just how much you love and appreciate them! Do not let another day of work pass with frustration. Choose to make a difference and act today. 

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.