Our Agile transformation story
It's nearly two years now since we started to the journey toward being an Agile company. So, it's probably worth taking stock, getting the photos out and having a look at where we've been.
Why did we bother?
A million years ago, on a planet far, far away, I worked as a work study engineer (or a 'time and motion man' for those of you old enough to remember the more derided expression) for a construction company. Despite the workers thinking you were just there to monitor how slowly they were moving, work study (as it says on the tin) involves examining the process of how people do things. Whenever we would make suggestions regarding how we should change methods, you would hear the same phrase repeated, again and again:
'But we've always done it that way!'
And this was Aquila Heywood's problem: it was making a profit, staff turnover was high but 'Hey, that's developers for you!', customers came and went but 'Hey, that's customers for you!' and we were using the tried and tested Waterfall method.
And 'we had always done it that way', so why change?
Yes, we were putting out versions and customers were buying them, but those versions normally took eighteen months to create. The new features, which had been asked for by customers, were now redundant, the market changing in such a way that they were no longer required - or at least not how they were designed eighteen months ago. And boy, were they designed?! Requirements, Business and Technical Specifications, each with a lengthy discussion and signoff process. Each rarely seen by the audience for which it was intended.
This was matched up with an estimation system that gave a set budget and date as to when enhancements would be completed. This caused a 'pressure-cooker effect' on staff members, who would be often asked why they had taken so long on a task and contrarily asked to work more hours, potentially at weekends, to get functionality completed before a certain date. A side-effect of this was the 'siloing' of knowledge, staff members not having time to spread knowledge when under this kind of pressure. Of course, another side-effect was people just getting up and leaving...
The exhaustive documentation of the Waterfall project didn't stop with the specifications, either. They were then used to create exhaustive unit tests, system tests and integration tests, which for the most part were manual. A team member, therefore, had the unenviable task of having to execute them every time a change affected that part of the system. There were no dedicated testers, as such, so this would revert to whoever was suitable.
All this malarkey had to be driven in some capacity and, within the Development department, we had a middle-management cadre of team leaders who were sandwiched between budget-driven project managers and increasingly depressed development teams. Most of the decision-making was made by these team leaders, with little interaction with the members of the teams.
No wonder you bothered!
It's easy, in retrospect, to paint a dark picture but, as mentioned previously, the Company was in profit, had a decent customer base and was winning awards. But, on the shop floor, morale was low and attrition was high. Considering the focus on timekeeping, the amount of time wasted creating documentation and manual testing was large. Not to mention the number of defect reports that were coming back from customers, mainly because what they received was no longer what they wanted.
But there were attempts to change our methods in Development. A series of complicated enhancements was undertaken using what was called a 'Stepping Stone' process, a melange of ideas from Scrum with the structure of Waterfall. Ultimately, this was flawed due to trying to mix the two very different ways of thinking, but it was an attempt to start undergoing a process of change, which would eventually lead to Agile.
In the next part of this blog, I'll talk about how we started to make that change...