Back to Basics: Delivering Great Products with AgileAdded to Business
It’s been over 15 years since the Agile Manifesto was created. Since then plenty of methods, frameworks, models, and tools have been invented and reinvented. It’s easy to see how it can be overwhelming to get started with Agile.
I remember the first Scrum Master job I had about 10 years ago. We had assembled a team that was mostly interested in working in an agile way, and we were working on a project that didn’t have too many strong dependencies with other parts of the 25,000+ organization.
After a 3-day liftoff, we were off to the races … er, sprint. At the end of the first sprint, we had finished development on all the stories but we hadn’t finished the testing. In today’s world we call that done. If testing is finished in the sprint, that’s now called done done. In the event we actually release to production, that’s now called done done done.
In our retrospective, the team lead (who’d worked there for 10 years and was just awesome) said, “Maybe we should help the testers next time?”
That was the catalyst for helping our team put our titles aside and for helping us focus on delivering the product to our customers. When we released to production, our product owner said it was the first time something had been delivered that quickly without any known defects in the 8 years she had been with the company.
This year’s OnAgile theme is Back to Basics: Delivering Great Products with Agile.
Over the years, we’ve strayed too far from the core of what Agile is. We’ve tried to figure out how to make development more agile, or how to make testing more agile and somewhere along the way we’ve lost sight of why the manifesto was created in the first place.
This year, OnAgile2017 — our annual virtual conference — will be held on October 25, starting at 9am EST. Save the date on your calendar as we’ll be announcing speakers soon!
Image (c) 2017 Lynne Cazaly
Used with permission. www.lynnecazaly.com
This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.