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!!!
Limitations of “Grow Your Own” Agile
"Grow Your Own"
Over the course of my career I have worked at several organisations and have always tried to improve the internal processes using agile techniques and principles. Despite being a valued employee (I hope) at each of the companies I have worked at, the amount of success I achieved in agile adoption always reached some internal limits. It was only when I joined emergn that I was able to rationalise this.
It is inevitable that as an employee of a company you will have something to do as part of your day job. This will always be your primary concern and there will inevitably be certain processes you must follow in order to perform your function. Changing this process from the inside will usually involve challenging the process (rocking the boat) using rational arguments and demonstrable alternatives. This is certainly achievable, but does take rather a long time to introduce even simple improvements. Organistations, particularly large organisations are not content with local optimisation and nearly always want to ensure that any benefits from a single improvement become the standard for the organisation as a whole. This usually means that the number of interested parties is artificially (and politically) quite significant and therefore the amount of resistance to change is high.
As an external coach the mandate is entirely different.
First and foremost, your primary function is to instigate change.
This will mean the amount of resistance is significantly less.
Secondly, you will not be tied to existing processes.
This means you can implement changes and improvements much faster.
Thirdly, as an outsider you are automatically assumed to be an expert.
This will mean that you will not need to engage in the same level of rational argument or discussion as an internal employee.
Lastly, as an outsider you bring some diversity and objectivity to the environment.
You will not be unconciously constrained by any existing processes or internal preconceptions about the art of the possible.
As an external coach now, I am actually extremely surprised with just how much compromise I had been willing to unconciously accept as an employee. Every small improvement I would have liked to make became a battle and unfortunately I lost many of these battles not through a lack of rational argument but through a lack of energy or time to continue to fight. When push came to shove I had to get on with my day job and ensure I lived to fight another day. Reflecting now, I'm not surprised that the more successful some of the improvements were the bigger the political entourage became and the more difficult it became to make the next improvement. Battles had to be chosen carefully not necessarily for the potential benefit but often based on the people who had expressed an interest.
I'm aware (and quite proud) of the changes I've made in each of the organisations that I've worked at but am left reflecting whether the effort was worth it. I think the barriers to continual improvement are probably a major factor when I decided whether I wished to remain at a given company and I can now see that effecting change from the inside is simply not effective. It will take at least twice as long to be at most half as effective as an external coach.
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...
My Agile Awakening
I've considered myself to be an agile developer (albeit of the pragmatic/lazy style) since the very early days of XP and through the course of my career have had the opportunity to experiment with most of the practises and methodologies in various 'flavours', but it wasn't until I joined exoftware at the start of this year that I truly appreciated what agile truly means.
"Agile" as a term has been niggling at me for years, because it has no clear defining definition, leading to abuse where everyone can, and often does, claim to be "Agile". Similarly, methodologies are extremely quick to jump on the bandwagon and claim to be agile (this is a topic for a future rant).
It is even more frustrating when there are so many purists out there advocating methodologies under the banner of agile. I'm sorry, but this just doesn't cut the mustard, if you're doing pure XP, you're an XP shop, but that doesn't necessarily follow that you're agile. Yes, the technical practise may be extremely good, but that doesn't mean the process is...
In just a few months at exoftware I have been fortunate enough to witness how a truly agile team doesn't follow any particular methodology, but continually improves their own processes, borrowing practises and techniques from any methodology. This sits extremely comfortably with me and confirms my beliefs of what agile is (mainly gleaned from Alistair Cockburn). But the surprise wasn't that agile should be pragmatic in it's application, but that in order to improve your agile process the best techniques and practises are themselves agile.
As an example of true agile, is there any real/substantial difference between an iteration, timebox or a sprint. I'm going to be happy to call this whatever the customer wants provided we can both agree a clear definition of what it means. And rather than get into the whole what does done mean, lets choose a term that means something in the customers context. Purists will have you release to production at the end of every sprint, but this will simply never fly for many large organisations (would you really want your online banking application being updated every 2 weeks with new features that had not been rigorously tested). Similarly, will I get bogged down in ceremony about when to hold a retrospective, of course not, I'll use them whenever I feel there is an opportunity to learn or adapt. I'll apply them not only to the deliverables, but also to the process being used to deliver.
The elitism inherent with many of the methodologies (and lets not forget the software craftmanship alliance) doesn't help with agile adoption, it just makes everyone else feel inferior... Wouldn't it be great if the team that brought us the manifesto got back around the table and gave us something SMARTER (specific, measurable, acceptable, realistic, timeboxed, energising, rewarding) rather than a few open-ended, fluffy statements so clearly open to abuse...