-
I’m a Leader… I Want to be Alone
May 24, 2012
-
Two Types of Workflow: Software and Human System
May 24, 2012
-
10 Benefits of a Project Management Software System
May 24, 2012
-
Spotting a Failing Project: 9 Warning Signs
May 23, 2012
-
Values of Effective Project Managers
May 23, 2012
-
Calm in the Eye of the Storm
May 23, 2012
-
Management by Heroics
May 22, 2012
-
Project Planning for Project Sponsors: Why You Need To Be Involved
May 22, 2012
-
Lost in Projects - Integrated Project Management
May 22, 2012
-
10 Warning Signs that Your SharePoint Implementation May Be Heading for Difficulty
May 21, 2012
The Perils of Fast Development in Agile
January 26, 2009 | Author: PM Hut | Filed under: Agile Project Management, Project Management Musings
The Perils of Fast Development in Agile
By Olve Maudal
Why do you have brakes in a car? Because then you can drive faster.
I like this quote, and I find it very relevant to modern software engineering. Teams that know when and how to use the brakes can drive a project fast and still arrive safe and sound at the final destination. But some agile teams are speeding; driving too fast, reluctant to actually use the brakes, and so they drive a project off the road. For example, sometimes you see teams being so much focused on implementing customer visible features that they forget about the importance of a sound and solid internal infrastructure. It seems like the old “nah, we are in a hurry, let’s write tests and documentation later” (which nobody did of course) has now been replaced with “nah, we are in a hurry, let’s do proper design and architecture later” (and this will of course never happen either).
Agile methodologies encourages you to do things in small steps, often in cycles that can be measured in seconds or minutes. It does not really matter if you do ‘think/change/test’ or ‘add test/change/refactor’, sometimes you will meet challenges that require many hours or days or even weeks to do properly. Just as we in the old days could spend months on a Big Design Up Front (BDUF) before starting to code, we must now be prepared to pause once in a while and spend some time thinking. For example, suppose you are to implement a feature where you need to store some values for later retrieval. You realize that you need some kind of persistence mechanism - and it is obvious that a big chunk of internal infrastructure is missing. This is a time where you need to slow down and make sure that you do this properly. Being agile should not be used as an excuse for just mocking up some poorly designed ad-hoc persistence mechanism.
If you do not slow down when required you will end up with bad design and architectural rot. Soon developers will start to complain about: “it is hard to find stuff”, “it is hard to add stuff”. Despite everybody working very hard, the real progress of the project is next to nothing. The project is like a car stuck in the mud, now pressing hard on the accelerator pedal is not what you want to do. This is not a time for more hard work, now you need to start thinking. You have wasted a lot of time and effort already, but if you are willing to backtrack a bit you might be able to fix the bad design, improve the architecture and get the project back on track. Not slowing down when required will cost you a lot in terms of time and effort, but also in frustration and lost confidence from developers and management. Actually, just like when driving a car, the penalty of driving too fast is so high that (most of us) always prefer to have a large security buffer. If you are eager to successfully complete one project after another, then behave and drive sensible. But of course, in software engineering there are no real cops watching you, so if you can see a very long open stretch, then go for it…
Olve Maudal is a software engineer based in Oslo. He has worked for several Norwegian high profile companies such as Schlumberger, BBS, and Tandberg. He blogs regularly on http://olvemaudal.wordpress.com/ about Agile Project Management, software architecture, and coding.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
2 people have left comments
I agree with the underlying notion that speed is not necessarily the bee all and end all. And if it’s just speed you’re worrying about, then for sure you’ll get yourself into trouble.
I have written a blog about this http://blog.agilebuddy.com/2009/01/agile-is-not-just-about-speed.html
However,comments such as “Agile methodologies encourages you to do things in small steps, often in cycles that can be measured in seconds or minutes.” are really not accurate.
No one in their right minds would be managing projects down to minutes. That’s really not the point of Agile. It’s about being Agile not about speed.
My 2 cents
Jack
http://www.agilebuddy.com
Becoming more agile *should* increase your team’s productivity as they continuously improve and weed out unnecessary tasks. But is it dangerous to suggest that becoming agile equals moving faster?
As I read this post I started asking myself, “how much of what’s being said here could be applicable outside of agile?” For example, you say, “If you do not slow down when required you will end up with bad design and architectural rot.” I think this is true whether you’re running an ‘agile’ project or not.
Like Jack, I agree with the premise of the post, though. It’s easy in agile projects to forget to stick your head up and look around now and again — both to keep an eye on the releases and overall product backlog, but also on the system design and architecture.