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.)
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.
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?
