There’s a concept core to Agile Software Development not mentioned explicitly in the Agile Manifesto or the 12 Principles behind it.
Context is very important.
You could even craft it in the form of the other value statements in the Agile Manifesto:
Consider context over best practice.
This is the idea that many people refer to when they cryptically answer a “How do you do X?” question with “It depends.”
Context plays an especially important role when your team considers what frameworks and techniques to use as you create your team’s methodology.
Different techniques and different frameworks are better suited for different contexts.
So when you hear questions such as “Which is better Scrum, Kanban, or XP?” find out what context the person asking the question is concerned about and let them know that those choices are not mutually exclusive.
There are a variety of aspects of a specific context to consider when you decide which framework you’ll use as inspiration for your team’s methodology. Here are the key choices you need to make.
Cross-Functional Teams or Existing Teams
A core aspect of Scrum is that you form cross-functional teams with new roles and specifically follow the few prescriptions embodied in the framework, such as organizing work into sprints, using the various artifacts, and holding the various events, such as sprint planning, the daily standup, the sprint review, and retrospectives.
Kanban on the other hand says to start with the process, roles, and organizational structure you have today, visualize your work, and change gradually.
The route you choose here depends on your organization’s appetite for substantial change right away balanced with the likelihood that your team and organization will make the necessary changes as you identify them.
I’ve found a lot of value in pulling people together into focused, cross-functional, dedicated teams and allow them to work together on one thing at a time.
Timeboxes or Flow
Both Scrum and XP have some concept of a timebox that you can use to allow your team to focus on a specific set of work for a specific time period, deliver something at the end of that time period and get feedback. This approach can be helpful when you have a considerable amount of work to do on your product and you want frequent checkpoints to get feedback along the way.
Kanban meanwhile handles work in a single-piece flow. This approach is helpful when the arrival of items you need to work on is unpredictable and each item on its own can be delivered to users and customers when it’s done and immediately provide value. This is why many operations and help desk organizations find Kanban more useful in their situation.
Many teams find that a flow approach provides them much more flexibility to respond to changes in priority, because they make the decision of what to work on next every time they pull a new item into their workstream. They also find that they can get faster feedback because they deliver each item when it’s done, as opposed to waiting until the end of the timebox.
That last reason is a bit of a red herring because there’s nothing preventing your team from delivering work multiple times during a sprint if your environment supports that and your customers can absorb the change.
I’ve found that a flow approach works best for most of the situations I’m in. Alongside that flow I mix in regular checkpoints to confirm that the backlog (or queue if you like) is ordered properly (you can think of that as similar to a sprint planning meeting), daily meetings to coordinate activity, and regular retrospectives.
Good Engineering Practices and Good Product Practices
Neither Scrum nor Kanban has anything to say about how your team actually develops software. That’s where Extreme Programming (XP) comes in. Good technical practices such as Test Driven Development, Pair Programming, Refactoring, Continuous Integration, and several others are either part of XP or sprang from teams that primarily used XP.
While I encourage teams to start using these practices as soon as possible, the typical adoption pattern is that a team starts using Scrum or Kanban, and then realizes they need to improve their core software development skills. At that point, they start exploring the various practices included in XP.
The one area where Scrum, XP, or Kanban provide no concrete guidance is how to actually determine what it is your product looks like, and how to make ongoing decisions about what the product should have in it, when you should release it, and whether you should keep working on it.
Scrum does identify a role to cover some of this work-the Product Owner but doesn’t provide much insight into how to go about doing that work aside from how that role operates within the rest of the Scrum framework.
Teams have found practices from fields such as product management (product ownership is a subset), user experience, and business analysis fill the void. Inspired by techniques from those fields, people in the Agile community created techniques such as Project Chartering and Story Mapping.
Creating and Revising Your Methodology Is Agile
Your situation is different than that of another organization. Your situation is also going to be different from one year to the next as the skills of your team increase, or you start a new project, or you get different team members.
The way your team chooses to deliver products will be different than those of other organizations and will change from one year to the next. Frameworks like Scrum, XP, and Kanban provide good starting points for your team to create your methodology, but you’ll need to figure out what works best in your context.
That means don’t be afraid to use aspects of a variety of frameworks, as long as you understand why. It also means you may need to supplement those frameworks with other techniques, as long as you know why you chose the techniques you did.
Do you have experience combining techniques from multiple frameworks? Share your experiences in the comments.
Photo Credit: https://unsplash.com/@peterychuang
