We’re going Agile!
Posted on November 13th, 2009 by Paul McArdle – 11 Comments.
One of our central focuses back in our Business Autopsy in July (which we’re now starting to think of as Autopsy 1 - as distinct from the current Autopsy 2), was the fact that our software development processes were not up-to-scratch.
We were doing a number of things wrong (actually, too many to list them all here).
1) Back in May, Shane alluded to some of them in his dissection of the NEM-Watch 8 project,
2) A little later, Shane posted this review of “Lean Software Development”
3) Just this week I have augmented this with a longer diagnosis (for internal consumption).
4) The missing 6 months in between – well, that’s part of our shortcoming!
Coming out of the autopsy, we made some changes that did result in some improvements to our process – but we still disappointed ourselves.
As part of my personal philosophy, I am a firm believer that self-managed teams (i.e. teams of Responsible Experts, as noted in “Tale of Two Systems”) is the way to deliver sustained benefits over the longer term.
Hence, following the autopsy, I was keen to allow the team some freedom to try to find a methodology that worked for them.
To their credit, this did deliver some benefits – though we all accept that it was not a complete success. A central shortcoming is that we have been slow to accept the need to shift to an iterative development methodology (like Agile) for everything we do (over the years we’ve used it for some projects, but not for others – and no prizes for guessing which projects delivered better results)
As noted in “The Myth of 9-to-5” sometimes organisations – especially those that want to progress to effective self-managed teams – need a bit of a kick-start to get itself into alignment and hence get the bus in gear, heading in the right direction (just one paradox it mentions)
Hence we have launched into a process that I have started referring to as Autopsy 2.
It’s actually a couple of different projects we have on the go simultaneously(incorporating the use of some external consultants in some parts), that we will be pulling together shortly .
I will post about this later, when I have some more time…
In this post, specifically, I want to note a few decisions that have been made specifically about our software development processes, as follows:
Decision 1) We will adopt an Agile development process, starting now.
We won’t try to implement everything at once – just one element at a time, and on an ongoing basis.
Doing it in this way will not over-stretch us, and will deliver an increasing amount of benefit over time.
Decision 2) We will study, ONLY about Agile Development
As you will have noted, I have a strong focus on life-long learning.
For the intermediate future (i.e. until we are very proficient in their application), I am asking that our study of software development methodologies is specifically focused on Agile technique.
As we are really newbies at this, don’t expect us to be posting blinding revelations any time soon – but I do believe that the process of writing things down (such as through a post) helps to reinforce learning, along with revealing what it is that we really don’t know.
Once our “Aspiring Agile Development Guru” has developed enough confidence in his/her knowledge, they will be able to make these posts public (in the meantime the focus will just be on proving-up their knowledge, and educating the rest of us). I have someone in mind for this role and will speak with them about this shortly.
In essence, we need to read, review and then apply.
Decision 3) We will hire a Chief Software Engineer
I have already begun this process.
I am thinking of this person as our “General Manager for Delivering What the Customer Wants”
No more argy-bargy about one group blaming another – this guy/gal will be clearly responsible
This person will be selected in order that they can achieve a number of things:
1) They will achieve some quick wins by implementing an Agile Software Development Methodology for use on all our projects (large and small). This will make us much, much more efficient.
2) They will improve our capability for talking to clients and really understanding what they want from our software. Importantly, this will include “reading between the lines”.
3) They will build up the skills of our other aspiring Product Managers, such that they will be increasingly in a position to deliver the same level of value. This will be by coaching, and learning by doing.More about this later. We want this person to be starting as early in 2010 as possible, but (by the same token) we need to ensure we find the right person.
Decision 4) We will Learn by Doing
When the Chief Software Engineer is onboard, everyone will learn by doing – that means everyone will be coding, at least part of the time.
Our Chief Software Engineer will have the largest say in terms of the structuring of our software development team, and the processes used within – but my objective is that the aspiring Product Managers will be given this opportunity to quickly upskill.
Decision 5) Every Project will be reviewed a similar way
My review of the NEM-Watch 8 project was much more comprehensive than anything that had been done before. Doing such a review serves multiple purposes including:
1) Celebrating our wins (yes, we do get some things right, some of the time – and our customers generally love our products, even if they are a little – ok, a lot – delayed)
2) Providing a real opportunity to assess opportunities for improvement in future
3) Serving as a focal point for our institutional memory (this has been an issue for us in the past, as we have lost a number of key staff from the early days who could have passed on, verbally, more about why we do things the way we do).
From now forward I have asked that all future projects are wrapped up with a similar review.
We look forward to seeing the results delivered through this process – both quick wins delivered rapidly, and sustained improvement over the longer term.
[...] a real understanding of the subject matter at hand (whether it be the electricity market, or software development processes, or marketing, etc…)
[...] and increasingly in the sprints we are developing as a result of the initial moves we have made to adopting Agile. This has reduced the amount of time I have been asked this question on a day-to-day [...]
[...] 5)
[...] was one of my primary motivators in stipulating our move towards Agile Software Development, for instance.
[...] We understand that we need to be more agile (i.e. small “a”), but are taking more time in adopting an Agile mindset than should be the [...]
[...] taking this approach as it’s aligned with a focus on agility that we are trying to instil throughout the company (i.e. quick response to our needs, and those of our clients, and an iterative, learning-by-doing [...]
[...] welcome, and quickly incorporate customer feedback during our development projects. We have made some initial steps down this path, but are hampered by the fact that we have a young-and-inexperienced software development team, who [...]
[...] (c)
[...] our Autopsy 1 process, which continued into the Autopsy 2 process, my stipulation that we were going to go Agile, and the commencement of our process for looking for our Chief Software Engineer. Note that there [...]
[...] have a long way to go in this respect.
[...] I do apologise for any misconception caused by posts such as this one. [...]