“A common example is process as proxy. Good process serves you so you > can serve customers. But if you're not watchful, the process can > become the thing. This can happen very easily in large organizations. > The process becomes the proxy for the result you want. You stop > looking at outcomes and just make sure you're doing the process right. > Gulp.” (Jeff Bezos)
This is a quote from a Jeff Bezos letter to the board, talking about internal metrics and improvements. Sometimes when you add a process to a problem, the process can become the focus and not the outcome.
In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.
e.g., Let's put a pin in this ...
The real value isn't in the process or lingo, it's in doing things better and making better software within profitable budgets. It's something that's been rolling around my head for a while, and Bezos describes it nicely.
I was talking about basic project management principles with a friend the other day, when I came across this Bezos quote. It sparked a discussion about software development processes, including hitting a few topics that I think are especially distracting in software development.
Do you use sprints, burn down charts (etc.) in software project management?
Yes, these are fairly common software management tools now, and I use some aspects of them. Now of course we don't say “spike” ever, or “tent pole”, but we do plan sprints of flexible durations, and we're always aiming for minimum viable steps and frequent releases.
I think it's a common mistake to set fixed durations with sprints, as it can shift the focus to succeeding at the sprint versus shipping something viable (i.e., both useful in the short and medium term). It can really deflate the team if sprint durations make no sense, as developers pick up on goals that aren't about useful or quality software.
Fixed duration sprints can also force poor decisions, as your primary goal is time and not the other factors important to software. If you relax your use of sprints a bit, you can pick sprint times that fit the underlying problem better. The real goal with sprints is to focus on scoping the project, and improving the overall tempo of development. Sprints shouldn't be truncating quality for minimum viability, nor should they be pushing teams to burnout faster. Really, all we want from sprints is a framework to keep us focused on the right features and a strong speed of development.
Does 'sprint' equate to 'crunch time'?
No, it shouldn't.
This is a great question. My friend is coming from another domain, specifically small-scale custom manufacturing. He's not fully familiar with software development terminology (though he's vaguely familiar with how software is generally developed). Conversations like this are a great reminder that the language we've developed in this industry is insular, even though it is based on what we think are clear metaphors. When you think about if from an outsider's perspective, you can see how arbitrary the language is, and how the imagery doesn't fit perfectly.
This is especially true with terms like sprint. You can't literally sprint all of the time, as it suggests expending the maximum amount of energy over short distances. Software projects are anything but short, and the idea of sprinting through the entire thing is absurd. The PM concept of sprints doesn't match the real world use of the term very well.
A sprint is like a focused mini project. To some degree, it's like having a personal trainer guide your workouts and push you a bit. The idea is to use the mechanism to help you push to a clear goal.
More traditional PM structures projects as very long, boring wanderings through the desert. Waterfall projects, for example, don't produce workable software until much later in the process.
We might say, “we're authorizing blanket overtime” which tells the > guys we need as much effort as we can get right now. There are some > tasks on the shop floor which simply can't be done faster, so we > would add more hours. Or worst case a second shift. There's huge > inefficiency in adding a second team.
That is a common manufacturing practice for increasing bandwidth, but sprints aren't only about increasing output (though the term strongly suggests that). A sprint is more like setting up a smaller shop, with a special, focused project.
Ahhh. We would job things out to other manufacturers ...
That's not quite it either, though I do find using sprints for special ops is especially useful, as you push the focus of the tool to problems that need special focus.
The concept of project sprints was really to make things feel more focused and tactical. It was a backlash on the traditional waterfall planning (i.e., requirements, design, implementation, and testing).
But after using sprints a bunch, they can become empty words for traditional project management things. The trick is really to keep sprint projects focused on smaller, but useful deliveries.
Sprints really just become project phases like those in the waterfall model, except that you've organized the deliveries differently. You try to partition design into things you can deliver on shorter intervals, rather than aiming to deliver one giant thing at the end. There is a huge advantage to delivering these small and useful pieces early on, as you learn a lot about what works (and doesn't) well before the end of it all.
I was saying earlier that the concept of sprinting suggests running fast, which if you think about it is so expensive in terms of long-term motivation and energy. It's an odd side-effect of the name itself, as running fast isn't part of the definition of a software sprint, yet the term implies it so strongly.
There's this pattern of making special languages for our formal processes, based on the ways we approach building software. It's difficult to find ways to describe processes that don't eventually become ideology or warped in some way. The simple act of naming the parts can change how we think of them, if we lose focus on the real goals.
I can't think of an analogue in manufacturing ...
It eventually boils down to the same set of problems as with projects in any industry. I've seen special-ops style projects in manufacturing before:
One re-manufacturing mill I worked with started a finger-joint mill. They took their best staff and had them design and built the new plant in stages, apart from their traditional management techniques. They split the work into smaller chunks, and had something up and running early.
Ahh, I see!
They treated it like a special thing, which helped them escape their traditional planning techniques.
Of course sprints aren't really just special-ops anymore, but that's where the concept started from. We used to say “Let's push hard and get this out by next week”. We used this push mindset well before Agile methodologies were well-defined, and sprints were really an extension of that.
Yeah we did that too, but I guess we were so unfocused that it was > normal to work on random projects.
In the end it's just different words for the same things. The mindset of making projects smaller and focusing them on early and useful releases is the best part of sprints. The concept of isolating design to reduce scope is also great.
Really, sprints cut across the grain of the old waterfall style planning, repackaging a lot of the risk to earlier deliverables. It really only works if your sprints produce production quality deliverables though, which is why it's so important to avoid serving the process over the goal of building something incredible.
Sprints are a good example of allowing the process to become the focus, instead of obsessing over what you're making. This is what frustrates me the most about software development methodologies: when great concepts become ideology and the underlying intent is lost. You start spewing the bullshit terms without even thinking. They become bullshit when the term is the focus, rather than the outcome.
e.g., Let's spike this feature for the next sprint.
Or, Our sprints are only 1 week, so that story is too much for us right now ...
It's disingenuous to use these words all the time. It allows a lot of passive-aggressive behaviour too, as you can use the noble act of following the process as a way to beat down legitimate concerns about what customers or the business needs.
What I see happen is that smart people can control production and planning by using the process language in clever ways. Arguing things for the sake of process can be a sign of that problem, i.e., elevating the process above the intent.
The problem isn't in the process, however, it's just a reminder that it's easy to focus on the wrong goal. Sticking to your process is often a much clearer path than figuring out what your users really need, or how to design that thing in such a way that it's a viable business. And because the process can be easier to succeed at, it becomes an easy target for people on a career path.
As software leaders we just need to remind our people to apply the process and tools for the outcome. We want to build useful things for our fans and users, and we want these projects to serve the needs of the business. The processes and methodologies are just tools to this end, and not the end itself.
#SoftwareEngineering #Weblog
