Agile Requires Skilled Developers
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.
Slack Is Important
I'm a very strong advocate for slack. I believe introducing slack as a policy improves the overall quality produced during productive hours compared with the traditional approach of applying constant pressure. Just like pair programming, it is actually very difficult to get managers to understand the real benefits of having 'slack'.
For me, slack is just another way to improve the transparency of an agile project and is also the ideal vehicle for introducing diversity, continuous learning and continuous improvement. Given slack, developers will naturally use this to either improve their own networks, improve their understanding on a topic they found difficult or explore new technologies. Any of these will ultimately add significant value to your project.
I’m Agile, But!
Stop right there...
You're not agile...
There are no buts in agile...
If something is wrong, you change it, you don't say "but"...
If you truly can't change it, then you're truly not agile either.
To be agile doesn't mean you must follow any particular methodology, to be truly agile you must be actively seeking to constantly improve every aspect of what you do. If this involves trying out some lean principles to eliminate waste, or TDD to improve the quality of the tests, it doesn't matter.
I'm a strong believer that agile has now become synonymous with many of the methodologies, which is very sad since agile is so much more than a methodology, it's a culture...
So, the next time you hear yourself saying I'm agile, but... You've just identified the next problem to solve in your own methodology and your also just a little bit more agile than you already were...
Too Many Broths Spoil The Cook
I' ve got several things bubbling over at the moment and because I never bothered capturing them as stories and placing them in a backlog I'm really struggling to make headway with any of them. Some are personal experimentation, others are professional and finally there's a few projects which may end up as open source.
So what's stopping me making this backlog? It's the lack of a single coherent customer to do the prioritisation of course. I could certainly pull out all the things I want to do into a set of stories, but would it be right for me to also play the customer role? I certainly don't want to ask my work to do the prioritisation, since I know which side of the fence they'll lean on...
I think my personal challenge is quite similar to many projects I have witnessed where there has not been a single customer. It becomes extremely difficult to prioritise stories and deliver a single useful end to end feature and instead we deliver lots of little bits and pieces. Of course, switching contexts in itself is extremely expensive in terms of productivity, but unless there is a single customer, with clear goals and a solid backlog of well expressed stories then switching contexts is inevitable.
What do I plan to do? Well first and foremost I'm going to take the baby-step of at least creating my backlog of stories... By definition, these are my stories, so in reality I am the customer, I guess I'm just like all other customers, I'm not a very good one and I like to keep changing my mind - oh well...
Qualities of a Good Developer?
Just what exactly is it that distinguishes a good developer from an average developer? Certification in a particular language or technology demonstrates the ability to be "average", but certainly doesn't demonstrate good. I believe a good developer is someone who has an aptitude for developing, which is inherently extremely difficult to measure or quantify. However, there are possibly a few things that can help you identify your good developers:
- They are capable of using several languages to get things done
- They are pragmatic in their approach
- They understand the concepts as well as the solutions
- They can think at multiple levels of abstraction
- They can get things moving despite uncertainty
- They champion quality and continuous improvement
- They like to share their knowledge and expertise
Of course, these are very subjective measures and very hard to qualify or quantify. It can be very hard to demonstrate an ability to use several languages if the working environment dictates a single language. Red tape may prevent pragmatism. If the environment prevents these qualities being expressed then it is very likely the most important qualities of the best developers are being suppressed.
If you wish to get the best from your best developers, and achieve that 10 times productivity that is often quoted, you should look to make sure that you have provided them with an environment that allows them to demonstrate (through action) the above characteristics. If there is anyone you can think of right now with some or most of these characteristics, why not take the opportunity to ask them how you can help to allow them to improve.
Avoiding Inertia
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
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...
The Downfall of Agile Hitler
I don't normally spend any time watching youtube, but did stumble across this one which is well worth the effort... Very funny...
Information Overload
The internet has now pervaded my life to such an extent I'm going to soon be looking to get a direct connection to my brain. But before I do, I'm in desperate need for a way to organise the constant, chaotic stream of information that is radiating from it...
Here's my list of basic requirements.
I want to be able to
- view all messages in a single application, regardless of source (rss, google reader, twitter, etc).
- post messages to any of the applications I use (twitter, blog, facebook, etc)
- Should also be able to post to multiple applications at once
- search and filter the content
- filtered messages, should still be available for future search/display
- use multiple platforms (phone, web, laptop, desktop) with them all kept in sync
- specify multiple ways of notifying me if anything relevant appears
- particularly important for mobile platforms
- switch between different modes (professional, private, meeting)
But MOST IMPORTANTLY
I DO NOT WANT TO:
- create YABA (yet another b****y account) to use yet another free online tool
- wait for hours while it downloads everything before I can view a single message
If anyone knows of such a tool, I'll be extremely happy to hear about it...
God Mentality
My recipe for developing a God Mentality.
Ingredients:
Method:
- Prepare a clean team working area
- Gently introduce the agile coach to the team
- Gently stir until a process emerges
- Trust the coach
- Allow process to fester
- Praise the coach
- Serve with a slight pinch of sarcasm
Adopting agile is extremely difficult and coaching is a great way to being in the necessary skills and expertise to a team. However, coaches are not infallible and will inevitably leave their own stamp on your project. Leave a single coach on a team for long enough and they will become an almost god like figure and the team will depend more and more on their advice and wisdom (KB/C3). A good coach will be able to adapt the processes and methodologies to suit your environment, but a zealot will probably insist on adapting your environment to match the methodology. To produce a really good God Mentality it is imperative that they are unquestioned in their approach and instead followed blindly. This works particularly well with a team of inexperienced (or long serving corporate) developers.
Unfortunately, if you fail to produce the perfect God Mentality, you're probably doomed to a life of perfect agile. The moment some diversity is allowed to challenge the preaching from God #1 you are on your way to never exalting a single guru (or their processes) again...
Unfortunately, the quality of agile coaches varies remarkably and this recipe may not always produce the perfect God Mentality.