Fumbling towards agility
Storytime, from the culture-change trenches. A long time ago, before Eric Ries published The Lean Startup when legions of executives talked about their six-sigma black belts, I had myself a management challenge.
The situation is probably familiar — we’d just slogged through a difficult overhaul of some first-generation web sites and were licking our wounds and trying to learn our lessons. Why had it taken so long? Why did all those lovely reports from the project managers turn magically from bright green to blood red in the final mile? Didn’t anybody read the spec document? Why did all the back-end developers think all the front-end developers were brain dead? Why didn’t it work they way it was supposed to?
Isn’t there a better way?
Like so many others, we were drawn to agile. The allure was powerful: Interaction over processes and tools; working software over comprehensive documentation; responding to change over following a plan.
For about a year we went through the motions with daily meetings, sticky notes and so on and while interpersonal communication improved there wasn’t any meaningful productivity increase. At this point, my colleague Rob Vretenar dug in and recommended a bit more discipline and elbow grease. This was the critical moment in the journey.
We built a real plan for transformation with the following components:
- Team ACT. A dedicated transformation team was formed. We dubbed it ACT (Agile Champions Team) and its membership included an executive (me), directors, managers and front-line staff. The team followed agile planning principles: We set a vision, identified epics, themes and stories that needed to be completed to fulfill the vision and then built a series of sprints consisting of stories we needed to complete to move us forward. We had regular stand-ups, planning sessions, retrospectives and even tried to demo our work to the entire organization — it was hard work that needed attention every single day.
- ADAPT. We wanted the way work gets done to change and that means people needed to be aware that there is a better way of working, they needed the desire to work that way, they had to have the ability to work in a different manner and the change needed to be promoted and eventually transferred to others. This is the ADAPT approach to agile transformation and it drove our thinking and helped us organize the stories we would prioritize.
- Help. We brought in professionals from Berteig Consulting, who dramatically increased the overall maturity and skill set of the entire department.
And then we began to make progress. Demos of working and shippable software became commonplace and a culture of learning connected to the regular rhythm of retrospectives took hold. Hard problems began to get solved and the interactions between developers and business stakeholders grew more meaningful. In the course of a year, productivity as measured by volume of code shipped, increased by 57 per cent.
Of course it wasn’t all roses. We never succeeded in convincing people to be truly cross-functional in their roles and we often felt we were working someplace between scrum and waterfall (“scrumerfall” we called it) but change happened for the better.
So cultural transformation is like everything else. You need to want it. Plan for it and work (hard) for it. Obvious perhaps, but too-often forgotten by those simply wishing things would happen differently.
Angus Frame is a digital media executive from Toronto.
Code Monk at Smile CDR Inc.
9 年We've been practicing Agile here at Intelliware Development Inc. for a number of years. Initial reactions: 1) I appreciate your recognition of the importance of discipline to successful Agile development. I've seen many an "Agile" initiative fail for lack of discipline and process. If anything, Agile development requires more discipline and more process than waterfall. It's kind of like a racecar vs. a train. The train will get you where the tracks go. But a racecar will swerve off the track if not diligently steered. 2) Software productivity is hard to measure; lines of code isn't a proxy. Sometimes shipping negative lines of code is a win. We have converged on a hand-wavy concept of a "story point" of functionality, that we've refined over years of experience. It's a HardProblem. 3) Practices we've found over the years to be key to successful Agile development are: a) Customer in the room. There's no replacement for having the customer sit with the developers. At a minimum half a day a week. b) Continuous Integration and DevOps. A phenomenal extent of delays can be traced back to integration and roll-out glitches. Open-source infrastructure support for CI and DevOps has exploded in the past decade. There is no longer a defensible excuse to not deploy early and often. c) Automated Testing. The fact that it becomes *easier* to make changes the closer you are to launch, not harder, is enough in itself. But there are so many other benefits to automated testing: it forces properly layered architecture, reduces ongoing maintenance costs--esp if there is any sort of break between dev activity.
Code Monk at Smile CDR Inc.
9 年All the fear has left me now I'm not frightened anymore...