Monthly Archives: January 2014
Introducing Agile into your software development projects, or other organizations in your company or into your life has produced
wonderful, empowering results for many people – myself included. I often get asked “What is Agile, in simple terms?” Here is my attempt to boil it down to 100 words which will hopefully resonate for everyone, regardless of your background.
Agile is an approach to problem solving. We tackle big projects by breaking them down into small, deliverable chunks. After each chunk is completed, we inspect it and adjust based on what we learn. We prioritize each chunk based on its value, to ensure we work on the most important stuff first. We work as a team where smart people get together face-to-face to brainstorm solutions to complex problems. We succeed as a team and measure our progress to immediately address any roadblocks. We strive to deliver more chunks with higher quality and clear value on a frequent, sustainable basis.
What do you think? What is missing? Does that make sense to people who aren’t part of this movement? I would love to hear what you think.
I recently had an enlightening conversation with someone who was just learning about Agile. She was deeply entrenched in a Waterfall methodology and legacy PMO practices. She had lots of questions about how Agile works in a Stage-gate approval process and client contract negotiations. But what captured my attention most was her frustration over rework. She said, “we recently had a situation where a client came to us with a half-baked idea. Before we had finalized the requirements, IT went ahead and worked on something. That led to seven rounds of rework before we finally satisfied the customer. How would Agile have handled that?” It is a good question, but the answer is about far more than just a process change.
The paradigm shift that Agile suggests is that rework isn’t bad. That is a challenging concept to get your head around. Let’s look at the woman’s example again and shift the language slightly. “Our IT department responded to a client and showed them an option based on the available requirements. Upon seeing the working software, the client was able to refine their request and provide more clarity to IT. After seven iterations, the client was thrilled.” Mind-blowing, right? If we simply pivot our expectations, we might find that we can be more Agile in our approach to solving customer problems.