I don’t think I’m the only one that gets a little bit turned around sometimes when I’m talking about Agile. It’s tough to quickly state what Agile is and how it affects software development teams on a day-to-day basis. Some teams focus on these aspects, concepts and practices, while others focus on those. Ideally, Agile should be a holistic effort, but I think in real life most companies that are trying an Agile approach are still focused on specific processes and might not see how those processes fit into the big picture.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I mean, I know the Agile manifesto: “People and communication over process and tools; working software over heavy documentation; customers over contracts; and responding to change over sticking to the plan.” Those are all set in my mind and so are the twelve guiding principles in the Agile manifesto. I won’t list all twelve, but I think “break down work into smaller components that can be completed quickly,” and “provide motivated individuals the environment and support they need and trust them to get the job done,” are two good ones.
But – even with a solid picture of what software development teams should be doing, I still get a little confused about how an Agile development team does those things. I had a great talk earlier this week with one of the founders of a major testing services company – Michael Hackett, a senior VP at LogiGear talked with me for a long time and was really clear about where Agile processes come from and how they contribute to fulfilling the promises of the Agile manifesto.
According to Hackett, the processes that let software development teams achieve Agile goals come from at least four separate sources. There’s Lean, Scrum, kanban, and extreme programming (XP). Hackett says these are the major influences in how software quality pros go about making Agile principles a reality. The problem, in his view, is that most organizations sort of pick and choose practices from each of those four and make their own mix-and-match Agile program – usually with a bunch of hang on waterfall techniques or exceptions to boot. He said that’s been a pattern for so long that now organizations are learning “Agile practices” from folks that have forgotten where they come from.
For instance, Hackett said he is still amused by how often organizations are using one or two specific Lean practices without knowing what Lean’s really all about or that they’re doing half-hearted Lean development. These organizations think they’re just doing Agile. Hackett said the Lean principles overlap with Agile principles very well and that organizations would do well to take the full scope of Lean into their development effort, but that usually they take on two or three Lean principles and leave off the rest. That’s a no-go in Hackett’s book. You can’t “eliminate waste”, “decide as late as possible”, and “deliver as fast as possible” if you don’t simultaneously “amplify learning”, “empower the team”, and “build integrity into every step”. Using both halves is the keystone principle – “See the whole.”
Hackett also went into detail about the contrast between kanban and Scrum – both of which are ways of managing the pieces of projects. Basically, he said kanban is a fluid process focused on getting each piece done and done right before moving on, while scrum is a more time-centric approach that focuses on meeting deadlines for each step of the process.
He also talked about XP and the way that extreme programming closely ties with continuous integration (CI). I got the impression that a well-oiled continuous integration program is like Nirvana for a software development team. It’s a very difficult journey of change to reach CI, but once you’re there you’re golden and the software almost writes itself. Well, maybe I’m exaggerating a little bit, but Hackett did say that continuous integration should be the ultimate goal for any team that’s looking to attain maximum application development flexibility.
Finally, Hackett went into detail about the role of the product owner (PO). He cited surveys that show POs are consistently the team members with the least understanding of Agile, which is a shame because they have the most influential role. Educating POs about their responsibilities and supporting their involvement is difficult, but extremely valuable, in Hackett’s view.
Stay tuned to SearchSoftwareQuality.com as we bring more details about these building blocks of Agile, tips on choosing the right cloud infrastructure services, and a rundown of the top ten myths of release management. All this and more coming real soon. Until next time, remember that it takes longer to explain why you did a thing wrong than it would to just do it right in the first place.