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