The Art of Product Management
The phrase “There is an art to this job” usually means there is something opaque about it that can’t be easily defined.
By:
Anyone who’s ever built anything can understand there is a specific tool in their toolbox which is best suited for any given situation. One may find a job or build requires several specific tools, each with a specific use to complete a specific task in the overall approach to the job. In other words, you’ll want to have access to your entire toolbox. Once this approach has been decided, one uses specific tools in a certain way with specific knowledge, and this knowledge means understanding the desired effects of the tool, how to incorporate complementary tools, and the way these tools work together. This premise is simple enough even for the non-builder. Good luck driving a nail with a screwdriver or turning a screw with the blunt end of a hammer. You get the idea easily enough.
The word ‘agile’ is a commonly used term we’ve seen emerge as a critical piece in how businesses are innovating and modifying the way they work. An agile development approach is how Nexient creates world-class software people love to use. Our development teams utilize a few different approaches all within this ‘toolbox’ of agile, so to speak. It’s important to understand, there are several ways to approach a project, and while we’re not saying this is ‘the’ way, we’re saying this is ‘our’ way, and many of our Fortune 500 clients agree, “It works pretty darn well.”
First, let’s open the toolbox for a common and important approach known as agile. Maybe you’re familiar, maybe not, ‘agile’ is a time-boxed, iterative approach to software delivery for building software incrementally from the get-go, instead of trying to deliver it all at once at the end, otherwise known as ‘the waterfall approach.’ Good to get that definition out of the way.
There are excellent frameworks within the agile toolbox, all of which follow the Agile Manifesto, and the 12 principles of agile development. Nexient teams have found success with 3 of these frameworks in particular, though all are valid in their own right. Our teams mostly utilize Kanban and Scrum, and then occasionally XP too at different points in the solution process, depending on which is best suited toward the solve. It’s also helpful to see these frameworks resting on a spectrum regarding number of practices one must follow. On one end is more prescriptive methods which have more practices, while moving toward the opposite end are more adaptive solutions which have fewer practices to follow.
Let’s look at the difference between Scrum and Kanban. We like to say Kanban and Scrum have similar DNA in that both align with the 12 principles of agile development set forth in the agile manifesto; both encourage collaboration, accountability, transparency, and self-directed teams; both use similar team sizes; both are time boxed; both value continuous improvement; their workflows are visible and transparent, and both strive to toward process optimization. Still, as every craftsperson knows well, there is always an optimal tool for a specific job, one with attributes fit for specificity. In other words, the right tool for the job.
Does this at all sound familiar? Your team is using an agile approach to software development, specifically Scrum as you’ve always done. You’ve planned it out to the best of your ability. However, the middle of your sprints are consistently hit with ‘surprises’ which necessitate replanning and constantly change the sprint goal. This ‘problem’ is a clear invitation to switch from agile software development with Scrum to the ‘flow perspective’ of Kanban. Just as there is always an optimal tool for the job, within the agile process, there is inevitably a ‘sweet spot’ where one approach excels.
Several ‘sweet spots’ optimal for Kanban software development use include teams with a highly unpredictable flow of work such as with ‘help desk’ tickets, or production team support. Another opportunity presents itself when greater than 50% of the work a Scrum Team is doing is “unplanned,” then they may want to consider using Kanban as an alternative to Scrum.
Kanban is ideal for agile software development teams in a well-established, infrequent, lean, and stable world where tasks are highly predictable, repetitive, and often require specialized knowledge. Think of a team supporting stable legacy technology and applications, requests for enhancements and adjustments are coming from many customers, multiple project teams, and frequency varies, a Kanban approach excels. In terms of DIY projects around the house, consider the Kanban approach similar to a ‘weekend to-do list’ where items are adding up, and once the weekend rolls around you begin marking off the items as you go, one after another.
With Scrum, an ‘inspect and adapt’ approach allows for teams to more often assess where they are and better determine what needs to change for them to get where they want to be. Scrum ‘sweet spots’ are analogous to a larger DIY project, say building and finishing a new room on a house, this approach works well for teams when most of their work has a longer time horizon. The work can be prioritized, it may be new development, or major enhancements with many unknowns, along with new work which can be sized and planned. As part of a larger coordinated project, Scrum is often the best choice to address dependencies and synchronization demand. When work items have a large variation of size and complexity, Scrum holds the answers. And the sprint timebox is a very effective mechanism for controlling WIP and enhancing team predictability.
Again, there’s always an optimal tool for a specific job. Some agile teams use Kanban when their project would clearly benefit from the additional structure of Scrum. For example, a team can take advantage of Scrum's 2-week timebox (a Sprint) to improve predictability. By measuring "velocity" they understand what they can accomplish during every sprint, and this helps them plan with greater confidence and deliver high-quality software with more predictability.
As agile coaches and practitioners, we understand the idea of people being used to one way or another, and often sticking to a favorite path toward a goal of success. Hopefully this article has shown there are multiple, complementary paths one can follow, each with their own sweet spot for solving unique opportunities. It’s a safe bet you’ll enhance your team's offerings when you honestly answer the question, “Are we leaving the best tool for the job in the toolbox?”
Ending with a quote by Bernard Baruch to really drive home the point of using the best tool for the job, “If all you have is a hammer, everything looks like a nail.” Perhaps it’s time to open up the agile toolbox and examine the tools you use, if for nothing else than to explore the opportunities your teams might be overlooking.
Want to learn more about how you can level up your agile efforts? Nexient can help. Click here to contact us.
Design cutting-edge software and digital experiences for America’s most admired brands with Nexient.
.svg)
