The Agile Jigsaw Puzzle

I was specifically trying to capture the idea that something beautiful can be produced a small piece at a time (and nothing more)...

I had great fun creating it and I hope you like it...

          

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!!!

          

• If I write the test before I write any code, it's an acceptance test.
• If I write the test after I've written the code, it's a regression test.
• If I write code to make an acceptance test pass, it is now a regression test.

Keeping it as simple as this keeps you out of trouble, I've seen so many people try to retro-fit acceptance tests after they've written code only to write a test which is based on what they've written rather than what they should have written.  It's a subtle but important point that writing a test for stuff you've written (which might be wrong since you haven't got an acceptance test) means you are potentially writing a test that the system always does the wrong thing...

          

DNA

I've been researching material to support an article on my company blog entitled "Agile Dictators" and it left me thinking about how Agile started in the first place.

The more I reflect on this, the more I am left feeling that Agile is actually a mutation in software development and this is one of the major reasons why Agile is so difficult to master. I'm wondering whether agile would ever naturally evolve in a small team left to their own devices and I simply can't envisage it. Of course, this will now remain an academic hypothesis since Agile has now stamped it's influence indelibly on the DNA of software development.

Software development as a craft suffers from unnecessary complexity and I fear that Agile, which initially thrived in simplifying (or removing) this complexity, is now becoming itself encompassed in unnecessary complexity.  Despite agreeing with much of the sentiment of the software craftmanship manifesto I just can't bring myself to sign up to it yet.  I struggle to see the benefit of more fuzzy aspirational statements and would prefer to see a clarity of vision and roadmap to achieving it.

Fundamentally Agile is fantastic, but sadly the passionate discussions, raging debates and conflicting methodologies don't clarify anything. If Agile doesn't clearly define itself soon I fear yet another mutation may take centre stage and Agile will end up being just a blip (albeit a very significant blip, where we gained sight) in the evolution of software development.

          

I've been working on a few internal projects for my company of late and this has involved working in a distributed fashion (yes, pairing by phone), and during some of these sessions I can immediately envisage the benefits of using Wave.

Surely there is at least one complete, tested feature they can roll out to production?  My concern is there are still some fundamental challenges facing the team, and I would not be surprised to find it being concurrency issues, so as the potential end-user of this technology I'm going to make it clear, I don't particularly care about have multiple users editing the same document in real-time with transparent, asynchronous updating...  Let me edit, commit, refresh, etc as a simple starting point...  But whatever you do, let me do something before I find a simple alternative...

To find out more about wave, visit the wave site http://wave.google.com/, and especially watch the google I/O presentation...

          

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...

          

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...

          

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...

          

I'm left wondering whether it is something inherent in human nature that leads us to strive complexity or whether it is actually the way we are educated.  Certainly, with regards to software engineering the majority of the agile techniques and practises appear to contradict what is being taught in universities.  The comment I hear most often when coaching Test First Development is that the difficulty is in thinking backwards, suggesting that the practise itself isn't difficult per se, but it's the way we think that needs rewired.

Of course, not knowing what the problem is makes it difficult to formulate a solution - now there''s a real challenge for agile