Enterprise Agile – Evolutionary Standards
Low Tech Evolutionary Standards
At the risk of being lambasted by the agile community I will use the words enterprise and agile in the same sentence 😉
This article largely follows on from some previous entries and in particular my entry on user centred test driven development.
It is often a complaint that large organisations trundle along painfully and slowly. Work can't start without following some process or other until you have sign-off. Part of this sign-off will probably involve agreement to follow certain standards and guidelines, but if these standards don't yet exist how can we start???
To challenge this and present an alternative approach, why not make the "standards" part of the delivery itself. Make it clear up front that rather than wait for the standards to be released (which would be the normal mode of attack in large organisations) you will actively work with whichever standard's body exists in the organisation to evolve just enough standards to support the actual work you are doing as you work through the backlog.
To make this work, COURAGE is imperative... Someone has to have the courage to put a stake in the ground early, recognising there is a small risk this may change. Developers should embed the standards into their automated testing as early as possible, this means that when and if a standard does change, there are tests in place which will assist developers in ensuring that all work to date is easily brought up to date...
The results of this is a design language that everyone can understand, when someone says they are writing a test which is looking for the jobs tag in the currently featured news article, everyone should know what that refers to in the wireframes, and also know how this will be identified and marked up in the implementation. This allows tests to be written before any code and even for the final "Look And Feel" to progress alongside development.
Of course, you're always free to continue in the traditional model and wait for three months until the standards body within the organisation produces a 300 page guidelines document before even starting that killer new feature that will storm the market... Or make totally random guesses, which are much more likely to be wrong, and be safe in the knowledge you have the traditional saviour of projects - Hope and Prayer!!!
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.
Should I Bother?
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.