Agile Means you never have to meet your deadlines
We, at Object Mentor, transition a lot of companies to Agile Methods. We help them learn and adopt the disciplines, and we help them adjust and change the organization. We've done this many times, and we do it very well.Companies call us for a multitude of reasons. Often those reasons are healthy. They want to manage their software development better; or they want a lower defect rate, or they want to improve their productivity; or... But sometimes development organizations ask for our help to convince their management that they don't really have to meet their deadlines.
It is true that Agile Methods promote scope management as one way to manage dates. It is also true that Agile Methods promote the notion of sustainable pace. Sometimes, however, you are in a run for your life. When that's the case, the only pace that is sustainable if a flat out run.
Clearly this isn't ideal. Agile Methods provide ways to help teams estimate and manage risk. Agile methods allow teams to choose makeable dates. But Agile Methods aren't magic. Just because you adopt an Agile Method, it doesn't mean that the business suddenly doesn't need the system it's been counting on for the last several month. Bringing Agile Methods into the middle of a project and then asserting that this means you don't have to make your deadlines is silly. If the business is counting on the dates, then the dates have to be met. If they can't be met, then the business need to know as soon as possible so that remedial action can be taken.
Agile can help with that last bit. By working in small increments and measuring the progress of each increment, you can accumulate data that tells you just how much trouble you are really in. Then the business can determine what to do about it. One of the things they may determine is that the development team has to pull out all the stops and drive like crazy to meet their dates.
Agile can help you measure, it can help you predict, it can help you estimate, mitigate risk, and choose meetable dates. But Agile does not mean that you don't have to make your deadlines. Agile does not mean that the developers get to ignore their previous committments. It does not mean that the business should suddenly ignore all the plans it has been making.
Agile is a tool, not an excuse.
!commentForm
I don't know any company where management accepts the developers not to meet deadlines,
no matter if they are "agile" or not. That's the business.
I have a question about transition to Agile Methods:
Is it better to do the transition in one step or
can I do it incrementally.
My current plan towards agility is as follows:
1. Automate Bulids.
2. Automated tests for everything.
3. Transition to agile project management.
Is this a good idea or is this the wrong order?
Pair programming is no option. Developers are scared of it.
I renamed it to "coaching" and it's done whenever somebody
needs help. Maybe I can take away the fear somewhen and
pairing gets "normal" for them.
no matter if they are "agile" or not. That's the business.
I have a question about transition to Agile Methods:
Is it better to do the transition in one step or
can I do it incrementally.
My current plan towards agility is as follows:
1. Automate Bulids.
2. Automated tests for everything.
3. Transition to agile project management.
Is this a good idea or is this the wrong order?
Pair programming is no option. Developers are scared of it.
I renamed it to "coaching" and it's done whenever somebody
needs help. Maybe I can take away the fear somewhen and
pairing gets "normal" for them.
Dear uncle Bob,
There's not much about (Java) Exception design in your GREAT book "Agile Software Design", in fact, how to design and handle exceptions is only mentioned in few place (e.g.,page 341, you turned an exception into an error for you don't want to pollute the interfaces!) Exception handling puzzled me a lot, could you give me some explanation (maybe in your next blog) or give me some references where I could find your guidance?
BTW, Does Object Mentor has intern position in Beijing,China?
Best Regards
-Birkey Ma
mabo@ios.cn
Lab for Internet Technology
Institute of Software, Chinese Academy of Science
There's not much about (Java) Exception design in your GREAT book "Agile Software Design", in fact, how to design and handle exceptions is only mentioned in few place (e.g.,page 341, you turned an exception into an error for you don't want to pollute the interfaces!) Exception handling puzzled me a lot, could you give me some explanation (maybe in your next blog) or give me some references where I could find your guidance?
BTW, Does Object Mentor has intern position in Beijing,China?
Best Regards
-Birkey Ma
mabo@ios.cn
Lab for Internet Technology
Institute of Software, Chinese Academy of Science
Transitioning incrementally is definitely preferred. I usually recommend that you:
As for the developers being afraid of pairing: I don't make it a rule. However, I DO NOT let the developers own modules. I keep the source code control system non-blocking, and I make sure that the developers choose tasks in different modules each iteration. I want the code to be owned collectively, not by individuals. This STRONGLY promotes pairing.
- Move into an open office or lab.
- adopt short cycles (1-2 weeks) with the planning game.
- Adopt Test Driven Development for unit tests.
- Adopt Automated Acceptance Testing (with e.g. FitNesse).
- Gradually adopt the other practices.
As for the developers being afraid of pairing: I don't make it a rule. However, I DO NOT let the developers own modules. I keep the source code control system non-blocking, and I make sure that the developers choose tasks in different modules each iteration. I want the code to be owned collectively, not by individuals. This STRONGLY promotes pairing.
Uncle Bob said:
<i> Transitioning incrementally is definitely preferred. I usually recommend that you:
Move into an open office or lab.
adopt short cycles (1-2 weeks) with the planning game.
Adopt Test Driven Development for unit tests.
Adopt Automated Acceptance Testing (with e.g. FitNesse).
Gradually adopt the other practices.
As for the developers being afraid of pairing: I don't make it a rule. However, I DO NOT let the developers own modules. I keep the source code control system non-blocking, and I make sure that the developers choose tasks in different modules each iteration. I want the code to be owned collectively, not by individuals. This STRONGLY promotes pairing.</i>
I agree that any transition must be made incrementally, slowly adapting what you are doing, making sure the new process sinks in.
I just do not agree on the schedule:
1. First I would make sure that all the code is in CVS, subversion or similar code repository.
2. Then and only then, I would make sure that all the code is compiled with ant or similar tool.
3. Then I would make sure there is a LuntBuild[?] or CruiseControl[?] machine making sure the code in the repository compiles after any check-in.
4. Then I would introduce code reviews (or pair programming) + code conventions + unit tests.
5. When the past practices are working I would introduce Staging for everyone to be able to test the system. Staging should be rebuilt twice a day automatedly using LuntBuild[?] or CruiseControl[?].
6. Then I would introduce a bugtracker (XP advocates do not like bugtrackers, but the client probably would prefer to simply explain what went wrong, besides other agilists like Scrums masters accept bug trackers, they just call them backlog trackers).
7. Then I would introduce 2 week cycles. The system is built twice a day, but we want stable requirements for 2 weeks, thanks. Usually the problem here is that it takes some time to accept the requirements, call them user stories or use cases, the fact is that most of the time they are underspecified or they are inconsistent.
8. Then I would adopt TDD. Specially for reported bugs, so that once solved they are not reintroduced.
9. Then I would move to an open bay, to make sure everyone listens when we speak, but make sure there are windows so that you can see the light of the day.
10. Then automate acceptance testing.
11. Then, once we are advancing faster than we promise, I would be strict about working 8 hours a day.
12. Prototypes or spike solutions (proofs of concept) should be used to reduce technological risks.
13. Then adopt other practices as you see fit.
<i> Transitioning incrementally is definitely preferred. I usually recommend that you:
Move into an open office or lab.
adopt short cycles (1-2 weeks) with the planning game.
Adopt Test Driven Development for unit tests.
Adopt Automated Acceptance Testing (with e.g. FitNesse).
Gradually adopt the other practices.
As for the developers being afraid of pairing: I don't make it a rule. However, I DO NOT let the developers own modules. I keep the source code control system non-blocking, and I make sure that the developers choose tasks in different modules each iteration. I want the code to be owned collectively, not by individuals. This STRONGLY promotes pairing.</i>
I agree that any transition must be made incrementally, slowly adapting what you are doing, making sure the new process sinks in.
I just do not agree on the schedule:
1. First I would make sure that all the code is in CVS, subversion or similar code repository.
2. Then and only then, I would make sure that all the code is compiled with ant or similar tool.
3. Then I would make sure there is a LuntBuild[?] or CruiseControl[?] machine making sure the code in the repository compiles after any check-in.
4. Then I would introduce code reviews (or pair programming) + code conventions + unit tests.
5. When the past practices are working I would introduce Staging for everyone to be able to test the system. Staging should be rebuilt twice a day automatedly using LuntBuild[?] or CruiseControl[?].
6. Then I would introduce a bugtracker (XP advocates do not like bugtrackers, but the client probably would prefer to simply explain what went wrong, besides other agilists like Scrums masters accept bug trackers, they just call them backlog trackers).
7. Then I would introduce 2 week cycles. The system is built twice a day, but we want stable requirements for 2 weeks, thanks. Usually the problem here is that it takes some time to accept the requirements, call them user stories or use cases, the fact is that most of the time they are underspecified or they are inconsistent.
8. Then I would adopt TDD. Specially for reported bugs, so that once solved they are not reintroduced.
9. Then I would move to an open bay, to make sure everyone listens when we speak, but make sure there are windows so that you can see the light of the day.
10. Then automate acceptance testing.
11. Then, once we are advancing faster than we promise, I would be strict about working 8 hours a day.
12. Prototypes or spike solutions (proofs of concept) should be used to reduce technological risks.
13. Then adopt other practices as you see fit.
Add Child Page to AgileMeansYouNeverHaveToMeetYourDeadlines