Yesterday I presented a talk entitled Introduction to Continuous Delivery at AgileDC. The audience was great and the room packed which is always a recipe for success. I really enjoyed talking about Continuous Delivery and there were some really interesting questions.
As promised I have uploaded the slides from the presentation to iWork.
As I mentioned yesterday Jez Humble was kind enough to donate his slides from which I borrowed shamelessly.
I came across this post by Michael Norton and thought I would reference it here: Stabilising Velocity Michael makes some keen observations on both causes and effects of unstable velocity.
Predictable velocity is a key agile planning metric. There is an implicit assumption in agile planning that this iterations velocity will be similar to the last iteration. Without this predicability it is very difficult, if not impossible, to provide and sort of forecast.
Trying to identify the root causes of unstable velocity is difficult. Quite often there are layer upon layer of symptoms masking or hiding the real cause. I delving into root causes I find these techniques useful
Faced with the question ‘What do you do?’ from family and friends is more challenging than it should be. Most other professions have been around longer than a generation but writing software applications is different. Especially for my parents and so this is for the vast majority of people who don’t do what I do but would like some sort of idea of what I do.
But first a disclaimer – I don’t really know that much about golf. I have played a few rounds in the dim and distant past and watched a bit on the TV. My apologies in advance to golfers everywhere for the mistakes I am about to make.
Every project needs to start somewhere. If a round of golf were a project then it would start at the first Tee. Arriving with golf bag with an arsenal of clubs ready to begin. Even before arriving at the first tee there has been a bit of planning, appropriate clothing for the weather, umbrella in case it changes on the way, score card and pencil in hand it is time to start the project/game.
If the fairway does not stretch out in front of you then this is probably pitch and put and you are overdressed and equipped. Take a couple of clubs from the bag and put the rest back in the car. Pitch and put might be an appropriate metaphor for the support and maintenance phase of a software project but that is not the game for today.
So the first step is to work out how to approach the first hole. This is similar to planning the first release. If the hole is close by you might be able to reach it in one shot. Typically though the pin is some way off in the distance, perhaps behind some trees or lake and although you might have a general idea of where it is, trying to get there in a single stroke is very risky and could land you in a whole lot of trouble. The sensible approach is to work out how much of the course you do know about (the bit in front of you) and try to get the ball a far down the fairway as you can without hitting an unknown obstacle. Each shot can be compared to an agile software development iteration which takes on enough work to move the project forward and deliver value without putting the overall project at risk.
What makes golf and software development so interesting is all the factors that can affect the game/process. Weather, tools, mood, other people. Sometimes even the best players end up a long way from where they intended to be and have to take a drop shot to continue the game.
Sometimes development iterations don’t go as expected. There are so many variables that predicting the outcome of an iteration let a lone a full product release is not reliable.
I have found myself drawing the classic cost of change graph a few times recently so thought I would blog about it. The graph was popular a few year ago in explaining the differences between and eXtream Programming (XP) team cost and a waterfall team cost.
The important thing to remember in interpreting the graph is that the lifetime of a software system is typically far longer than the initial development. Most systems spend much longer in ‘maintenance’ than they ever did in ‘development’ so anything that can be done to make maintenance (ongoing development) more effective has to make sense.
The XP premies is that by augmenting the codebase with automated tests changes are easier to make later on. Developers can regression test the code to make sure that they have not broken anything and that their new tests also pass. This requires the same if not more discipline than the original development.
It is also important that refactoring be part of this ‘maintenance development’ without it the system will degrade, making it more difficult to effect changes.
A couple of years ago I was fortunate to work with a team developing a web application. Nothing special perhaps but the combination of background and skills for this project turned out to rather special. After the first release which was made under extreme time pressures new features were needed and added.
The key difference was the aggressive and determined pursuit of simple elegant code present in all of the team. At around the second release it was felt that ‘the code just wrote itself’. The code seemed to support the addition of new features and productivity improved dramatically.
Some time later it was decided that ongoing development be moved offshore.
As a lead developer this can be a troubling time but as part of the handover myself and another senior developer were asked to take the project offshore to ensure a smooth transition.
And this is where things got interesting. The team were delighted with the code and were keen to get started. Some scheduling conflicts meant that they could do a development iteration (1 week) and work on some of the backlog before envisioning the next major release.
That week was great fun with many whiteboard discussions about the principles underlying the architecture and the design.
After the development iteration the team felt confident in moving forward. That confidence proved to be true. The rate of changed increased and the client was delighted with the results.
If you are reading this and were part of the onshore or offshore team then thank you for such a fun time and wonderful code.
P.S. And yes I remember how hard the project was too.
On Thursday this week I will presenting a talk entitled ‘WebTDD’ at the ThoughtWorks Agile East conference in Conshohocken PA. It is the first outing for this talk and I have been working on the supporting software for some time.
I am really looking forward to this first speaking opportunity in the US this year.
If you are reading this and attending I look forward to meeting you there.
This has got to be one of the ultimate demonstrations of agility, confidence and poise….