When I started this blog I intended it to be about both woodworking and software engineering. It’s pretty clear that my focus has been woodworking, and more specifically woodturning.However, that’s not to say I’m not busy thinking about software engineering, I just don’t often think to write about it.
This week I found myself starting another agile project. A little over a year since I wrote about being ‘so agile they’ll need another word‘ and so I thought I’d write up some more thoughts on the subject of software engineering and agile projects.
Last year the project was one I had spent some time building support for, to overhaul our automation infastructure to be more sophisticated. It required a change in the accepted way of delivering results. Which meant convincing project managers that the new information would be *better* than what they were used to. Then convincing management that thoe whole package would be worth the cost of about 4 person months.
I really enjoyed that project, and I learned a lot. Both about how to run an agile project, but also about how to get one off the ground in the first place. I came to the following conclusion
People don’t know what they’re doing.
By which I mean, all of those people who ‘control’, managers, project managers, strategists etc etc. They mostly don’t have grand plans and visions. They are now ochestrating clever and subtle schemes to reach their goals. They basically are just winging it, like the rest of us.
The implications of this realisation are simply that if you have an idea of what you want to change, and can formulate a half decent plan to achieve it. Then there is a good chance that managers and planners will seize upon it with joy. At last! A plan! I don’t mean to undermine what these roles do, they keep projects moving, they understand what is required to deliver a project. They remember what ahs gone before. But the important realisation is that they rarely have time to think about great changes from the ‘norm’ and they will gleefully accept that idea you’ve been toying with, if only you can pitch it in their language.
Last year the project was a great success. And one year on I believe people are still feeling the benefits, looking back over the project it is clear that things went better, ran smoother. The project delivered on it’s promises.
That makes for a good reference when talking again about a project to run. And so it is that I started a few months ago paying attention to general talk around adopting a new product to manage our test tracking and reporting. There was a general feeling that we ought to be looking at it, but by default everyone is already completely commited to plans. And so ‘looking at it’ means, occasionally having a meeting to talk about it, but not actually having any time to *do* anything. It seemed clear that this would be my next target.
Part of the message I try to get accross about why such projects are necessary is : Automation isn’t free. And neither is significant change for the better. In short, you can’t expect to acheive great things for nothing.
For too long auotmating tests was sold as expensive up front, but then you got a lot ‘free’ like platform converage, repeatability etc. I think that this message set the wrong picture. Because many automation infastructures are woefully under funded for on going work. The attitude is very much that ‘we paid the high up front cost, now this bit is free…right?’
Well no, automation isn’t free, it requires people to make sure things keep ticking along. It requires updates to support new things. It requires skill and knowledge in what is often a complex environment. However, it has such a high rate of return, such an amazing return on investment, that it is easy to think of many of the benefits as ‘free’
I struggle to push the message that you get what you pay for, and when you pay into your automation infastructure you get a LOT. But it DOES require on going investment.
In this case I’m not dealing with automation as such, but we are talking about a big change. It has the potential to make many areas of our project ‘governance’ much better. It has fantastic scope to open us up to options that simply can’t happen without the first big step.
And it is this that I told people when looking into adopting this new technology. Anything *less* than a couple of person months dedicated time to get things going is a joke. If you aren’t prepared to stump up the resource for at the minimum that much. Then stop talking about it, stop thinking about it, because you’d just be wasting your time. Sure there are plenty of other things that you need to acheive with that resource, and you need to understand the relative priority of this compared to those things. But don’t for a second kid yourself that the team can effect such large change without some real time to plan, test, try, deploy.
And so here I am, 1 week into a 5 week project, where I have been given time, and a student. To really get to grips with how we will adopt this new technology. My goal is to have it either going into production at the end of the project. Or have a very specific list of blockers, and associated defects and actions to resolve them.
I love working this way. I have a set of stakeholders, people who will be the real customers of the system. and I meet them weekly on Friday’s. In that meeting I show them what has been achieved during the week, and get their approval to mark certain tasks as ‘complete’ Then I work with them to define the tasks of the next week. Sometimes this means making them agree amongst themselves the priority order for new tasks. Then everyone knows where we are, and what we’re doing. Why we are doing this first instead of that. The list of requirements can grow as and when the stakeholders think of them and define what they want. But they also get to help chose which of those on the backlog they *really need* this week. The great advantage of this is that you could keep the project rolling until people run out of *must have* items. You can stop at any time that people feel they’ve had most of the value. In essence the stakeholders are the ones who will ultimately decide some fraction of the requirements they raised, really weren’t that important afterall.
It also means that last weeks work finished on Friday, and next weeks work starts on Monday. That sounds kinda obvious, but pychologically, I am not starting to think about the challenges of next week yet. And those of last week are done, for better or worse I met with our stakeholders and showed them what we had and that was the end of the iteration. Working this way keeps me focussed. Everything boils down to ‘what do I have to show the stakeholders on Friday’. It makes for an intense working week, and sometimes it’s hard to go home at the end of the day and NOT keep working. But I have to remember that if did that it would be a disservice to anyone in the future. It would be dishonest to show a project completing on schedule, if it actually took me a weeks worth of over time to do so.
Week one is always hard in terms of just ramping up, but week two is where things are going to get serious. The level of expecation goes up a few notches, and my little team needs to start delivering real change. I’m looking forward to it, I know that success in this project is more than just delivering what I said I could, it’s showing that this whole way of working delivers consistent results. It means that next time I pitch a project, my job is a little bit easier.
Many projects I’m sure, struggle to justify the cost in terms of the benefits they yeild. I find a different challenge, trying to remind people there is a *cost* and what that is. It easy to see the value, but automation isn’t free, and change isn’t either.