Sooner, Not Faster
There is a widely-held myth (well, near-myth) that Agile software development is about "going faster". It's really not. Oh, you might go a little faster, but that's not what it's about. To go faster, one will tend to optimize by shortcutting the process and accepting lower quality work, by sacrificing health to long hours, etc. Agile methods have strict discipline to avoid these things, and agile projects do end-of-project work sooner and more often than a typical waterfall project. Agile actually adds some valuable steps to the process. It's "more work", though it's more certain.
Faster can be dangerous. If you are running at break-neck speed, and then you come upon a steep downgrade, you are likely to go pinwheeling out of control and break something. Hopefully something cheap. Pushing someone who is running as fast as they can is likewise unhelpful. They will make much *less* progress when they're lying broken on the track. You probably can run a little faster than you think, and a little longer. If you are on foot and going faster than you can run, however, you are in big trouble.
Likewise, coding faster than you can safely code is dangerous. Things are left undone, things are broken in subtle ways, things are not tested, problems are not understood. The effort quickly pinwheels out of control. It's likely that you develop code faster than you think you can, but if you are going faster than you are able to manage, you are in very big trouble indeed.
Agile helps maintain control. You know when you're breaking more code than you're fixing. The feedback (tests, partner, etc) says you'd be better off at home, in bed, than creating disasters for the next four hours. You're not going faster or working longer hours per day. You're using the best measured pace you can sustain. You may end up going a little faster than you thought you could, but you won't be going faster than you are able.
If you are going faster than you are able to manage, then what you are doing is not agile, it's just hurried. Your managers and customers want code sooner, but do they really want "hurried" code from an exhausted, out-of-control team? I can't tell you how often in my early career I've been on teams pushed to go faster and faster, only to be blasted by the same managers for being out of control. They didn't really want faster. They wanted sooner.
Instead, Agile projects are about being "done" sooner, more certainly, and more often (for larger values of "done").
In agile projects, you are always ready to deploy, starting with the end of the first iteration. Mind you, nobody may want that pathetic first increment, but nonetheless it is supposed to be ready. The extent to which each team is succeeding is the extent to which each release is ready to be deployed. If there is patch-up work, integration work, and testing to be finished, then your iteration is actually not done. The "no partial credit" rule says you have to be finished with all tests passing. If you still have to "finish" anything then, by-definition, you are not done, yes?
Being done is more work than not being done. You have to prepare the build system sooner, the installers sooner. You have to have a working build system sooner. You have to keep these things in good working condition all through the project. But being able to deploy to a project stakeholder means that there will be more feedback on the work that's been done. This feedback allows validation sooner, and that means that correction can be done sooner, hopefully before a real customer deployment. That means that it will be correct sooner, even though you're not working faster.
You are supposed to be "done" often. Every month, every two weeks, every week.
Mind you, the world will still want "faster" too. But agile will give you sooner instead. Be sure you know what you want.
!commentForm
This is a common misunderstanding that I see often with people who are not familiar with Agile development. I think the cause is the term "Agile" (please note that I am not suggesting to change it).
Agile development is the latest refactoring of our development method, we (the programming comunity) started with water fall, refactored it to RAD, refactored RAD to Iterative, then refactored Iterative to Agile. (Did I miss any? :)
I wonder what will be the outcome of refactoring Agile development?
btw, this roman number conversion is very annoying.
Agile development is the latest refactoring of our development method, we (the programming comunity) started with water fall, refactored it to RAD, refactored RAD to Iterative, then refactored Iterative to Agile. (Did I miss any? :)
I wonder what will be the outcome of refactoring Agile development?
btw, this roman number conversion is very annoying.
There were several correct points in your post, I especially emphasize that agile development adds more value to the process.
But you miss the point.
The major way to achieve faster development is through cutting out waste, that is useless features, useless design and last but not least useless code resulting from i.e. up front design, or no violation of best practices, no testdriven development and no pair programming.
Based on the simple fact, that one can only do a certain amount of work per abstract unit of time, it follows that it is not possible to work MORE in this unit, except - of course - through more motivation, selforganisation and responsibility. Still agility helps to focus on value added work and minimizes waste thorugh continuous learning and improvement.
Also in an agile environment you would not "push" a developer, as the developers commit themselves only to what they choose!
http://sheyll.blogspot.com
Actually, we violently agree here. I would say that the mantra of "maximize the amount of work done" has everything to do with sooner precisely because it avoids doing the same amount of work faster. -- Tim
But you miss the point.
The major way to achieve faster development is through cutting out waste, that is useless features, useless design and last but not least useless code resulting from i.e. up front design, or no violation of best practices, no testdriven development and no pair programming.
Based on the simple fact, that one can only do a certain amount of work per abstract unit of time, it follows that it is not possible to work MORE in this unit, except - of course - through more motivation, selforganisation and responsibility. Still agility helps to focus on value added work and minimizes waste thorugh continuous learning and improvement.
Also in an agile environment you would not "push" a developer, as the developers commit themselves only to what they choose!
http://sheyll.blogspot.com
Actually, we violently agree here. I would say that the mantra of "maximize the amount of work done" has everything to do with sooner precisely because it avoids doing the same amount of work faster. -- Tim
When in primary school, my report cards included grades for effort and achievement. When I entered grade 6 (as we say in Canada), the effort grade disappeared, leaving only an achievement grade. In (now) over 20 years, the effort grade has never returned.
"Fast" is a measure of effort. To "deliver faster" (really "more quickly") means to try to do the same things in less time. How much we /do/ is a measure of effort. That's nice, but I can't feed my family with effort.
"Soon" is a measure of achievement. To "deliver sooner" means to put value in the hands of the customer sooner, by whatever means you can, including /doing/ fewer things (possibly even more slowly!). It is a measure of achievement, and that's why CEOs pay me.
Therefore, I believe my job is to deliver sooner, rather than more quickly, so I believe my greatest contribution to a project is to identify work that does not need to be done.
"Fast" is a measure of effort. To "deliver faster" (really "more quickly") means to try to do the same things in less time. How much we /do/ is a measure of effort. That's nice, but I can't feed my family with effort.
"Soon" is a measure of achievement. To "deliver sooner" means to put value in the hands of the customer sooner, by whatever means you can, including /doing/ fewer things (possibly even more slowly!). It is a measure of achievement, and that's why CEOs pay me.
Therefore, I believe my job is to deliver sooner, rather than more quickly, so I believe my greatest contribution to a project is to identify work that does not need to be done.
Abdul Habra says:
I think the cause is the term "Agile"
Which is funny, really. Agile doesn't mean that you run very fast, it means you can turn or leap very suddenly. It's really more about the opportunity and effectiveness of steering rather than acceleration or rate of travel. In fact, a physical object traveling at a higher rate of speed becomes less agile (according to Newton).
Hmmm....
Dude,
I'm sure it's just me, but I often feel that Agilists portray themselves unnaturally wholesomely. As though they work in Level 5 clean-rooms, in white, plastic overalls; they address one another as Mister Darcy, and Mzz Woebetide; they write perfect code in perfect silence in perfect synchronisation; and at the end of the day they strip off to their grey suits and frocks and disperse wordlessly into the shiney, glass skyscrapers of PerfectVille[?].
That made my skin crawl when I read the comment, "Also in an agile environment you would not "push" a developer, as the developers commit themselves only to what they choose!"
If I could choose a methodology, I choose one that supported lazy, moaning, uninvolved, smelly programmers with hangovers.
Now that'd boost productivity ...
www.EdmundKirwan.[?]com
PS I second, third, and fourth the call to get rid of this irritating roman numeral check; or at least post a link to a good translator.
I'm sure it's just me, but I often feel that Agilists portray themselves unnaturally wholesomely. As though they work in Level 5 clean-rooms, in white, plastic overalls; they address one another as Mister Darcy, and Mzz Woebetide; they write perfect code in perfect silence in perfect synchronisation; and at the end of the day they strip off to their grey suits and frocks and disperse wordlessly into the shiney, glass skyscrapers of PerfectVille[?].
That made my skin crawl when I read the comment, "Also in an agile environment you would not "push" a developer, as the developers commit themselves only to what they choose!"
If I could choose a methodology, I choose one that supported lazy, moaning, uninvolved, smelly programmers with hangovers.
Now that'd boost productivity ...
www.EdmundKirwan.[?]com
PS I second, third, and fourth the call to get rid of this irritating roman numeral check; or at least post a link to a good translator.
I'm sure it's just me, but I often feel that Agilists portray themselves unnaturally wholesomely.
Aren't you glad you have me to tell you that it's tough? In the steady state, we are supposed to come to work ready to rock-n-roll, play our A game all day, and then go home exhausted and ready to be out of the office. Work really hard for your work hours then go home. We don't always live the reality because sometimes you need to take a break before you mess something up, and because it's software and software is naturally messy work. Sometimes you stay over and sometimes you don't want to.
I hate it when it's portrayed as all roses. It's software, after all. Agile is a minimal process, but it's still a process. Sometimes it is misapplied, sometimes it is misunderstood. Also we're all still people and different people see things differently.
You could look at agile development as a kind of an inclined gutter in which we run. If that makes us a little smelly, grumpy and apt to moan and grip, then so be it.
I feel developing software is a lot like paying taxes. You can pay by the week or by the month or by the quarter or you can wait and pay it all at the end of the year. Agile pulls up a lot of the work into weekly or monthly installment payments so that you're not a trainwreck when the full amount comes due. You realize each paycheck that you're paying, but you also know that you might break even or come out slightly ahead at the end. When you aren't making installments continually, you end up paying tax, interest, and penalty at the end.
Mind you, on a good day it can be fun. But it's never a clean, wrinkle-free life.
That made my skin crawl when I read the comment, "Also in an agile environment you would
not "push" a developer, as the developers commit themselves only to what they choose!"
Agile teams do self-organize rather than having work assigned to them. Also, they make their own estimates, so they are not pushed (only held to them). The funny part is that it doesn't actually make the work easier. It sounds like a party, but even though the rules change, it continues to be the same hard, human, creative work every day. We are just more certain about the state of the code at any given point in time and we don't have the same burden for paperwork and meetings and nonsense.
I'm sure it's just me, but I often feel that Agilists portray themselves unnaturally wholesomely. As though they
work in Level 5 clean-rooms, in white, plastic overalls; they address one another as Mister Darcy, and Mzz Woebetide;
they write perfect code in perfect silence in perfect synchronisation; and at the end of the day they strip off to
their grey suits and frocks and disperse wordlessly into the shiney, glass skyscrapers of PerfectVille.
Wow, I can't feel bad enough for that perspective. I can't think of a less-apt description of an agile team than the foregoing. We work on the edge of chaos, make tons of mistakes very quickly, kill and heal our designs several times daily, yell at each other and go home exhausted. Sometimes, we bathe.
What I do have, however, is a rosy ideal to work towards. What if we didn't have to write all that unnecessary documentation? What if we felt free and confident to change any line of code at any time, even on the last day of a release? What if every time I had a question, I got an answer soon enough to help me? I just refuse to believe that's impossible.
Add Child Page to SoonerNotFaster