More Work?
Forgive a little advocacy, please
Some programmers told me that they understand how management benefits from agile development in flexibility and risk reduction. However, they said, it is a lot more work than non-agile development. There are more steps to the code-writing task than in old-style development where you "just write the code". You move more slowly with more steps.
I remember when I first started reading about eXtreme Programming. The theory then was that it was going to make programmers happy, but that management would never go for it. Now we find that the argument is that it's great for managements, but that it is harder for programmers? Why the 180-degree turn? Have we sold it more successfully to managers than to programmers?
The thing that's hard to value in the old model is that you are never "just writing code" throughout the project. You are also battling integration problems, build problems, surprising little bugs, etc. You get slowed down by messy code. You learn to workaround crummy code, and have to rewrite parts of it sometimes. Everyone makes mistakes, but you aren't aware of the problems you create until someone actually tries the parts that you've broken. Likewise, your code won't work because someone else broke it and you are called over to fix it when it's not even your problem, really. You end up under increasing end-of-project pressure to deliver functionality in an increasingly difficult code base. And for this you hear "that's just how it is."
What if that's not how it has to be?
With TDD and pairing, you find out about your mistakes much sooner and you help your partners correct theirs sooner. Those bugs that make it past the second set of eyes (partner) and the unit tests are detected by the massive battery of unit and acceptance tests that are run every few minutes (possibly every few hours in uglier cases). You are able to avoid those hellish sessions where everything has changed and something has broken but nobody knows quite what it was. You are integrating all the time, so those integration problems don't fester and rot for months. But you are working on these things sooner and more often - all the time in fact.
With refactoring, you simplify your code all the time. You have a pair partner, and that helps to tell if it's easy to read your code or not and whether it is misleading in some way. You keep the quality up from the beginning, and you fix anything that doesn't look right as soon as it starts to look funny. You don't do this when a crisis arises, but sooner and more often. All the time, in fact. At least in theory -- though anyone on your team can refactor to make things more clear. You clean code together and individually.
With iterations, you know what you have to work on in the short term. You know when you're done. You know how far behind you are all the time <.5 wink>. You know how much you are able to get done, and you are not given work beyond your measured ability to deliver. You don't have slack time, but you are never 180% overcommitted. Rather than push the team to commit 110%, the agile project reduces scope to make the end date possible.
Because of shared code ownership, there is no one person who has to carry the team. Since there is no single anchor person, anyone can be sick or have a day off sometime. No one person has to work 24x7 to keep the team alive, no one person can sink the effort.
If you are always ready for a release (after a certain iteration, I know) then a release is no longer a stressful occurrence. The strain is evenly spread throughout the development process. Panic mode is very, very rare. The testing team should be involved from the first iteration, so even they aren't pulling all-nighters. The installer is being built and tested as part of the iteration, so the build team doesn't have to panic.
So if this is possible, if this is the plan, then why isn't this really attractive to every programmer?
The cost of an even strain is an even strain. You don't have a big tail-end rush because you have a lesser ongoing integration and release pressure. You don't have tail-end integration panic because you have monitoring and correction in the daily ATs and UTs. You don't have code rot and design, because you do constant code cleaning and refactoring. Your work is more of a steady-state, and you are in control of more of it. Maybe it is more work. I guess I understand how it seems that way. It is better and more certain work, though.
Agile programmers I know aren't interested in going back to "the old way" of working, mostly for these very reasons. They know what to do each iteration, and they are allowed to do it very well. They expect to work hard each day and go home at a reasonable hour. They always know whether the work is going well or not. They have a sense of professionalism and quality, and know that they can attend their kids ball games in the evening. They say that it's less work, really, in a "quality is free" sense. They say that it easily pays for itself in time and effort and emotional wear-and-tear.
!commentForm
Tim! I think you shouldn't forget what you've learned about agile development in the mean time!
Especially practicing TDD is hard for people that have practiced implementation driven design (IDD)
for years or even longer and sure, in the beginning it'll take more time since lot's of
learning is included.
I'm convinced that TDD should be tought in schools for that's the place where it's easies to learn
(although the teacher's I know aren't capable of teaching it :-( ).
In high jump, it must have been extremely hard for the elder athlets to jump with the back first but it's the only way
to pass the bar with the mass center below the bar and thus it was the only way to remain competitive
(see http://en.wikipedia.org/wiki/Fosbury_Flop). That's the situation TDD is in now.
I think the best way to introduce agile methods is in a smooth transition. One step after the other with visibly earned
value in each step (starting with CI is easies...).
Once people see the benefits and you show them that you can fix a bug in thirty seconds including testing
(where you could unltimately proove that the fix will not raise side effects), you'll make them curious and eventually, things will
run in the right direction.
Good luck!
Especially practicing TDD is hard for people that have practiced implementation driven design (IDD)
for years or even longer and sure, in the beginning it'll take more time since lot's of
learning is included.
I'm convinced that TDD should be tought in schools for that's the place where it's easies to learn
(although the teacher's I know aren't capable of teaching it :-( ).
In high jump, it must have been extremely hard for the elder athlets to jump with the back first but it's the only way
to pass the bar with the mass center below the bar and thus it was the only way to remain competitive
(see http://en.wikipedia.org/wiki/Fosbury_Flop). That's the situation TDD is in now.
I think the best way to introduce agile methods is in a smooth transition. One step after the other with visibly earned
value in each step (starting with CI is easies...).
Once people see the benefits and you show them that you can fix a bug in thirty seconds including testing
(where you could unltimately proove that the fix will not raise side effects), you'll make them curious and eventually, things will
run in the right direction.
Good luck!
"Forgive a little advocacy plese": Change "plese" to "please"
Thank you. Forgive the little typo, please! :-) Tim Ottinger
Thank you. Forgive the little typo, please! :-) Tim Ottinger
Chinese martial arts already know how to jump several meters high (up to 5 meters) not going "back first" but "front first" and using both feet.
What I mean by this, is that there are several ways to solve a problem, and some ways are better than others, but some require more preparation than others.
We have found a local maximum and we call it XP. But in order to achieve that performance you need an XP mentor. How long? A few months? A few years? This doesn't mean that there is other practice that is several times faster than XP, but that you need a mentor for a 100 years in order to learn it properly.
What I'm trying to say is that probably you can get up to speed faster in VB, but if you are going to stick around developing software for at least a decade, you better learn Java. And if you are going to stick longer you better learn Smalltalk, Lisp and Prolog.
What I mean by this, is that there are several ways to solve a problem, and some ways are better than others, but some require more preparation than others.
We have found a local maximum and we call it XP. But in order to achieve that performance you need an XP mentor. How long? A few months? A few years? This doesn't mean that there is other practice that is several times faster than XP, but that you need a mentor for a 100 years in order to learn it properly.
What I'm trying to say is that probably you can get up to speed faster in VB, but if you are going to stick around developing software for at least a decade, you better learn Java. And if you are going to stick longer you better learn Smalltalk, Lisp and Prolog.
TDD is less work at the beginning, because:
1. You need to learn TDD, but once you have learned it, it becomes easier.
2. When the project is about to end, you may change previous decisions confidently, because any change you make that brakes something is not checked-in.
So eventually the project goes much faster than the day before.
1. You need to learn TDD, but once you have learned it, it becomes easier.
2. When the project is about to end, you may change previous decisions confidently, because any change you make that brakes something is not checked-in.
So eventually the project goes much faster than the day before.
As a project manager, I'm in the center of the hurricane, in a team fighting to change the development process from a traditional waterfall to agility at it's best. Our team have both young developers (who act like they have had TDD fed to them in their mothers milk), and older ones that struggle just to understand the idea at all.
The bosses above the project level naturally ask the question: "is it worth it?". Some may even have put it: "Is it worth the extra work?". Fortunately, they have confidence in the project management when we state: "just wait and see!".
Granted, we have had a really hard time!
Just getting to the point where we can derive the teams "per iteration productivity" is hard (actually we've not yet been able to "guesstimate" the amount of functionality we'll be able to produce in the timebox we've been given).
But I still think we're able to prove a couple of important points :-)
1. Going from "the old school" to agile development costs. Absolutely! But it's not in the coding it self! It's in the transition process!
2. You shouldn't judge (the cost of) agile development, until its actually fully implemented. I mean, ..you wouldn't conclude that a bulldozer is no good at moving mountains of trash, if it hasn't got it's showel fitted :-)
My point is that I think the focus is on the wrong kind of cost. There IS no extra time used to code, when doing so in an agile project! The time is just used differently!
I'm not sure I agree with Sebastian in his claim that agile development should be introduced in small steps. Actually I think the benefits will only be visible, if all the steps in the process are implemented as a whole!
OK, ..it might be a bit harder to make the transition, but the "wake up call" on the first day when it actually works, will be that more obvious!
It's hard work to do the transition. it's hard for some developers trying desperately to understand the idea. It's hard for management to accept that the productivity of the project falls for a while (and doesn't seen to correct itself). And it's hard for the project management to keep up the moral and motivation in the team, if quick succes is not visible. A lot of attention is given to the development team, and often the developers are blaimed, if the team doesn't meet the deadlines. But I think that too little attention is given to the enormous responsibility that lies with the project management.
It's a change process, and changes are hard! In fact, ..most people try to avoid change as a reflex. And that's where the cost is! Anger, frustration, joy, embaressment, ...emotions! Thats what it's about! And that isn't handled by presenting flowcharts and showing code examples of how to write a proper unittest. Demand that your project manager takes this aspect of the transition seriously!
We are beginning to see the light at the end of the tunnel :-). And if you are in the middle of a similar transition, I can give you a hint about when to start enjoying the ride. When the reactions from the team members change from demonstrations of resistance, to pointing out the situations when someone steps outside the lines, ..then you know you're heading the right way :-)
The bosses above the project level naturally ask the question: "is it worth it?". Some may even have put it: "Is it worth the extra work?". Fortunately, they have confidence in the project management when we state: "just wait and see!".
Granted, we have had a really hard time!
Just getting to the point where we can derive the teams "per iteration productivity" is hard (actually we've not yet been able to "guesstimate" the amount of functionality we'll be able to produce in the timebox we've been given).
But I still think we're able to prove a couple of important points :-)
1. Going from "the old school" to agile development costs. Absolutely! But it's not in the coding it self! It's in the transition process!
2. You shouldn't judge (the cost of) agile development, until its actually fully implemented. I mean, ..you wouldn't conclude that a bulldozer is no good at moving mountains of trash, if it hasn't got it's showel fitted :-)
My point is that I think the focus is on the wrong kind of cost. There IS no extra time used to code, when doing so in an agile project! The time is just used differently!
I'm not sure I agree with Sebastian in his claim that agile development should be introduced in small steps. Actually I think the benefits will only be visible, if all the steps in the process are implemented as a whole!
OK, ..it might be a bit harder to make the transition, but the "wake up call" on the first day when it actually works, will be that more obvious!
It's hard work to do the transition. it's hard for some developers trying desperately to understand the idea. It's hard for management to accept that the productivity of the project falls for a while (and doesn't seen to correct itself). And it's hard for the project management to keep up the moral and motivation in the team, if quick succes is not visible. A lot of attention is given to the development team, and often the developers are blaimed, if the team doesn't meet the deadlines. But I think that too little attention is given to the enormous responsibility that lies with the project management.
It's a change process, and changes are hard! In fact, ..most people try to avoid change as a reflex. And that's where the cost is! Anger, frustration, joy, embaressment, ...emotions! Thats what it's about! And that isn't handled by presenting flowcharts and showing code examples of how to write a proper unittest. Demand that your project manager takes this aspect of the transition seriously!
We are beginning to see the light at the end of the tunnel :-). And if you are in the middle of a similar transition, I can give you a hint about when to start enjoying the ride. When the reactions from the team members change from demonstrations of resistance, to pointing out the situations when someone steps outside the lines, ..then you know you're heading the right way :-)
I'm seeing the problem move from "the developers aren't agile" to a bigger problem of "only the developers are agile"
Add Child Page to MoreWork