Shine has posted a new article which highlights the great work we have done in the Continuous Delivery domain.
Some people love it, others hate it – many people just don’t get it. So what is Test Driven Development ?
Jason Gorman has got a great analogy that helps to make it a bit more real – Test Driven Kitchen Design.
He didn’t invent the phrase “TDD is specification by example”, but it sums things up well.
So what’s in a name … ? Does it matter what you call your chunks of work ?
In many ways it doesn’t – different people use the terms inter-changeably. Sprint is specifically a Scrum term, XP tends to use Iteration, each different Agile approach has different ways of defining and using the terms. However the common ground is that they are regular, repeated timeboxes used to manage the work to be done so that there are regular checkpoints and feedback as part of the project process.
However there are some important differences between the processes of iterating versus incrementing.
Jeff Paton has posted a nice summary of the difference, along with some pictures that help to make it clear:
Iterating: Starting with an idea of what is wanted and refining that idea to get the desired result
Incrementing: Starting with a much more definite understanding and building piece by piece
Both still have the benefit of regular feedback and both can still deliver usable software at the end of the timebox. Incrementing is probably more useful when requirements are more stable or better understood, whilst iterating allows a more agile response to changing or unclear requirements. There’s no reason why a project can’t use both, at different times and for different features – in fact most projects probably should.
So – whatever you call your timebox periods, make sure you understand whether you want to iterate or increment.
One of the challenges working in a consultancy on client site, is adapting modern ideas and techniques onto existing legacy systems. The temptation can be to sweep away the old and replace with the new, but most times this is not possible (or even desirable as it introduces a whole new element of risk and cost). In the following article, I detail our successful attempt to bring “continuous integration” via Cruise Control into an existing Cobol system. Article :
Cruise Control & Cobol
If you think you are doing Scrum, how do you know ?
There are lots of good books around, but – whilst Scrum is deliberately quite simple – it can sometimes be easy to lose sight of the principles. Over on the Agile and Business blog Joe Little has posted the test used by Nokia to determine whether a team is using Scrum or not.
I’m happy to say that some of the recent work I have been involved in does quite well on the test, other work not so much …
One of the common criticisms levelled at Agile development – particularly by those who haven’t experience it for themselves – is that it is little better than hacking. In particular, that the reduced focus on documentation is evidence that the processes aren’t managed or controlled.
So, for a corporation that has invested significant time and money in process improvement and has reached CMMI level 3 or above surely Agile development is not an option ?
Not according to Mark Paulk who looked at Extreme Programming in the context of CMM(I):
“XP has disciplined processes, and the XP process itself is clearly well defined. We can thus consider CMM and XP complementary.”
So who is Mark Paulk ? He worked at the Software Engineering Institute as leader of development of the CMM for software.
Well, this week I’ve been able to introduce another developer to the Eclipse Web Tools Platform project and it’s been satisfying to see the look of joy on his face as he discover its hidden gems. As well as the standard stuff like HTML syntax highlighting, error highlighting and formatting, there’s also the more powerful stuff like completion on any tag library you want. Sure you can get this sort of thing with MyEclipse, but the WTP is free.
The only catch with this project is that it’s a big one with a couple of dependencies – which makes it much, much easier to install if you just use the Eclipse Update Manager and get it to automatically load dependent frameworks. I’m surprised at the number of developers who still install Eclipse plugins and features using the old-school technique of downloading a zip file and unpacking it into their plugins folder. You can often even upgrade all of Eclipse using the Update Manager!
However, we haven’t been able to use the Update Manager this week as we’ve been working behind a corporate firewall that blocks it for some reason – even after we configure the HTTP proxy access. Initially we resorted to the old-school approach (with all of its consequent difficulties) but then remembered that you can get distributions of Eclipse that are prepackaged with WTP. After that there was no looking back.
Mark raised some very good points in his comment against my recent post on welcoming change in projects:
“One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements.”
So what to do ? Does this mean that an Agile approach can’t be used ?
Much of what makes up Agile development is simply sound development practices, but what specifically could we take from the Agile philosophy for use in a fixed price contract ?
Let’s look at a typical situation we encounter – responding to an RFP or other tender. The client has provided some overview of the goals, objectives and requirements, a target completion date and wants a fixed price quote.
1) Respond to the RFP in the best way that you can
You need to make (and document) assumptions, try and fill in the gaps, use your experience – anything you can do to improve your information. And you need to estimate the work. There are no silver bullets here, with Agile or anything else, you just have to do the best that you can. However, if you’re used to working Agile you’ll be used to identifying requirements and putting together good estimates fairly quickly – treat is just like a normal planning session (someone will have to pretend to be the customer !).
2) Plan to deliver business benefit early
This is core to an Agile approach in any case – “early and continuous delivery of valuable software” – but it also means that if something surfaces during the project that significantly affects your original estimates you’re in a better bargaining position. A client is much less likely to be concerned about a suggestion to drop some of the minor functionality if they can see a working solution that already implements their most important requirements.
3) Promote your Agile approach as a benefit as part of the proposal (and put your money where your mouth is)
The use of Agile processes is now widespread, almost mainstream, so is something that can add value to your proposal. Even if your client isn’t really aware of what Agile processes are all about tell them what you are offering – choice. The ability for them – the client – to have control over the process and end it at the end of the next iteration if they’re not happy. Or maybe even if they are – because they might by that stage have what they need to achieve the business benefits they are after.
4) Do the job better
In the worst case – even if the client is not interested in Agile processes or iterative development – you can still benefit from those processes as an external vendor / supplier. If your development processes are more efficient and more effective then you are going to be more competitive at proposal time, as well as more likely to deliver on time, on budget and to meet (or exceed) your client’s expectations.
As Mark also points out in his comment – things work better when you have “trusted partnering relationships where both parties are working for mutual benefit”. Or – as the Agile Manifesto puts it -“Customer collaboration over contract negotiation”.
The more you can demonstrate delivery of business value, the more you can develop trust. On the other hand, if you need to rely on the wording of a contract to protect your position then the project is already in trouble.
But surely that leads to chaos – how can we possibly build something if we’ve got a moving target ? It must make more sense to gather all the requirements from all the stakeholders, lock them down and then make sure we deliver …
Let’s explore that thought for a moment. It is conventional wisdom that defects are more expensive to fix the later thay are discovered. Requirements are gathered at the start so changing them down stream will be expensive – the further down stream the more expensive.
But what are the costs of not allowing requirements to change ? Even if the solution is delivered on time, on budget and meeting all requirements, research has shown that more than 60% of the functionality is rarely if ever used and only about 20% is used often. Why is this …
But what if there was a way to change things ? What if a change to requirements could be made without the expense, or maybe even to save costs or increase benefits ?
The full principle from the manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Change happens. Projects are about making change. We can treat changes within our projects as an impediment that needs to be constrained or removed, or we can harness it.
The Agile Manifesto was released in 2001 with some theatre and not a little revolutionary symbolism. Whilst it was seen by many as being a radical departure from accepted software development “best practise” I remember being somewhat bemused at what all the fuss was about. Rather than being a radical departure, it seemed to describe a lot of what we were already doing.
So were we doing Scrum back in 2001 ? Or XP ? No. Although these methods (and others) had been developing for some years before the release of the manifesto, at that time they didn’t have widespread adoption or even awareness. But – at a time when projects around us were being cancelled, in some cases after years with no progress – we were writing good code, delivering quality systems that the users liked and getting things done. So were we “doing Agile” ?
Here are some of the principles we followed back then:
These principles evolved from experience – seeing what worked and what didn’t – and from an innate sense of what is ‘right’ both ethically and in terms of effectiveness. A lot of these could almost be taken directly from the Agile Manifesto and supporting principles which perhaps explains my initial response. So in that sense we were certainly in the spirit of Agile.
But there were a few significant concepts introduced with the Agile Manifesto that were not front of mind for us back then. One of these was “deliver early, deliver often” – an idea so mainstream now that it seems hard to conceive of a time when it wasn’t practised. Yet this more than anything has helped demolish the great dividing wall between technology and business, allowing people from the non-technology world to step into the development process and share control.
Fast Forward to today and what has changed at Shine ?
In some ways nothing at all – we still subscribe to the basic principles we were following in 2001 simply because they’re right and they work. We are still writing good code, delivering quality systems that the users like and getting things done. We’ve chosen not to standardise on a specific Agile methodology yet, but we have heavily borrowed from many and used ideas as appropriate to specific projects. We have used time boxed iterations, test driven development and continuous integration (amongst others) as techniques to help, particularly in order to “deliver early, deliver often”.
It is worth remembering that Agile software development is not XP or Scrum or AUP or any of the other many and varied methodologies. These are expressions and extensions of the underlying principles laid out in the Agile Manifesto. So perhaps Agile software development is more evolution than revolution, defined by a group of like minded people who stood up, looked around and recognised that some of the things people were doing actually made things better.
Or perhaps it is something more.
One of the other new ideas was to “Welcome changing requirements, even late in development”. This puts control of scope squarely back with the business – where it should be – but is arguably the greatest challenge to traditional software development approaches.
But that’s another story in itself so it will have to wait until next time.