Switching on the Agile lightbulb
March 21st, 2008
I've got to admit I'd always had a jaded opinion of the Agile software development methodology. From what I knew of it - no detailed requirements document, no functional specification, no prototyping, no design thoroughly first then build it - from all of this it seemed to me that Agile was something dreamed up by a software developer, for software developers, but a potential nightmare for testers, technical authors, marketing, sales and support. To me it seemed like Agile was a kind of a "let's just bash on and make it up as we go along" approach that left developers free to do whatever seemed best (or maybe just easiest), without being tied to anyone else's plan, or maybe any plan at all. And, as a technical author, how do you document something that's evolving from day to day according to the whim of developer?
So that was where I was with Agile until the week before last. Not hostile to Agile, but definitely skeptical.
Then, as part of the restructuring exercise that's underway at my work, I spent a week with MarketAcuity CEO and Agile guru Sam Bayer. I'm not entirely sure what Sam's mission was: whether he'd been tasked with introducing Agile product development to the company, or just talking us through the Agile methodology. He has a very laid-back, discursive approach, so it's hard to tell. It never felt like he was trying to teach us particularly, more like he was just talking with us about one way of doing things.
We started with some basics of Agile product development. What's the point? Answer: it's about accelerating value to the customer. The 4 pillars of Agile:
- Customer The process is centred around the customer. It's not about producing some new, cool product because it's something we think would be interesting to work on, or because it's this year's big thing. It's about finding out what our customers and potential customers need and value and doing that for them.
- Demonstrations Show your customers the real production software (not a prototype or a smoke and mirrors job) on a regular basis and get their feedback.
- Iterative Build something, demo it, get feedback, build some more, and so on. Demonstrations could be a week or a month apart, but probably not more than a month apart, and always on a regular schedule. Don't go away and work on something for six months or a year only to find at the end of that time that it's not really what the customer wants, because they found it hard to explain, or you weren't listening, or they changed their minds/personnel, or the market or operational environment changed.
- Collaborative This isn't the waterfall approach. There's no leader passing down commands that must be obeyed. Within the company everyone's got a role and a job to do, but these aren't set in stone with high walls. The team have to work together according to their knowledge and abilities to get the job done. And, looking externally, you've got to collaborate with the customer and bring them into the process.
Potentially similar posts
- Tech Writers Need to Learn to Say Yes. However … – June 2010
- The Art of Agile Development: “Done Done” – April 2010
- Deobfuscating the title page – November 2009
- Site problems – October 2008
- The help system or CSH topics – which is more important? – October 2008