Do you speak FIT?

I read with extreme interest James Shore's blog about FIT but was dismayed that he devalues automated acceptance testing.  To claim that FIT is a "natural language" is wrong, it is a developer language and this is possibly why customers don't get involved.  Concordion on the other hand is natural language and I think plays much better in this arena.  In addition it is much more developer friendly. 

I've written previously that for me the value of test first is the thought processes surrounding it, however,  where applicable converting these into automated tests, and in particular automated acceptance tests is a huge win.  I would love having a customer "own" the tests, but when this isn't possible (almost always) I will try to put my "customer" hat on and think like the customer and express what I'm about to do in their language (which will be English, not FITnese, or selenese, or rspec).  If the customer is happy with my specification, I can then use this directly as my test.

So for me, the lack of customer isn't the problem, but I agree with James on one point, there is a problem...

It's the people...  The majority of developers I've encountered can't think like the "Customer" and instead thrive on complexity.  They can't express the problem or solution correctly and write tests that become implementation specific.  This means they have written a test for a specific solution, where actually there could be a multitude of solutions, even in the same technology.  When they then 'implement' this solution and the customer doesn't like it, the test can't be reused and needs to be 'reworked' (I'm avoiding refactored, since the test was actually wrong, and therefore it should be fixed, not refactored).  This is the problem, the test may be rewritten many times at which point the customer will be thinking, this is now the n'th time I've asked for this exact same feature and I've seen five different versions of a test for the same thing, none of which are producing what I'm asking for.  If I was that customer would I want to own these "tests" which seem to be so difficult to change and can produce such a burden to tweak the implementation.

So for me, if I don't know what I'm doing, I won't do it and will ask for help from someone who does know what they're doing.  I would encourage all developers to have the courage to admit when they are out of their depth with a practise and seek advice rather than struggle on developing the wrong thing which ultimately ends up having little value. 

I forever find myself coming back to the five values, and when I measure FIT against simplicity, communication and feedback it would come in at "Good, could do better"...

          

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.

          

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.

          

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

          

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

          

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