A New Software Development Framework: Whole Team

See New-Framework

Bon Voyage

For reasons that escape me, I’m beginning a series of articles describing what I’d do if I were to create a new software development framework. Be assured, I’m not going to do that, but I do think writing from that perspective will give me a chance to see how history has changed my views about what’s important, what’s possible, and what’s fun.

In some of these articles, I may start from the Agile Manifesto. In others, like this one, I’ll at least try to tie the ideas back to the Manifesto. To me, it still embodies a lot of what we all were about 20 years ago, and what I’m still about today.

The Manifesto is about values, and principles. I share those and think they are quite important. However, I believe that what happens in the world depends on what we actually do, not on what we just believe. Therefore, I’ll be writing a lot about practices … the things we actually do.

Practices are meant to be done mindfully. Let me put that another way: you’re not supposed to just do them blindly. You’re supposed to do them with your eyes and your mind open, observing what happens when you do them, when you don’t do them, when you adjust them.

Some of the specific practices are there as starting points, and we expect that someday you may move beyond them (but perhaps not away from them). Some are there as ideals, and we expect that you’ll never get there, but that you’ll find value in trying. In every case, I’ll try to describe how I think of the practices, what goes before them, what comes after.

But I’m just guessing. Today is the first day of a journey. I’m just setting off. Come on along, let’s see what happens.

Practices

When it comes to practices, I’d start with XP. “XP is like Scrum, except that it works.”¹ Still, XP is very specific and it was created 20 years ago. So we’ll need to take a look. Today, I’ll begin with my “official” XP diagram:

As part of exploring “New-Framework”, I mean to consider each of those original XP elements and use them as a basis to explore what I believe today. I’ll write today about Whole Team.

Whole Team

At this writing, I think I’d retain this practice by this name.

The idea here includes Scrum’s notion of “cross-functional team”. The Scrum idea is that the Dev Team has within it all the skills necessary to deliver the product increment. Whole team also embodies the sometimes-mentioned XP practice called “On-site Customer”, which corresponds to Scrum’s “Product Owner”.

We need to deconstruct this a bit, because there’s a lot in there.

Cross-functional Dev Team

We need to build an increment every week or so. The increment has to be running, integrated, tested, and doing all the things that the Customer has selected (see Planning) as being of high value in all the iterations up until now. If we’re to accomplish this responsibly, we can’t be relying much, if at all, on key skills outside the team. The product needs testing: we can’t wait for the testing department. If the product uses a database, we’re going to need to administer it. We can’t wait for the DBA department. Is a manual needed? We can’t wait for the documentation lady to drop by on her monthly visit.

However, this is sometimes a bit idealistic and unreasonable. As my dear colleague Al Shalloway suggests, if there are only ten metallurgists in the company, maybe we can’t have one on our team. Well, sure, but also maybe that’s a clue that we shouldn’t have more than ten teams needing metallurgical help, or that we need to hire more metallurgists. And it surely means the team would be fools to take on a story that required a metallurgist if they couldn’t rely on having one when needed.

Still, the Whole Team practice does describe an ideal. We won’t always have someone in the room who knows everything we need to know. Our job, as thoughtful team members, is to work continually to ensure that this happens only rarely.

On-site Customer / Product Owner

XP has the notion of “On-site Customer”, which would ideally be a real customer for the product. Scrum has the notion of “Product Owner”, someone with the business responsibility to maximize the value of the Scrum Team’s effort. Some Scrum people have referred to the Product Owner as “the single wringable neck” on the team. This is a bit more rough than I’d like to be, but the idea is that this person is held responsible by the business.

Kent Beck, the creator of Extreme Programming, once said that he felt that the division between On-site Customer and Programmer² was a fundamental flaw in XP, but that he couldn’t see a way around it.

In most businesses today, the Powers That Be³ want to delegate responsibility to an individual. There isn’t usually the concept of a team with responsibility (and accountability, which is what the Powers often mean). The idea here, unfortunately, is all too often about who to blame and punish if things go wrong.

We see some exceptional businesses and experiments. Zappos in the USA, Semco in Brazil, and some others, are organized without hierarchy. People come together and work out ideas, get funding somehow, and self-organize to do the work. The Manifesto talks about self-organizing teams, as do Scrum and XP. I think we really mean that, and that none of us as yet knows quite how far that will go.

I remember sitting at a Scrum Gathering with a manager from Disney. He said that he didn’t want to be the “Product Owner”. He wanted the Team to own the product. He wanted to be the “Product Champion”, supporting them, guiding them, coaching them, getting them what they needed to build the product. This individual could surely be Product Champion for several teams. As such, he’d be held responsible in Disney for some high-level goals. Who knows, overall revenue, or number of smiles per unit time. Something important to Disney.

And he might not hold anyone on his Teams “accountable”. Perhaps the worst he’d ever do would be to show up after some months of effort and say

“Gang, as you’ve been telling me, it appears that no matter how hard we try, we just can’t make a good movie about garbage-eating slugs with no brains. I’m sorry, but we have to look elsewhere for something to do. None of you will be harmed by this change in direction, and we’ll get to work on a better idea ASAP. Thanks: We’ll talk again soon.”

Tentative Conclusion …

In this light, perhaps the ideal point for Whole Team is a self-organizing team, including the technical skills, and the business skills, to produce the product that the company needs. This Whole Team would own the responsibility to use its budget wisely, including the responsibility to abandon the product and try something else if that’s the right thing to do.

That seems very unreasonable to many of us who have grown up in big companies. It may seem quite reasonable to those of us who have built something “in our garage” or as part of a small startup. And those of us who have gone from startup to venture funding, or to being purchased by Giant Corp, have also seen what can go wrong with someone assumes Power and starts making decisions that we were all part of back in the garage days.

My take right now is that Whole Team embodies the full spectrum of self-organizing teams, and that the ideal point is a Team without an owner, a boss, or a manager. The Team would own itself and manage itself. That is surely an ideal and it’s not clear that we all will get there, or that we even should.