Missing A Sprint Not Considered Harmful
Since I'm a sports guy, let's start with a sports analogy about Michael Jordan, the greatest basketball player of all time. Over a 15-year NBA career, Michael Jordan played in over 1000 basketball games and scored over 32000 points. In those 15 years he led his team to a total of six NBA titles.
Throughout his 15-years in the NBA, Michael Jordan made, on average, 49.7% of the baskets he shot.
Clearly, the fact that Michael Jordan missed more shots than he made isn't tarnishing his reputation as a Hall-of-Fame basketball player. Yet, on agile software development teams, it often seems that missing the target on even a small percentage of sprints is considered an indication of a dysfunctional or struggling team.
Friends, this is simply not the case.
Scrum often uses the word "failed" to describe a sprint wherein the team does not complete all of the stories they committed to at the start of the sprint. Technically speaking, it's a true description. But the connotation of the word is so strong that I've sometimes seen teams get pretty down on themselves because of it. I suggest using the word "miss" instead of "fail" for this reason. Michael Jordan missed about half of the shots he attempted, but he's certainly not a failure, and I can't imagine he even spent ANY time at all dwelling on individual "failed" baskets.
If your Scrum team is truly challenging itself to fill each sprint with the most work that can reasonably be done during the sprint timeframe, you should fully expect to miss on your sprint about half the time. That shouldn't be a problem for you, and if it is a problem for your management, you need to help them back off and see the larger picture. Here's why:
Suppose there are three Scrum teams in two different organizations working on a series of 10 three-week sprints. Suppose that the best each team can do, in terms of estimating how long work will take, is to achieve about 80% accuracy. Team A always tries to fill their sprint with what they think is three weeks of work, while Teams B and C always commit only to the work they feel fully confident they can accomplish in three weeks.
This means that every sprint, Team A is trying to do three weeks of work. Their margin of error is 20%, or 3 days. In any given sprint, if Team A completes their work inside of the range of 12 to 18 days, they are operating within the margin of error and thus filling the sprints about as full as they can be. About half the time they will complete all the committed work, and about half the time they won't. But over the course of the 30 week project, those hits and misses will average out and they should accomplish about 30 weeks of work. The management for Team A clearly gets the bigger picture that consistent execution toward achieving 30 weeks of work is preferable to always achieving every commitment along the way.
Now consider Team B. Their management doesn't have the same vision as that of Team A, so instead they insist that Team B must meet their commitment every single sprint. Team B realizes that their margin of error is 20% on each three-week estimate. So how does Team B ensure they meet their commitments each sprint? They only commit to about 12-13 days of work each sprint. That way, in the worst reasonable case they take the full three weeks to get done, and still meet their commitment. But what happens when they overestimate? In the opposite case, they finish in about 9 or 10 days and spend the last week of the sprint waiting for it to end so they can start working again. Over the course of their project, their estimate inaccuracies cancel each other out, just like they do for Team A, but because they were padding each sprint, they only did 25 weeks of work in the 30 week project. They met their goals each sprint along the way, but it cost them 1/6 of their work capacity.
Team C has it even worse. Their management insists that they fill each sprint with three weeks of work, no padding. But they also insist that they must meet each sprint commitment. That means about half of the time, Team C will have no alternative but to crunch in order to overcome their faulty estimate. If we assume Team C doesn't know until the last week that they are going to miss if they don't crunch, we can assume that about every six weeks, Team C will have to work a 50 hour week, on average, to make up for it, and sometimes as much as 65 hours. Team C might complete 30 weeks of work in 30 weeks, if they don't go get new jobs first. They didn't get any more work done than Team A, but they were a lot more stressed out and a lot more miserable for a good five weeks of their project.
Imagine if Michael Jordan's coach had told him, "Michael, I want you to score, but you are expected to make every shot you take. If you take a shot and miss it, you're gonna get benched." It's easy to imagine how this ridiculous situation would play itself out: Michael Jordan would never have become a great basketball player because his fear of missing a shot would have kept him from shooting nearly every attempt he otherwise would have taken.
Like Michael Jordan, your team can only become great if it is safe to fail. If you are missing every sprint, that's a problem that needs correcting, but I would be equally as worried about a team that hits every sprint. A great team should hit their sprint about half the time, and they don't get down on themselves when they miss. After all, it's the finished product, not the individual sprint, that the customer pays for. Missing half your sprints on the way to delivering a great product on time is a fantastic recipe for smashing success.
Scrum Will Not Make You Code Faster
It's funny how obvious this seems when you state it, yet how commonly organizations try Scrum (or any other methodology, for that matter) in an attempt to improve the speed at which developers deliver code.
Take any typical software engineer from any typical software engineering organization. Years (or months) ago, this individual was attending college, probably studying computer science. During this time, this person would attend classes and receive homework assignments from professors. These homework assignments would often require this individual to write a computer program which would solve a specified problem in code. This person would then hand in the compiled program and/or the source code to complete the assignment. Getting good grades on assignments was required to get good grades in class; at a minimum, producing working code was usually required in order to pass.
Okay, you are saying: So what?
Read the paragraph again if you must. In order to attain a CS degree, the software engineer in question had to prove they know how to PRODUCE SOFTWARE.
Maybe not high-quality software. Maybe not fully localized software. Maybe not enterprise-class software. But software nonetheless.
Software developers learn how to write software in college. Yes, they learn more about it as they gain experience, this is true. But they learned this skill in college, and had to prove it again and again to graduate. They do not need a software methodology to help them write software.
Nor do they need one to help them write software faster. The amount of time it takes a software engineer to write the code to implement a piece of functionality, the amount of time to actually write the code itself, is not dependent upon a specific methodology. How long would it take me to write an HTTP server in JavaScript? However long it would take, choosing Waterfall or Scrum or DSDM makes no difference in this case. Someone else may do it quicker or slower, but it isn't because of the methodology they choose.
Organizations make this mistake a lot. They ask engineering for an estimate to write the WhatsyDoo. Engineering says it will take 9 months. "They never give me an estimate that fits within my desired timeline," they think, even subconsciously. "I need a way to get them to deliver it faster. Maybe Scrum will help!"
These same people presumably consult with their wife, decide to have a child, then get frustrated when the doctor says it will be 9 months before the baby is born. Presumably, they scour the internet looking for new techniques to allow you to deliver a fully-developed, healthy, full-term baby only 3 months after conception.
Software methodologies are designed to help software development proceed more efficiently. But don't get confused. No methodology can make a group of developers deliver code more quickly than they otherwise would.
What CAN a methodology do, then?
- It can minimize distractions to developers, so they spend more time developing.
- It can minimize meetings, so developers spend more time developing.
- It can manage external requirements, so developers don't fight so many fires.
- It can focus measurement on the right metrics, so developers don't spend so much time quantifying their work.
- It can help identify the right features, so developers don't waste time working on stuff that customers don't want.
Software development methodologies are frameworks — frameworks for helping the art of writing code to fit within the context of an organization that delivers software products. For example, the creation of software products that meet the goals of a business is a problem that can benefit greatly from methodology and process. Software development methodologies provide guidance and structure around how to leverage the software writing activity towards the achievement of the goals of an organization. How the organization management interfaces with the engineering group. How performance is measured. How the team works more effectively as a team. How to manage external or last-minute requirements, even mid-stream. How to facilitate the team working at a regular cadence. How to improve predictability and accuracy of estimates.
Methodologies can help you achieve many efficiencies in your organization, but they can't help your developers learn how to type faster. So before you try out Scrum to address your execution problems, fail to address said problems, and then demonize Scrum for utterly failing to save you, be sure the problem you are trying to solve can actually be solved by adopting a software development methodology. If the problem you really have is that you want a full-term baby only 3 months after conception, what you need is an alternate universe, not a methodology.
(By the way, when you find that alternate universe, please comment. I'm sure everyone else would love to hear about it.)
Software Development Methodology Profile – Novell Forge
It was the fall of 2002 and I hadn't been in Novell's Developer Services group for more than a couple of months when I realized that the way Novell was maintaining and offering their developer content was flat-out broken. We needed a new process for delivering developer content that was a lot more dynamic and interactive. So I proposed we create a new web site with a web application that would allow us to publish more freely. We soon realized that we wanted to publish code too, not just documents, and that many of our developers wanted to also host and share their own code. The idea behind Novell Forge was born.
We were starting with an open source CMS, Xoops, and a fairly good-sized Xoops plugin named XoopsForge, but there was still a lot of software development needed to deliver Novell Forge from these foundational pieces. We had a smallish development team of four or five engineers and a project manager. I was somewhat unofficially designated as the lead. Having recently read a bit about Extreme Programming and being interested in trying some of the techniques out, I somehow convinced the project manager that we should try out a new way of developing software.
This methodology was so amazingly lightweight and simple, and yet it worked so remarkably well. It's shaped a lot of my thinking about software development ever since.
I wrote a very simple web application in PHP to facilitate the process.
- There was a story card entry page, where you could add a new story to the list of stories that comprised the product roadmap, or edit a story. Each story had only a couple of fields: a name, a description, and exit criteria. The exit criteria outlined a number of objective criteria that, if true, meant the story was complete. A developer could also assign himself or someone else to work on the story.
- There was a participant entry page, where you could add a new developer to the project, or edit one. This was pretty simple also, maybe just the name.
- There was a story prioritization list page.
- There was a dashboard where you could easily see who was on the team and what they were working on currently.
That's pretty much it. It took me about a day or so.
There were two keys to this. The first was that the stories were prioritized from 1 to N where N is the total number of stories remaining to be completed. This required a leap of faith on the part of the project manager, who had spent her entire career prioritizing features as P1 (mandatory), P2 (important), and P3 (desirable). Maybe your project does things this way too. Most companies I've worked for use this same technique.
Here's the problem with the P1-P2-P3 prioritization. Suppose the product manager, or whoever, puts together a requirements document. He lists all of the features and prioritizes each one P1, P2, or P3. Any guess how many of the features are P1? Based on my experience, probably about 60%-70%. Another 20%-30% are P2, with maybe only 10% or less prioritized as P3. What if the schedule can only allow us to do half of the requirements? This prioritization doesn't help us at all. When a developer finishes one assigned task, which should she work on next? If they are all prioritized P1 it is hard to differentiate.
Sorting all the stories from 1 to N forces the people managing the requirements to think about what really matters first. If you deliver each story completely and meet the exit criteria, the product should be "functional" with the new story fully integrated by the time it is done. Note that this doesn't necessarily mean the product is shippable after the first story. With Novell Forge, we knew we needed to deliver to about story 30 or 40 before we had a product we felt was worth releasing, but still we numbered every story from 1 to N.
A great benefit that comes from this is that now the developers can self-manage. Is my work done? This is easily determined by evaluating the progress against the exit criteria. What should I work on next? Just assign to yourself the next item at the top of the list.
The second key is trust. A lot of more complex methodologies add a lot more process to replace the need to address incorrect behavior by your developers. My web app didn't have any access controls, didn't have any roles or responsibilities. Anyone could add, delete, reprioritize, or assign stories, but the key is that they DIDN"T unless they were supposed to. Developers closed issues when they were done and assigned themselves more work when they needed stuff to do. They kept themselves busy and continually marching toward the goal. My point is this: If your team can't follow very simple processes, you might have a personnel problem, not a process problem. So don't try to fix your personnel problem by adding process complexity.
What were the results of this simple process? Well, for one thing, it put the team and management at ease. At any given point in the cycle, we had a functioning product with the most important features already delivered and the next most important features in progress. We could ship whenever we felt like it. We could decide to delay shipment until specific stories were done, or align our shipment with a specific event or announcement and go with what we had at the time. Great flexibility here.
But another, arguably better, feature of this methodology was that the developers loved it. They wanted to follow it because it was so lightweight, required so little of them, and assumed such a high level of trust from them. It helped them to focus on just doing their work, and it was easy to see us progressing toward shipment.
Ultimately, Novell Forge was delivered on schedule with the full feature set, but having the flexibility along the way made it a lot less stressful. Really, does the process have to be more complicated than that?
Discipline When You Need It Most
In the locker room for the University of Michigan football team there is the following quote:
Under pressure you will not automatically rise to the occasion and become a hero. You will revert to the level of your training effort and perform at that level.
Or something like that.
At least, that's what I've heard. I've never been in their locker room. But I remember hearing something about that on TV once and it really stuck with me.
If you are a football guy, this is the explanation for all those long hours of drills. The mantra, "You play the way you practice," exists for this reason: So that the level of your training will be sufficient to carry you through the crisis.
If you are a software person, this applies to you also. "Playing the way you practice" means having the discipline to follow your process all the time, even when you don't want to or feel pressure not to. In fact, especially when you don't want to or feel pressure not to.
The entire reason you have a process is to help you make decisions in hard times. If you are a software company that never has deadlines, never has commitments to meet, never has quality standards by which you are measured, then you probably don't need a process. You probably don't have customers, either. But if that doesn't apply to you, then you probably have a process, or need one.
Here are some examples of software development crises that are mitigated through process:
- Sales just told a big potential customer that your software contains a key feature that it doesn't actually have.
- A big partnership opportunity is available to your company if you will drop your current plan of record and instead implement a bunch of custom functionality.
- An executive just installed the beta of the next release of your product, and found out that you cut that executive's pet feature that his cousin really wanted.
- You are so sure the fix you just made couldn't possibly break the build, you are tempted to just check it in and go home instead of waiting for the test suite to run.
- You're nearing shipment of your product, so you are tempted to forego a new unit test for the bug you just fixed and just ship the thing.
- Your colleague or boss pressures you to just put in a "fix" for the product issue they found, even though the product is technically working as designed.
What should you do in each of these scenarios? I'll tell you:
You should follow your process.
Your process should tell you how to handle each of these situations, and it probably does. Scrum, for example, has built-in mechanisms for handling each of these scenarios.
The challenge is that when the pressure is on, you, along with every other normal human being, naturally feel tempted to cave in. The pressure of the situation causes you to panic. You don't make your decisions rationally and objectively. You make them based upon emotion instead, which is not generally the best guide.
When the pressure is on, it is more important than ever to follow your process. Trust it to help you make these and other decisions correctly. When you feel pressured most to abandon your process, that's precisely when it is most important to follow it.
Which is why you should always follow your process. During normal operations, your process may seem like it is oppressive or costly, and it may be. But if you follow your process when you don't have to, you will have the level of training you need to follow it when it will save you.
Software Development Methodology Profile – Spillman Technologies
Spillman Technologies was the first software company I worked for, from 1995 to 1998. When I worked for Spillman they produced a UNIX-terminal-based law enforcement database application for county sheriff offices and police departments. They had about 400 customers at the time. Spillman issued a major release of their software product once annually, and made money by selling support agreements to customers that included perpetual use of the latest version of the software as long as an active support agreement was in place.
Spillman had a feature gathering and prioritization technique that was pretty interesting and was quite popular with their customers, and still intrigues me to this day. This activity centered around their annual user's conference, which every customer was invited to attend. During the year (or more) leading up to the user's conference, Spillman's customer-facing departments, like sales and support, would gather feedback from customers and formalize them into proposals for new features.
The highlight activity of the user's conference was the lottery for new features for the upcoming release. Every customer was allotted a number of votes based on the size of their annual support contract. I don't know the real numbers, but as an example, you could say that each customer might get a vote for every $100 they spend annually on support. So during this lottery, each customer had the chance to review the proposed features and spend their votes on the feature or features they wanted most. They could spread their votes among a number of features they cared about, or spend their entire allotment on a single feature they needed the most.
Customers who did not attend could of course enter a proxy ballot to vote for the features they liked. At the end of this exercise, Spillman had an ordered list of the set of features their current customers most wanted to see in the next version of the product.
This list comprised a percentage of the upcoming release, not the total. Again, I never knew the exact numbers so these will just be hypotheticals, but you could suppose that the customer-voted features might comprise 40% of the total release. Certain other groups within the company would also have complete control over a certain portion of the upcoming release, e.g. product management might have 30%, support 20%, development 10%. Spillman didn't have a QA department at that time, but in a typical software company today you would probably adjust those percentages for QA.
Based on the percentages, Spillman would allocate a portion of the overall effort to each group. Going with our hypothetical example:
- Suppose there are 10 engineers on the product team, each working a 40-hour week. (Spillman was religious about 40 hour weeks and I hardly ever worked overtime.)
- Allocate 10 months for development work, and 2 months for integration, testing, porting, and release.
- Suppose your engineers are 50% efficient, alloting the other 50% for meetings, administrativa, training, vacations, business travel, and sustained engineering (i.e. bug fixing).
- We'll assume 10 months is 42 weeks, which is a little conservative. 42 weeks * 40 hours per week * 10 engineers * 50% efficiency = 8400 hours of work per release.
- 8400 hours breaks down as follows:
- Customer Features - 40% - 3360 hours
- Product Management - 30% - 2520 hours
- Support - 20% - 1680 hours
- Development - 10% - 840 hours
At this point, all of the candidate features from each bucket would be estimated and each bucket filled with the most important items. Once each allotment of hours was used up, the bucket was full and no more functionality would be accepted for that release.
This was a great way to make sure that each release contained at a minimum a sizeable percentage of new functionality that most of the customers cared about. Additionally, a group like Support would normally use their allotment to add features that were needed to address key customer pain points, usually issues not so large to receive the popular customer vote. Development always knew they had some time each release to do work they needed in order to minimize engineering debt (refactoring, for example, or perhaps writing automated unit tests, or advanced tools). Groups could barter with their allotments; for example, Support might need 1800 hours to implement all the functionality they need this release, so they borrow 120 hours from Development to get what they want, on the condition that they give Development 120 hours (or maybe more) next release to pay it back.
In my experience this worked really well for every party involved. Every group knew how to get the functionality they cared about most into the next version of the product. Customers were generally quite delighted with the product. And the development environment was very, very sane: Because of how the releases were organized, developers hardly ever worked any overtime. Each release was simply filled up with the most important features; once it was full, no more work went in. It worked great.
The Myth of the Detailed Design Advantage
There's a lot of approaches to the concept of software design, as it relates to software delivery. The places I've worked have spanned the spectrum from detailed up-front design to mostly agile approaches where very little design is done.
What I find odd and, frankly, erroneous is the idea that doing a large amount of detailed design work up front will:
- Make delivery faster
- Minimize unknowns
- Offer more precise delivery estimates
- ???
It seems that way because most of the questions get answered during the design phase. It probably is true that a detailed design gives you #2 and #3, and perhaps other things (#4). Importantly, however, it does not make delivery any faster.
Again: Detailed designs will not help you deliver any quicker.
There's a time period between concept and delivery. This time period is more or less constant:
|------------------------------------------------------------------|
There are some things you can do to make this time shorter: Add resources, or hire smarter people, for example. And there's some things you can do that don't really have any effect on the time period, like design work.
|-design-----------------------------------------|-implement-------|
For example, this graph indicates a lot of up-front design work.
|-design-----|-implement-------------------------------------------|
This graph indicates a more agile approach, with very little design work up front.
If you do the design work up front, the implementation becomes quicker and more predictable because you answered more questions during the lengthy design phase. If you go agile and do very little designing (mostly just story cards), implementation is much more exploratory and less predictable as a result. Mostly, though, you end up exerting the same amount of effort to get a delivered result.
Another thing these graphs can tell you is how happy your developers are:
|-design----------------------------------------------|-implement--|
These developers hate themselves and are looking for work elsewhere.
|-design--|-implement----------------------------------------------|
These developers love their job so much their faces hurt from smiling so much.
Clearly, if you want happy developers you should quit making them write such detailed design documents. The whole time they are writing those design documents, they wonder why they aren't just writing the code anyway. And you aren't really gaining anything by having them do such a laborious quantity of design; your delivery date will be the same anyway, so you might as well let them get to work.
Of course, there might be one small problem. You're clearly convinced, now, having read my very persuasive argument. But your project manager, or your boss, or the company policy-maker, might have a personal rule about reading my blog and they insist that they must — MUST!!! — have a much more predictable and trustworthy measurement, and they can't do such a small amount of design and leave the implementation so wide open and crazy.
If that is the case, it is time to relabel some things. Do a lot of up-front "design," where "design" means "mostly prototype, and also do some design." Now your graph looks like this:
|-mostly prototype and also design--|-implement--------------------|
This should make everyone a bit happier.
Getting Coders to Code
Think back over the last project you worked on and the time it took to complete it. How was that time spent?
At first glance you might come up with a list like this (in no particular order):
- Gathering requirements
- Designing
- Implementing
- Testing
Think about it harder, though, and you might come up with a number of additional things:
- Sitting in meetings
- Waiting for people to review and approve your documents
- Waiting for people to finish reviewing your code
- Reviewing other people's code and documents
- Setting up dev and test environments
- Dividing your logical tasks into smaller, sometimes illogical units for the purpose of tracking
- Entering tasks into an issue tracking system
- Documenting and updating status on assignments
- Reporting status to management
- Branching and merging
- Fixing bugs
- Reading e-mail
- Administrative and red-tape
Now, go through the list you have. Which one item are the customers actually paying for?
That's pretty easy — the implementation. Ultimately, what the customer is paying for is for you to write code.
This begs the following question: If writing code is what customers are paying for, why is so much time spent doing the other stuff?
Your knee-jerk reaction would probably be that all the other stuff helps you to do your job better. Generally, I'd agree that most of those other items CAN help you do your job better, but I'm going to challenge the reason why you are doing them.
Writing code is the primary activity of a software development team. To be more specific, writing correct code should be the primary activity of a software development team. Given a specific feature that customers will pay for, every correct line of code written for that feature directly contributes to revenue.
Therefore, in order to maximize revenue, your goals should be to:
- Maximize the amount of time that your developers can be writing code
- Optimize that time by improving the likelihood of each line of code being correct
Seems pretty simple, right?
Now, take a look at the way you conduct your work. Ask yourself this question: How would your work change if the focus was to spend as much time coding as possible, and to improve the correctness of each line of code?
Would you change the way you do your work? If so, why are you working that way?
