For success with Scrum, we need the basics, our expertise, and to improve our culture. To improve the culture, we need the Product Increment.
Regarding Scrum, one really needs to know the basics: the activities, the roles, the artifacts, the inspect and adapt, the partridge in the pear tree. And based on some of the articles I’ve been linking to lately, a lot of people don’t know some basics, like how long a meeting is allowed to take, and what the meeting’s purpose is.
There are good reasons why things are the way they are in Scrum, and if a team is going to be successful with it, it’s wise to try to do it by the book, at least until you get good at it. It seems, based on the stories we hear about why Scrum should be hit by a meteor or eaten by bears, that a lot of would-be Scrummers either never got the word or quickly forgot it.
In my opinion, you really need to know the basics, and live pretty close to them, if you want the best chance of success.
Almost all of what developers need to know is outside Scrum. Developers need to know how to develop. In software, that means the languages and tools in play. It means that developers have to know how to program. They have to be able to analyze requirements. They have to be skilled at testing. They have to know how to design. It takes years to be really good at these things. No one developer has to know it all, but the development team needs to have all the skills required to build the product.
Similarly, most of what Product Owners need to know is outside Scrum. They need to know the market, the customers, the competition, the needs that the customers have. They need to have the ability to envision a product need and to create a solution. It takes years to get good at what Product Owners need to know outside Scrum.
Many Scrum people believe that Scrum requires a “culture change”, and that lack of that culture change is the biggest reason why Scrum teams get in trouble. Reading as we have about ninety minute stand-ups and such, it’s easy to see “culture” at the root of those problems. A key question is how do we bring about that culture change.
The canonical Scrum answer is a decent start, if people would do it. You’re not supposed to add a ScrumMaster and a Product Owner to your existing roles of Manager, Tech Lead, Senior Java Engineer, Chief Architect and User Experience Scientist. You’re supposed to have exactly three roles: Product Owner, Developer, and ScrumMaster.
You’re supposed to have those three roles, to learn how much of what you do can be handled by those few roles and those few people, working together. Sure, you’ll have to sort out some interface to the company for hiring and such, but to build the product, that’s all you need to start with.
And you’re supposed to get rid of those silo-creating specialist titles. I’m not Chief Architect: I’m a Developer. You’re not a Senior Java Engineer: you’re a Developer. We develop the product. We do it. Together.
Yeah, well. No one does that. Everyone keeps their old roles and titles. Maybe the Project Manager says “Yeah, now I’m the ScrumMaster, but I’m really the Project Manager”. And so on. What happens? Most, what doesn’t happen is change. Why? Because we decided not to change before we even started.
Rather than change ourselves, and learn the new game, we changed Scrum. We changed it before we ever knew what it was. Two strikes against us, pun intended.
Building the Culture
Is it possible, even in a contaminated Scrum situation, even when some of the key structural aspects aren’t in place, to build a productive and happy culture? Since many teams manage to do it, clearly it is possible.
This is a very difficult question, and surely every team is different. However, I think there is an element that is usually central to building a successful Scrum effort: the Product Increment.
The Product Increment
Scrum canon is very clear about this: at the end of every Sprint, the developers deliver a Product Increment. This increment must be usable, even if the Product Owner does not intend to release it. It must be tested. It must meet the organization’s definition of done. The Increment must include all the value of this Sprint and all preceding Sprints.
Let’s be clear: this isn’t easy. Every two weeks (every month if you’re a wimp), you must release a new version of a usable product, including all the value from the preceding versions, tested, and ready to go. Teams have trouble with this, no doubt about it. Sometimes I even have trouble with it myself.
Nonetheless, the Increment is essential to building the culture, as we’ll discuss now.
Scrum revolves around the Increment
The product increment is the most tangible communications medium within the development team and between the development team and the Product Owner. It goes like this:
The Product Owner describes a need. The team works out how to build software that solves the need, and they build it in a couple of weeks. Everyone sees the same real live Increment. Trust grows. With tangible results, it’s easy to focus on accomplishment, how to improve it. No one needs to worry about who’s working hard or who’s working on what, because we have a real product to talk about.
Does the team have a manager (wait, what role is that again?) who asks for lots of details of what people are doing? He’s doing that from fear, the fear that nothing will get done. A few cycles of getting real product done should calm those fears. And the team, their ScrumMaster, and their Product Owner can all be aligned in saying “Stay cool, Jim, we’ll be back in two weeks with another increment with this stuff in it.”
Is the Product Owner not very good at providing guidance? Are her backlog items too vague? “We have to test this thing, Susan. How’s this for a test for that shopping cart feature?” The product is tangible. Maybe early on Susan will try something and not like it. Great! We have a real thing to point at, and we can devise real tests to ensure that things are going to be good before we even start.
Are the backlog items way too detailed? “Susan, we see some ways to do this thing, and we understand what we’re after. Let’s set the Sprint Goal to be ‘Handle Credit Card Refunds’. We’ll run with it and build something you’ll like by the end of the Sprint. We’ll show you what we’re doing in a few days.” If Susan knows she can trust the team to produce a real increment, she can relax and let them apply their creativity.
It’s not magic. There is no magic. But with a solid product increment coming out every two weeks, the communications move away from uncertainty and fear, and toward pragmatic discussions of this real thing we see in front of us.
The product increment is, in a very real sense, the point of Scrum. It is the thing you’re going to ship. Maybe not this week, maybe not next. But you could ship it if you wanted to. You can – and should – show it to everyone who’s interested (Sprint Review, remember?).
In my opinion, the Increment is the sine qua non of Agile Software Development. How do we get one?
Getting the Increment
Yes, well. Here we are, back at the technical stuff. Scrum asks for a running, tested, integrated chunk of product every two weeks. (Sound familiar? Hello, welcome to 2004. But I digress.)
The team needs to learn how to do this. They’re already good at their tools, but if they haven’t learned to use them to build a running increment every couple of weeks, there’s a bit more to do. They could consider an Agile tech skills course, which would help them at least see that it’s possible. Or they can just keep banging away at it.
Perhaps the biggest trick in building an increment in two weeks is taking on only a tiny bit of work. Some teams can’t build the current version in two weeks, much less put a change into it. Your team probably isn’t that badly off, but you might want to expect to do very little actual story work in early Sprints, while you get things running smoothly.
But always take on at least one or a few of the Product Owner’s backlog items. Even in these early days, we’re trying to build trust between developers and stakeholders. There’s a huge difference between saying “We’re going to need two (four, six) weeks to get our infrastructure in shape, then we can start on stories”, and “We’ll just take on one or two stories for an iteration or three, while we sort out this new development flow. After that we can start running a lot more through the machine.”
This will build trust, and it will keep your eye on the ball. Far better to get a real increment with one little bitty story in it, than to come out at the end of the Sprint saying “Well, our build procedure is nearly done now”.
Trust me on that, I’ve been there. Small progress can be improved. Zero progress looks as if Big Changes are needed.