Agile Insider » benefits

Agile Requires Skilled Developers

mark — Fri, 29 May 2009 20:07:06 +0000

In a recent tweet from @EstherDerby, she states

Some ppl complain agile only works w/ highly skilled developers. Never been clear 2 me that ANY dev. method works w/o highly skilled devs.

I think the subtle distinction is that agile REQUIRES skilled developers to be successful, whereas some of the "heavier" methodologies would be better with skilled developers but don't actually require them. I also think that when we look at many of the agile successes, it would be interesting to determine whether there was any correlation between the level of skill of the developers compared to the level of skill on the non-successful and/or non-agile projects.

And taking this just a little bit further... Would a small group of skilled developers be successful regardless of the methodology? Truly skilled developers tend to be very pragmatic and will always find ways to simplify the complexity around them, so I'm sure that if you took 8 highly skilled, highly successful agile developers and stuck them on a waterfall project they would deliver a successful result, at least in terms of the customer...

What's also quite interesting about this dynamic is that once a developer "sees the light" and becomes "agile" they can't imagine going back to waterfall, despite the fact they can add immense value by being part of a waterfall project and improving the processes. There is something very selfish about this which has not yet been picked up in the mainstream... This is also possibly one of the reasons why agile suffers an identity crisis, often being regarded as a cult.

And no, I'm not advocating waterfall, I'm just wondering whether skilled developers have more impact on success compared to the methodology.

Avoiding Inertia

mark — Wed, 27 May 2009 11:48:52 +0000

Michael Hill has produced a lovely essay about how TDD and Pair Programming ensure that the internal quality of your code doesn't cost you in future productivity. It is often difficult to grasp the benefits of TDD and Pair Programming due to the inevitable short term perceived hit in productivity. It is extremely important to recognise that the short term hit is however producing the desired side effect of highly maintainable code as a natural byproduct of producing high quality, well tested, simple code.

http://anarchycreek.com/2009/05/26/how-tdd-and-pairing-increase-production/

More Reasons to Pair

mark — Wed, 27 May 2009 11:34:04 +0000

Pairing is perhaps the hardest sell of the agile practises, so it is extremely refreshing to see yet more compelling evidence, courtesy of Mark Needham, of how pairing is extremely effective, in this case in the context of a large-scale refactoring (although I wonder just how the business assigned value to this activity).

http://www.markhneedham.com/blog/2009/05/26/pair-programming-refactoring/

I would concur that refactoring is much more effective while pairing and it is often while refactoring that patterns emerge which makes up for the lack of upfront design, so having more than one brain looking for patterns will ultimately lead to better code...

Should I Bother?

mark — Fri, 22 May 2009 07:53:03 +0000

You've never done "agile" before and you work on a legacy system which is extremely large, complex, fragile and bug-ridden. I'm guessing quite a few developers will be able to identify with this scenario. Does this mean "agile" is a no-go? On the contrary, applying "agile" techniques will probably make it easier to fix those bugs, faster and in the process improve the code just a little bit.

Here are my tips (prerequisites) before attempting "agile" within a legacy project:

Remove blockers
- Legacy builds tend to be painfully long - setup an environment that allows you to build and test the changes you will make quickly.
Protect yourself
- The changes you'll want to make are probably buried extremely deep within existing methods - use refactoring to pull out the code you want to change into a new method/class.
- Write tests that capture the existing functionality of the code you just extracted.

If it is too difficult to perform any of the above steps then don't bother with "agile" just yet (although by all means apply pragmatism), choose your "agile" battles carefully and you'll live to fight another day.