All software development is iterative (without slides)
Posted on November 4th, 2009 by Paul McArdle – 3 Comments.
Well, 17 hours ago I was awake for an IEEE-organised Webinar featuring Kent Beck (founder of Three Rivers Institute) titled “Software G Forces: The Effects of Acceleration” – so I’m beat! Just another long day in a software start-up.
However I wanted to get this blog post up before it slipped my mind (please excuse me for any lack of polish in this one!)
Editor’s Note:
Having checked with Kent, he has advised the following:
The slides are published under the Creative Commons non-commercial, no derivative works license, so the use you propose in your blog is not allowed. You are welcome to rephrase what I said, highlight important points, etc, (as you did in the rest of the post) but I intend for the slides themselves and their precise content to be delivered by me personally.
That’s why I asked him! Hence, I have shifted the full post here (to a restricted part of the blog accessible to employees only) and put this shorter one up for public viewing….
A) The title is right
It was only during question time at the end that Kent really noted the above explicitly – however the main thread of the conversation was all about the fact that all software development is iterative.
For instance, even though we’re investing considerable time in the upgrade of NEM-Review at present, everyone is aware that this new framework won’t last forever – and, indeed, will most likely last a lot less time than the current framework has lasted.
Hence, if all software development is iterative (which I wholeheartedly agree), the key question revolves around the cycle time of the iterations.
B) The cycle-time is reducing
For reasons Kent did not really dwell on, the cycle time for development of software is reducing.
In our case, I have already written about our need to reduce our cycle time due to the many uncertainties we face – both technical and commercial.
What might have previously been a one-year iteration period has reduced to three months now, down to one-month (with Agile) and looks set to reduce further, down to weekly or even daily updates (now the case with some web-delivered software).
C) Old paradigms will hold less and less
As the cycle time reduces, any thoughts of retaining the old-style development methods (e.g. waterfall) become less and less credible. Instead, software companies will need to change their methods to match their changing environment.
Here, Kent showed a number of slides (which were very good, but which I unfortunately can’t include below - as noted above). As such, you will just have to make do with some notes I made!
From 1-year to 3-months
For each of the transitions, Kent provided a slide indicating some of the main challenges he saw an organisation would have to overcome.
In particular Kent stressed that, whilst automated testing might be a luxury for a long cycle-time, it becomes a necessity with Agile because:
1) There’s not enough time to do it manually
2) Because the code is always changing, there’s an increased risk that something that worked one day will be broken the next.Kent also mentioned the need to shift from one-off fees and pay-per-upgrade towards a subscription model, commercially. At least in our case we have never had anything other than a subscription model (just did not seem logical for me to do it any other way)!
However, as shown below, that’s not where it will end…
From 3-months to 1-month
In my view, this is where we are currently positioned – not specifically because we are doing 3-month iterations presently, moreso because I know we need to get to regular, reliable, monthly iterations.
I tried to institute monthly iterations for NEM-Watch v8, but this was implemented poorly, as Shane has noted.
A few points from what Kent noted:
1) With a 1-month cycle time, there is just no time to have a separate test team, analysis or QA team (indeed, as noted by Michael Levine, the client-facing people and code monkeys need to work closely together). Having separate teams always seemed like a retrograde step for me, anyway – perhaps an outcome of a start-up environment.
2) At a monthly cycle time, it is plausible that the commercial model for the software shifts to pay-per-use. We cannot currently implement this with our existing licensing system, but have it noted as a requirement for the upgrade.
3) At this point, clear and quick communication amongst the team is of the essence – hence user stories on sheets of paper pinned on the wall, etc…
From Monthly to Weekly
From this point onwards (in my view) we are looking further into the future than we can effectively plan, as a company.
I hope that we will be able to return to this in 18-36 months once all the other changes have been ironed out, and are showing some returns.
Given it was not of immediate relevance to us (in my view) I did not take any notes about this transition.
From Weekly to Daily
What was particularly noteworthy (for me) about this transition was that the move facilitate “split testing” – which could be especially useful in web-delivered services (for instance, in terms of interface design, or in terms of headline and offer in marketing).
This is certainly something that we need to keep in mind when working out our internet-marketing strategy. Kim has already started down that path.
D) Additional Notes
Finally, Kent made a number of additional notes that I think are very relevant to our situation:
How do we change?
Assume we have made the decision to change. The next logical question is “how do we make the change”.
Kent noted the Japanese word “Nemawashi” which he said was used in gardening in relation to shifting a tree by cutting the roots, one at a time. In other words, make gradual, ongoing changes.
Seems logical to me – very similar to the Agile methodology itself.
Visibility
Kent emphasised that the success of an Agile development methodology revolves around the high visibility of the key metrics of the project –
This would also refer to the burn-down chart I noted in my previous book review.
This is a step beyond the “what gets measured gets managed” paradigm.
How do you force upgrades on the customer?
Kent was asked this question. The logic behind the question is understandable, to some degree.
Kent was very clear on this one – you don’t force a client to upgrade. What you must do, instead, is learn why they prefer to stay with the superseded model and, in all cases, work to eliminate these reasons (be they technical or commercial or whatever).
I could not agree more. For instance, when we released the early iterations of NEM-Watch v8, we experienced some push-back from clients, for very valid reasons (e.g. features they had grown to love had been removed). Shane has posted about this. Hence, we did exactly as Kent suggested (though it was painful) – we made sure we alleviated all of the issues, to the stage now where clients generally love v8.
Can you do this with a junior team?
Kent answered that this was possible – just that it would be a load more painful.
I certainly empathise with this point of view. We’ve been around for 10 years, but the current employee who has been with us the longest is just clocking up 5 years. Hence, we have a junior team, which is making these transitions painful for all involved!
What’s the trade-off between Agility and Discipline?
A question came in referencing a particular book with a title something like this – but I did not catch the authors names.
Kent was very clear on this one – he rejects the premise that Agility and Discipline are opposed.
Arguably, he says, to be properly Agile you need to be extremely Disciplined – which is why it is hard to do with a junior team.
E) What it Means for Us
In November-December we will be undertaking some intensive business planning sessions (coincident with our 10th birthday) to set us up for the coming 10 years.
A core part of this process will be identifying how our approaches to software development need to change.
We’re also starting to look for a Chief Software Engineer to assist us with the transition (so more about this later). Will lessen the pain and speed us up in the transition!
Regarding “junior” teams, does this really refer to process maturity, or rather the understanding that there is benefit in moving forward within a process framework - not necessarily the years of experience the individual team member has had? Some of our most junior developers (e.g. recent grads) are the ones that took most enthusiastically to Scrum. Getting our most experienced veteran engineers on board is much more challenging!
Thanks Rob,
That’s a great point you make. I think their are a few factors at work here:
Personal Maturity
There are plenty of good books and resources written about this one - such as “The Myth of 9-to-5″. As this book points out, personal maturity is somewhat independent of age, and moreso independent of intellectual ability.
Personal maturity is one of the determinants of how much people will resist change (not one specific change, which might be resisted for other reasons, but more generally any change). With respect to our progression to a more Agile organisation, we have people at various stages of a continuum.
Professional Experience
Professional experience is a key determinant of how well we can do things such as estimate the time it will take to complete tasks (in simple terms, more experience provides more opportunities for “like-for-like” comparisons) - along with the obvious benefit of knowing better ways to code solutions.
This is one of the main reasons why I am very keen on fostering a culture supporting life-long learning.
As a rough guide, experience can be measured in years of working - but even this can be a little misleading, as many years stuck in a job providing no diversity does not deliver as much value as perhaps even fewer years in a more diverse environment(s).
What is “Junior”?
Hence, “Junior” is (in my view) a combination of maturity level, experience level and other factors I don’t have time to go into right now.
Of course we can (and will persist to) continue the development of our junior team - in my judgement this will be aided considerably by adding to our team people more senior and hence able to accelerate this development by acting as coach (amongst their other roles).
[...] posting my review of Kent Beck’s webinar back in November, I contacted Kent to confirm it was ok with him to [...]