Why Bother with Automated Acceptance Tests
Who's this for?
I'm about to write a few articles covering some advanced acceptance testing techniques. I don't plan to get into the nitty gritty technical details and instead want to discuss the why's... For some great material around acceptance testing I highly recommend looking at the Concordion techniques page and can't speak highly enough of Gojko Adzic and recommend you look at his blog and in particular the comments to his posts.
The question I want to ask is slightly more philosophical. Why are we really writing automated acceptance tests and who are they really for?
If you have a customer on-site, who writes the stories and tests (acceptance criteria) in a non implementation specific way then stop reading right now and send me the link to your blog, otherwise...
In an acceptance test driven environment, the acceptance tests help ensure you have solved the problem and developer tests help ensure you are solving the problem the right way. To validate you are solving the right problem we need to express the tests in a way which doesn't tie you to a particular implementation so we probably want to drive this more from a user experience and in particular the functionality we expose to the user as well as what the user can expect when using that functionality. So we are writing acceptance tests that check that the functionality we are making available to our customers is working correctly, without worrying how we will provide that functionality, but does that mean we are expecting our customer to "accept" those acceptance tests?
In agile teams you probably have a product owner and in an ideal world we would want the product owner to "own" these acceptance tests. More often than not, the product owner will happily own the story but will delegate owning the specifics (which sadly often includes testing) to a business analyst. Our goal is to get the product owner to own these tests, but with a business analyst in the way we are probably already at the stage where any tests will be implementation specific, since the business analyst is probably doing exactly that, working out how to solve the problem... In fact, business analysts probably don't want to own the tests either which leaves the team...
Let's reflect for a moment... We want the customer or product owner to own acceptance tests, but instead it usually ends up being the team that owns them, so let's explore what typically happens... The team search the web for acceptance testing techniques, they come across BDD and see there are a wealth of tools out there supporting BDD. They pick up a tool (cucumber, jbehave, etc) and all tests are now captured and represented in Pseudo english in the hope that the product owner or business analyst can start creating these tests themselves. I've yet to meet a product owner or business analysts (or indeed a developer) who uses this style of language,
a product owner walks in to a bar and says to the barman
"Given I am thirsty
and I am standing at a bar
and there is a beer mat in front of me,
When I ask the bar man for a pint of his best bitter
Then the barman will pour a pint of his best bitter
and place it on the beer mat in front of me".
Just a little bit verbose (not to mention slightly implementation specific) for expressing ordering a pint of best bitter. So my point is BDD is a technique, it is invaluable for exploring the problem domain and capturing scenarios and examples to help understand a problem, however they are not a specification in and of themselves. Using a tool too early to automate these ties you into this form of unnatural expression and eliminates a choice of how to engage with the customer later.
As a team, using the technique in discussions but then using a tool or framework (e.g. xUnit) more suited to the real owner of the executable part (developers) means you can leave the choice of customer facing tool to a more appropriate moment when they actually do want to engage and also benefit from an environment and language the developers are most comfortable with... I've written previously that even working out what you plan to test or demonstrate before working out how to implement it can add immense value as a thought exercise.
Toxic Waste
There is also another scenario which is by and far the most dangerous... Having browsed the web, we want a cross functional team so we embed a tester into the team to perform this function. The tester works closely with the business analyst and creates/owns functional tests. Most testers are new to development and don't have the skills or experience of the developers to be writing code, and worse, we are trusting these inexperienced developers with writing the most important code in the system, the tests that validate that what we are doing is correct... Inevitably we will end up with an enormous suite of functional tests that are very "script" based, not easy to understand and which add little if any value to the day to day activities of the team.
So to recap, we want to write acceptance tests to validate we are building the right thing (and that once built (or is reimplemented) it continues to work), and we want the customer (or product owner) to "own" them. If any of these are not true in your organisation then seriously ask yourself why are you doing what you are doing and put the customer's hat on and ask would you (as a customer with limited technical knowledge) ever "accept" what is being done on your "behalf"...
Agile, a poem
Agile is a Journey
I thought I'd have a little blast at poetry for fun...
Agile is not a Gift I can Give,
Nor is it a Method I can Teach,
It is a Choice You must willingly Take,
And a Journey You are willing to Make.The road Never ends,
It Twists and it Turns,
But the Road is your Road,
And it's your Trail which Blazes.Don't be a Passenger,
Don't pay a Chauffeur,
Grab hold of the wheel,
And Pick your own Pace.Take those Detours,
Enjoy the Delights,
Splash in the Fountains,
Chase those Green Lights.
Updated – Agile Hitler – He’s Using Git
It's been a few years since Hitler found agile , so it's nice to see that Hitler is now enjoying git...
Dusting off Rework
My current contract ends in a few more days so I'm taking the opportunity to dust off my worn copy of Rework by 37 signals. I have to make a long overdue thanks to Craig Davidson, an outstanding agile developer I encountered in a previous engagement.
It's not a traditional agile book by any means, but the facts that are presented within the book resonate strongly with my agile values and I find it has helped me immensely to keep grounding myself between contracts. I am now constantly surprised just how many paper-cuts I have personally accepted at each engagement and am equally surprised at my own personal level of intolerance now. I'm actually thinking of requesting a discount from the authors since I now use this book as a gift I give almost routinely...
I challenge anyone not to find the book invaluable at challenging their own current view of the world.
So, once more, and I must apologise profusely for the tardiness, thank you so much Craig...
Concordion Plus
I've written in the past about Using English to write Acceptance Tests and the tool I choose/advocate is without doubt Concordion. Customers love seeing their stories come alive, but I've found developers can sometimes struggle to differentiate these from JUnit tests, particularly since JUnit is used to provide the execution mechanism.
I've also found that in many of the situations/organisations where I have introduced Concordion, a single story has required several tests and although the Concordion guide does present some excellent techniques to deal with this, teams new to writing acceptance tests will be uncomfortable capturing stories in this format and customers might not be happy that all their acceptance criteria are being met. I am therefore pleased to be releasing Concordion+ to the wild. At the moment it is a simple extension to Concordion which allows developers to create individual scenarios (or test cases) within a single story and also to ignore the scenarios they are actively working on. In addition, a new JUnit runner captures the state of each of these scenarios independently and reports them in the common IDEs while also allowing developers to use the JUnit @Before and @After annotations. This should simplify adoption by developers since they now have a JUnit lifecycle they understand.
I have to send a huge thank you to Nigel Charman for the concordion-extensions project which helped immensely with my development. And of course I can't dare not mention the excellent work by David Peterson on Concordion itself and particularly the facility to write extensions 
I hope you enjoy using it as much as I enjoyed creating it...
My Stories Are Bigger Than Your Story
Big Stories...
I've always found it a challenge when new teams are adopting scrum but have simply renamed their list of requirements as a product backlog. Scrum provides a nice facade which shows a steady progress of churning through these requirements, but it makes it extremely difficult to measure the tangible business value. This is particularly the case where we have a scrumbut model, especially when done doesn't include production/release.
The progression from a list of requirements to user stories with acceptance criteria is usually the first step I recommend, but this is fraught with danger. Requirements typically have inherent dependencies that don't translate well into stories and requirements are also usually solutions to problems rather than the problems themselves. It is only by uncovering the underlying problems that we can start forgetting about the "requirements" and start providing tangible business value by solving business problems.
The first stab at cutting user stories usually results in very large stories with very vague, subjective acceptance criteria, if indeed there are any acceptance criteria. As teams work on these large stories, the tasks they produce are also probably too big and vague and simply sit forever in the in progress column. This is usually due to blindly trusting and following the scrum process. At this stage I usually challenge teams to stop tracking tasks and instead focus on delivering the stories. This is extremely uncomfortable at first since teams will be struggling to deliver big stories. However, it only takes a sprint or two before the team start focussing on the stories and feel relieved that they don't get bogged down in 3 or 4 hour planning meetings to produce extremely detailed task breakdowns. The tasks are still extremely important to capture and update, but this is more of a real-time activity and no-one gets penalised for adding new tasks, or removing tasks that are not needed any more...
This hybrid scrum/lean model provides much greater opportunity to start introducing new technical practises (e.g. test first, automated acceptance testing, etc) since stories are broken down at the last responsible moment and some stories are natural candidates (comfortable technologies, clearly defined, etc) for trying new things.
The next challenge I usually face is getting stories to a size that is acceptable for the team and the PO. Applying the INVEST model works quite well here as does parking open questions through agreeing to raise future stories as required to limit the scope of the story in question to something that is estimatable. At this point stories can become quite small (which is great IMHO) with perhaps only 1 or 2 acceptance criteria. This for me is the sweet spot. It means the story will probably fit in the 2 hr to 2 day window, it is well understood, it is easy to estimate, it is easy to test and a host of other great things... However, it will also probably invalidate any existing (but also highly dubious) velocity metrics since the team will need to rebaseline...
Scrum
I've witnessed scrum applied extremely well, when supported with some additional technical practises and good story discovery/acceptance criteria/backlog management, but more often than not in my experience scrum is applied as the smoke and mirrors over the requirements list to demonstrate progress and it's only when you hit the last sprint you realise that you can't integrate/release/deliver despite having completed 90% of the requirements before entering the sprint with only a couple of requirements to go (e.g. Oracle Auditing and Secure Messaging)...
Digital Charity Shop
I bought my wife a sony ereader for her birthday in November and despite the fact she wasn't too happy it wasn't shiny or smelly she has since not put it down...
Her friend has a kindle and the other night my wife asked whether I would be able to transfer one of the books she just finished reading from her reader on to her friends kindle. I wasn't entirely sure I could, since my first thought was drm is probably going to prevent this. My second thought was why??? In the non digital world, once my wife has finished a book there would be nothing preventing her giving it to her friend but in the digital world this isn't easy, but why... Surely it should be possible for her to transfer her rights to someone else... Of course, someone will probably point out that this is already possible, but it was my next thought that really got me.
I wouldn't say we were minimalist, however we do tend to have a 'clean out' regularly which usually involves a trip to a local charity. We religiously donate the books we have read, the toys we have replaced and various other things. But now that my wife is using a reader there are no books to donate 
My solution, www.digitalcharityshop.org. It doesn't exist yet, but I've bought the domain and intend to find like minded individuals to help me set this up to receive unwanted digital content and resell them with all profits going to charity. If you'd like to help me on this journey I'll be extremely grateful
Of course, this won't just include ebooks, the solution is also begging to include any digital content - movies, mp3, software, apps... And just to be entirely clear, I'm not interested in £1 of each purchase goes to charity type deals, it all goes to charity...
So can you help?
Why you should never employ a techie to solve your problems!!!
I've just read a fantastic debate on the usability of Git (or rather the lack of) and it reminds me that most technical folks I encounter are too clever for their own good and will constantly introduce complexity for the sake of it (or to keep their souls clear from the devil - users).
The problem with this is that these wannabe rocket-scientists are fundamentally too stupid to appreciate that real people may not care about the elegant layers of abstraction or powerful combinations of wacky commands that can yield amazing powers. What they want is a simple solution to the problem they have expressed. The technical folks I admire are the technical folks who can create a simple, usable solution in a format that is acceptable and digestible by the end user.
As Einstein quoted "Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction.", which indicates the technical community appears to be filled with lots of intelligent fools...
And just to illustrate this further, I would include Spring in the mix here as an (actually it's a collection of) overly complex solution(s) to a fundamentally simple problem space, which given the size of the user community indicates their are a lot of intelligent sheep...
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!!!
Keeping It Simple – Regression vs Acceptance Testing
Another emergn coach asked me the other day how I distinguished between an acceptance test and regression tests. For me there is a very simple rule...
- 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...
Top Tips – User Centred Automated Acceptance Tests
Following on from my previous article, I thought I would share some top tips for creating automated acceptance tests for projects using user centred design. There is nothing inherent in user centred design which prevents an agile approach being adopted and indeed agile adds huge value to user centred design by reducing the feedback loops during the "design".
The outputs from the "design" part of user centred design is usually a set of wireframes, sometimes highly graphical to be used for marketing and soliciting customer feedback. Low fidelity wireframes, as produced by balsamiq are fantastic for exploring the solution space with minimal commitment and retain that back of a napkin look and feel which prevents misinterpretation by customers and business about how much work remains to be done making them real. At some point, developers will get their hands on these wireframes and be tasked with "making them real". Of course, if the developers can help create the wireframes, then so much better and what a great way to reduce that feedback loop
An example wireframe...
So, we're a delivery team and we have the wireframes available which we want to use to start carving this up into stories (with a customer ideally), executable tests and working code. Where to start...
First we want to express what we're seeing as stories so we can assign value to the stories and prioritise based on ROI. Depending on the technology choices, these wireframes also help to perform an initial design of the application in terms of data, services, components, etc.
The stories we write can be high level stories capturing the user experience as they navigate through the site, or they can be as low level as which fields are visible within a given area of the site.
My preferred approach is to write stories and tests at the high level and as we uncover the detail capture these as smaller stories and more detailed tests. This seems to fit naturally with user centred design and allows planning and release activities to focus on the high level stories around the user experience (which is probably why they chose to do user centred design in the first place) and allow the development and build activities to focus on delivering the smaller stories.
My top tips would be...
- Write your stories and tests based on what you see in the wireframes
- e.g. When a user (who is not logged in) visits the homepage they can see the "News" in the main area. Notice that the wireframe has a single article, but this could be many articles in the future. There is also no reason to assume this is the "Latest News", "Featured News", "Breaking News" or anything else.
- Be constantly aware of the context (explicit or not) within the wireframe when writing your test
- e.g. In the latest news section, we may see a "Read More" link and assume that we can simply fnid this "Read More" link on the page. Of course, in the future, there may be more than one news article (so we want to find the "Read More" link related to a particular article) and indeed there be more sections that contain "Read More" links such as user comments (so when we implement a test around the news, we want to ensure that we are finding the correct "Read More", which means we look for it in the news section and in relation to the article(s) of interest).
- Don't assume the wireframe is what the final implementation will be so think in abstract terms
- e.g. if there is a button in the wireframe, this may be a clickable image later, or a tab panel. So word your tests not on the button, but on the capability the button provides, so instead of "...and the user can click <Help>" we might have "..and the user is able to obtain <Help>".
- Envisage alternative implementations while writing the tests and validate your test would still be valid
- e.g. If I change this from being a form to being editable inline, does the test still work?
- Try to be discrete in your tests, it is better to have lots of small, simple tests than a small number of tests that test too many things.
- e.g.
- when... can they see today's weather
- when... can they see today's temperature
- when... can they see tomorrow's weather
- e.g.
- Use "Given, When, Then... and" to think about the scenarios you need, but try expressing them in natural english.
- e.g. When someone is viewing the school holidays calendar (Given) and they enter their postcode (When), the calendar should only display holidays for schools within the catchment radius (Then) and the user should be able to remove the filter (And).
- I like to think of "Thens" as being the assertions, and with UCD this is the stuff I want to see on the screen as a result of me doing something.
- The "Ands", which are an extension to Dan North's, I like to think of as the stuff I can now do in addition and in UCD this usually relates to new functionality which has been exposed or links that have appeared.
- Refer to the Concordion Techniques page for some great examples of how to write robust tests in natural language.
- Separate site aspects (navigation, login) from functional or contextual tests
- Refactor your tests as you go to evolve a testing DSL to simplify writing future tests
- Use personas (or metaphors) to encapsulate data
- Bring your personas to life
- Write them a CV, or post their key characteristics on the team wall.
- You can validate key aspects of your persona within your test (in the "Given" section) to provide better tests by clarifying what aspects of the persona you are actually testing
- e.g. "When Joe (who is on legal aid) views the list of local lawyers, the lawyers who provide legal aid are highlighted". Notice that highlighted could mean anything, from promoting them to the top, changing colour, or adding a nice icon...
- Bring your personas to life
- Don't create too many personas
- Personas are very powerful, but when abused become difficult to manage. To test functional aspects related to simple data variations use dynamic personas (e.g. when someone, who has not yet entered their postcode, accesses their profile...)
- Think like a customer
- Ask yourself how much money you would pay for a given feature or piece of functionality
I'm sure that I'll refine this example in the future and therefore watch this space...
“Natural Language” Automated Acceptance Testing
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"...
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.
Functional Debt
Thanks to Ward Cunningham, we now have a wonderful metaphor "Technical Debt" which explains the common problem of skipping a little bit of design or missing out that little bit of refactoring to meet a deadline. Whenever we cut corners there is a very good chance we are taking on more and more Technical Debt.
Money to Burn? Invest in Functional Debt
But is there a flip side to this? I think there is and the term I would use is Functional Debt. This is tied firmly in the YAGNI camp and relates to functionality that is developed without a need (or worse still a test). Applying too much design, or developing generic frameworks with no business reason to do so inevitably leads to a solution which is over-engineered. Of course, over-engineering as a term has been around for a long time, but I prefer the term Functional Debt, because this ties it back to money in a similar way to Technical Debt.
Debt is a term that evokes emotion and is easy for people to identify with and it is this capacity of the term to clarify the issue with a certain practise. Over-engineering as a term doesn't evoke the same response and certainly doesn't suggest a loss of money in the same way that Debt does.
There are of course direct, easily measurable costs involved in creating unused functionality and that is the development costs, however, there are many more subtle costs that are easy to overlook. There is the missed opportunity costs associated with not doing the right thing. There is the project overhead costs in maintaining code that is not used. There is the project overhead costs in increased complexity and time for the standard day to day activities of testing and refactoring. There is the increased maintenance costs since it is now harder to understand the code for support personnel...
One of the biggest causes for Functional Debt I have seen is a lack of customer (business) involvement or direction. Left to their own devices, IS departments naturally build overly- complex solutions to simple problems. Without a business value attached to a piece of functionality (actually to a problem that is solved by a piece of functionality) it is only too easy for the IS department to burn money like there's no tomorrow.
Vision >= Solution >= Problem
I'll admit it, I'm not 100% agile since I tend to like solutions. I would prefer a problem to solve, but if a problem is intangible I often find a solution is a great way to explore the potential and help express the underlying problem.
It is worth noting that innovation and invention are solutions and not problems. When you apply for a patent, you don't patent the problem, you patent the solution, why? If there are multiple solutions to any given problem then wouldn't we want to patent the problem?
I also find that quite often the solutions I am exploring are the result of a problem that I have assumed was well known and in actuality is not; it is in these moments that using the solution to derive the lowest common denominator of a problem stated as a user story can ensure that everyone is speaking the same language.
But given a solution, do we always need to know the problem? My pragmatism (and a few lean principles, i.e. waste) would state that if the solution brings value then run with it, if not ditch it. If on the other hand the solution seems too constrained or lacking in features/functionality, then why not exploit the solution as the basis for a vision? Indeed many visions are just that, solutions to problems, expressed in a language alien to most developers.
So given a vision expressed in an abstract form vs a vision that is pinned against an actual solution which is easier to understand and less likely to be misinterpreted? I know which I'd prefer...
Do solutions have value, obviously; must we always mine problems, hmmm...
Ten Commandments of Agile
I've posted a few entries now about my unease with the fuzziness surrounding Agile and how I feel it needs some clarity so I thought I'd have a quick stab at it.
The following commandments would be my first stab at such a list which would apply to any person who is part of or interacts with an Agile team.
- Thou shalt not negotiate quality
- Thou shalt not prophesize without proof
- Thou shalt not falsify the facts
- Thou shalt not force thy wishes on others
- Thou shalt not discourage those around you
- Thou shalt not disparage the actions of others
- Thou shalt not work without committment
- Thou shalt not focus on more than a singular item
- Thou shalt not demonstrate incomplete work
- Thou shalt not act in isolation
Of course, this is just a bit of fun on my part, but I fail to see why there can't be a set of golden rules of Agile? This is also a very quick list, so who knows, I may revisit this at some time to refine it...
Also, please note, I'm not being remotely fuzzy about this... I'm not saying
"I value not negotiating quality over allowing any old crap in the code..."
Could Agile Have Evolved?
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.
The Real Value of Test First is the Thought Process
TDD found the simple solution
Test Driven is a loaded term and means different things to different people. I much prefer the term Test First which clearly states that the test comes before the implementation. However, for me, the value is not necessarily in creating an executable test, but in the thought processes that Test First brings out.
One of my colleagues at emergn is constantly reminding me that when presented with a solution you need to ask yourself what is the problem. This is what lead me to question TDD and it's variants. If you search the web for Test Driven Development, you'll uncover a wealth of information from many of the authors in my BlogRoll, as well as many variants on a theme. I think the wikipedia entry is a particularly good summary of Test Driven as it is currently understood by the community but for the real meat and bones you need to look at the articles from the thought leaders behind the practises.
However, when I look at this wealth of information, I'm now faced with the question... OK, these are all solutions, but what is the fundamental problem they are solving? Is it
- Code quality/design is poor
- Code is overly complex/difficult to test
- Unused functionality within the code
- Too many bugs
It is only when we understand the underlying problem fully that we can then evaluate the applicability/suitability of a particular approach. Indeed, it is this lack of a clearly defined problem which makes it impossible to determine which approach is best, since we can't define any tests up front... This is actually a little bit of a paradox, but highlights for me one of the most important points about TDD. TDD is a solution to too many problems and in certain cases is not a very good solution.
Testing should be about proving functionality, but unfortunately we too often see TDD trying to address non testing issues like design and code quality. Of course, code needs to be testable, but it is not the responsibility of the Testing to enforce this, it is the responsibility of the design, but this is (unfortunately IMHO) the missing piece in most methodologies... Indeed, the approach of writing the "Simplest Possible Thing" to pass a test is possibly my biggest bug-bear with TDD. This approach often means you can pass tests with no functionality other than hard coded return values, now that has to be the biggest process smell ever.
I'm going to stop using TDD, or Test Driven now and use instead the term I prefer which is Test First. For me, this means that before I do anything, I will determine ahead of time how I would test it. The immediate benefit (a.k.a value) I get from determining how to test something is I'm also starting to think about (dare I suggest design) things like apis/design/interaction/responsibilities. This is not the same as BDUF (big design up front), instead it is just enough thought at just the right moment to (hopefully) prevent a disaster. I can then apply some cost/benefit analysis with a pinch of risk analysis to assign a value to actually writing all the tests that TDD would have forced you to write, or just a small percentage to cover the important or more complex functionality.
Of course, in many cases I will actually create executable tests for many of those uncovered during this thought exercise, but will I go through the whole Red/Green/Refactor cycle, possibly not. For me the Red/Green/Refactor is like micro context switching. I prefer a slightly longer period of focus and therefore I may write quite a few tests at the same time before applying that context switch to go into coding mode. This of course is my personal preference and undoubtedly would be scorned upon by the dogmatic TDD zealots, but if this is what makes me more productive, and without a baseline problem statement I challenge them to prove that this is not the best way to do your testing.
Test First allows me to
- Understand the problem I'm trying to solve
- Think about how I will solve it (just enough design)
- Uncover any unknowns or risks hidden in the initial problem statement
- Produce high quality code which has just enough tests
Many of the Test Driven approaches do indeed address many of the initial problems stated earlier, but are they the only solution to these problems? Indeed, are these problems actually just symptoms of even deeper problems? If the problem is simply that your code is very tightly coupled and difficult to test then the best ROI will probably come not from TDD but from up-skilling your development team on fundamental design principles (unskilled developers was the real problem in the first place and TDD can't solve that).
Resources:
- Wikipedia entry for Test Driven Development: http://en.wikipedia.org/wiki/Test-driven_development
- Introducing BDD by Dan North: http://dannorth.net/introducing-bdd (highly recommended reading)
- C2 wiki entry for Test Driven: http://c2.com/cgi/wiki?TestDriven
Big Red Button
Here's my little user story:
As a blogger,
I want to use Threely as my url shortener.
So that I get more letters on Twitter.
Pretty simple story, and also very simple to implement, but impossible to test? I can certainly test the API to twitter, but given I use a wordpress plugin (developed by someone else) to do the auto-posting is it worth the effort for the addition of 6 lines of code?
For me, the pragmatic solution is to take the risk based approach. I'm going live with Threely (http://3.ly) (again, fixed a small typo), but have an escape plan (extremely important when there are known risks) which is the ability to revert if anything untowards happens and revisit my approach.
So, here goes, pressing the big red button 
Delivering Early
The MMF wasn't quite complete.
I've seen plenty of fancy graphs demonstrating how agile provides faster ROI through early delivery and while this can certainly be true in some cases, it doesn't necessarily hold true for all cases.
Just because a feature is done, doesn't mean you could, or even should deliver it... The Minimal Marketable Feature set (MMF) is very important for determining when to go live. When you take the MMF into account, then agile doesn't deliver any value until the MMF is complete and this certainly won't be within the first iteration.
Of course, once the MMF is done, agile will win hands down delivering new functionality, enhancements and bug fixes (what bugs?)...
So what went wrong in the picture? What was the MMF
- Wheels/Chassis
- Engine/Gearbox
- Steering
- A Seat
And guess what, they've ticked all the boxes, I'm so excited I'm going to run off now to my local dealership and snap one up...
acceptance tests agile analysis baby steps benefits charity coaching commandments communication culture emotions essays feedback from the trenches fun fuzzy google human nature ideas information radiator just enough legacy mentor methodology mmf pair programming pragmatism psychology puzzles quality rants refactoring risk satire simplicity stand ups tdd team test driven test first user stories vision wave weather poker youtube
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
My Links
Recent Posts
- Why Bother with Automated Acceptance Tests
- Agile, a poem
- Updated – Agile Hitler – He’s Using Git
- Dusting off Rework
- Concordion Plus
- My Stories Are Bigger Than Your Story
- Digital Charity Shop
- Why you should never employ a techie to solve your problems!!!
- Enterprise Agile – Evolutionary Standards
- Keeping It Simple – Regression vs Acceptance Testing
Blogroll
- Alistair Cockburn
- Andy Hunt
- Ben Hoskins
- Dan North
- Dave Thomas
- David Peterson
- Gojko Adzic
- James Shore
- Jim Highsmith
- Joel On Software
- Martin Fowler
- Michael Feathers
- Nigel Charman
- Object Mentor
- Portia Tung
- Scott Ambler
- Stephen Walther
- Ward Cunningham
Archives
- January 2012
- August 2011
- April 2011
- March 2011
- February 2011
- September 2010
- April 2010
- March 2010
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
Tag Cloud
Rate This
