The development lifecycle
Irrespective of which approach a company is using, it all starts with a customer need:
This need must be understood, so we need to invest some effort into understanding.
In Scrum, we call this "Refinement". It could also be called an Ideation or Prototyping process. Regardless of how you call it - it's essential to build the right product!
Once understood, our next job is to build something. Any kind of iterative approach encourages us to build just a little, then learn from that. We want to minimize our upfront planning efforts and jump right into doing delivery work. In Scrum, that's our timeboxed "Sprint".
The objective of delivery is to get something shipped right to the customer, we want to make the product available. This is often called "Minimum Viable Product", in Scrum we call it the "Product Increment".
When we got the product out of the door, we want to learn how customers respond to it. This is where most agile implementations disconnect: Scrum has a "Review" - although the Review still happens disjoint of both the problems and opportunities arising when our product hits the shelves!
What happens in the "Real World" becomes the job of Support, Customer Service or Marketing.
This final piece of the puzzle is vital to build an even better product in the future. We want to iterate a full cycle in increments as small as possible:
The business opportunities when integrating this cycle are immense: Anything that is of value can be turned into revenue, anything that wastes effort can be turned into saving. To harness this potential, it's essential that a single team has the ability to recognize and create these benefits.
Now, it's time to take a closer look at some agile frameworks:
Standard frameworks
Scrum
Scrum is the most common framework. It excels as a delivery framework. Based on the Scrum Guide, it neither cares for what happens in order to get the right items into the Product Backlog nor what happens after the product increment has been delivered.A small fly in the ointment is that Scrum scopes the timebox: it doesn't bode well for a Scrum team to deal with unplanned work. Yet, everything that happens with customers in real time is hardly planned, much less does it make sense to plan it upfront.
Kanban
Like it's cousin Scrum, Kanban focuses strongly on optimizing the delivery process. Kanban provides less emphasis on getting a planned shipment through the door, offering higher flexibility in dealing with unplanned work. Teams that have productive maintenance responsibility often fly well with Kanban.Side note: Scaling Frameworks
Scrum scaling solutions, such as Nexus, Scrum At Scale (S@S), LeSS focus on doing the same thing with more people - getting better at delivery. Combining these frameworks with Enterprise Kanban practices, like suggested in SAFe, is still limited to the delivery portion.While SAFe strongly encourages integrating DevOps, the suggested use of DevOps is still restricted to getting the product through the door in the most reliable fashion.
Design Thinking
It's often adertised that Design Thinking combines well with Scrum, and indeed it does. Design Thinking addresses understanding the customer need through systematic exploration before delving into a more costly delivery process.Lean / Six Sigma
Regardless of whether you're thinking Lean, Six Sigma, or the standard combination "Lean Six Sigma" - these frameworks address optimizing our existing product through better insight:Extreme Programming
Returning to the agile hemisphere, Extreme Programming and some of its derivates, such as Programmer Anarchy, add more emphasis on understanding the customer and providing the right solution for the customer's needs.DevOps
DevOps is concerned with two things: Getting the product to the customer with minimal overhead and delay - and understanding how the product is being used.The first, and well-known, portion of DevOps is providing an automated delivery Infrastructure - Continuous Delivery, Infrastructure as Code, Containerization, Logging, Authentication and many other things come to mind.
In addition, DevOps, done well, provide a myriad of analytical insights into the product: which features are being used, how new features are being received, where unexpected things occur, how to solve customer issues etc. This requires more than technical insight - it requires harnessing business insight as well!
The big picture
DevOps is an essential piece of the puzzle towards hyperperformant teams. The full power of an agile team requires a smart combination of discovery and delivery methods. It's your choice whether your team sails under the Scrum, Kanban, XP, none or any other banner - just make sure you cover all of the blocks:Design Thinking shines for the "Understanding customer needs". Scrum is great to cover the "Doing work on customer needs" section. Combine these two with DevOps to optimize your "Working on the available product - both before and after delivery" approach.
For best results, you might want to add a touch of Lean, an ounce of XP and a pinch of Kanban,
Closing the loop
Let's forget frameworks for a minute. What's important is that you got everything covered. Use Design Thinking where it helps you build a better product. Apply XP where it helps you build the product better. Try Scrum elements that improve your delivery process. Utilize DevOps tools and practices to ensure you're doing the right thing when the rubber hits the road. And never forget - Lean/Six Sigma has really powerful tools that help you do the right thing better!
If you look closely, you will discover that this cycle is an implied "Build-Measure-Learn" cycle, which is the core premise of Lean Startup, yet another framework from the agile bucket.
No comments:
Post a Comment