Selecting your Agile way

The Agile Manifesto gives us guidance but it doesn’t tell us how to execute it. Frameworks like Kanban or Scrum that are built on agile principles are not the only way. Scrum, for example, does not equate to Agile. It might be the most popular framework out there, and for sure it has its benefits, but remember that it should be applied when it actually solves the problem you are faced with.

Still if you do not have much history with agile methodologies, you might try to start off with one of the well-known frameworks and set up your process based on the experience of others. Then with time, as your understanding of your needs grows, you can adapt and change.

The first questions should be:

• Why do you want to implement Agile methodology?
• What do you need Agile for?

Example answers to those questions can be different. Sometimes your needs are more general, like for example:

• Have you read about one of the many failed IT projects and you don’t want to find your own project on that list?
• Have you been working for years in a waterfall environment and you see how much waste comes from long, one-way processes that prevent you from changing scope after months of implementation?

But sometimes what you need is quite precise.

• Do you need fast responsiveness to changing business requirements?
• Do you need better observability of your delivery process, improved technology and business alignment?
• Or maybe it’s about identifying bottlenecks in your current process?

Depending on what it is that you are trying to achieve, you might end up with a different implementation of Agile methodology.

The great value of Scrum and Kanban is not just that they solve specific problems for which they were designed very well. Today, maybe an even greater benefit is that they are industry standards. People learn and get certified in Scrum, yet debate over the proper execution of the framework still exists in every single project.

Each change to the standard increases the risk of discussion and questions, requiring dedicated internal training and more work for your Agile Coaches, if you have them. Consider this quote from the Scrum Guide:

The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.

Think about that when designing your process. Does introducing a change really bring you enough benefit to justify it?

So, if you want to boost your development team’s productivity, there is a known recipe for that. Scrum is a well-known framework with a proven record of successful implementation. Designed to promote transparency, inspection and adaptation, Scrum indicates commitment, focus, openness, respect, and courage as the most important values for a Scrum Team.

To achieve great results in building software products, use Scrum, but do remember that it’s not only about your development team. If your business is not involved in the whole process, you’re not really doing it right. Agile doesn’t stop when the software part ends. The Product Owner should be an actual business stakeholder, involved in your day-to-day operations, as well as in your software development process.

And if your problem is delivery effectiveness, then why not give Kanban a try? Designed to identify bottlenecks, this framework helps your team achieve top performance. Kanban helps you to create an effective production line and can be a good choice for a maintenance project. The core assumption is that you will not exceed a given number of parallel tasks. Just like in a factory, if one of your lines is blocked, subsequent products will not just skip over the problem.

But who will remove the obstacle? As it often turns out, the reason for the delay is outside the team’s jurisdiction. Kanban assumes that management, or even better, the whole company is dedicated to the removal or repair of the problematic element of your production line. You need to observe and identify which stage of the process is the slowest one, and concentrate your efforts on improving it. And it shouldn’t matter if the change has to happen within the team or outside it.

If you are not committed to end-to-end process improvement, then maybe choose a different framework. And if you’re considering a change of framework just because you end up with unfinished stories at the end of every sprint, then Kanban is not the right solution for you either.

But if you have decided to go your own Agile way, please consider this: does it make sense to use Scrum terminology if you are not really using Scrum? Is it really a Review you are meeting for? Is your increment the same as is in Scrum, and if not, is it clearly explained somewhere? Make sure you have your custom process very well documented and that the onboarding process includes training in your bespoke methodology.

Nevertheless, reality shows that keeping properly aligned with the rules of standard frameworks like Scrum is not always possible. When changing an already existing functionality, by introducing small features or minor refactors, we might be able to fit increments into our typical two-week sprint. We might end up working happily like that for quite some time.

Nonetheless, what about when a major code refactor comes in, or if it’s a full architecture change, or maybe a regulatory requirement for which 20% implementation just doesn’t make sense? Are parallel versions of the application, merge conflicts, feature flags and multiple retests really the right choice? Or maybe sometimes it actually makes sense to wait longer for your increment? Even if it goes against the principles of transparency or inspection a little bit.

Not everyone has a full regression tests package that keeps up with the implementation. Scrum says your sprint should be shorter than one month and that all sprints should be of the same length. But the principles of Agile Software only state that you should:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

It’s up to you to choose which one makes more sense in your situation.

Fortunately for those who like a bit of freedom, neither Scrum nor Kanban specify how to organize your process below the level of milestones, such as identifying if a particular item of work is ready or done. Most Application Lifecycle Management tools like Jira or Azure DevOps have predefined workflows for managing development tasks. On the other hand, they do also allow for those to be modified to your personal needs.

Of course, it matters if you work with Use Cases, User Stories or something else. However, it’s entirely up to you to decide if you need one or ten steps to reach the Definition of Ready.

Your process can be more or less formal depending on your needs. If your team has stricter rules on analysis, you might need some additional steps or flags in your process to make sure all the necessary verifications have been done. If you have some complex incident tracking rules, you might also want to adjust for that. The release process, quality assurance and bug tracking – all of those should be represented within your process somehow.

Nevertheless, unless you have a good reason to force a specific way of handling that, then it’s probably best to leave the decision to your team. This is exactly one of those things you can adjust over time, choosing actions to take for Sprint Refinements. That is, of course, if you have them.

As previously mentioned, Scrum is immutable. This also applies to other frameworks which you can choose to implement. However, sometimes getting to the point when you can implement an entire framework takes time. So don’t worry if you have to start by being just a little bit agile. And that does not mean adding Scrum Ceremonies into your dev team’s calendar. Agile begins with culture, not with structure. Start by identifying clear business ownership and make sure your dev team has constant access to stakeholders. Shorten the feedback cycles. Introduce inspection and adaptation mechanisms. Make your work more transparent. Remove obstacles and intermediaries. And one day, you will realize you are already doing Scrum.

Using a predefined framework helps a lot for sure. However, when you are in doubt, consult Agile Principles and use your own best judgement. Meet with your team and decide together. Should you or could you apply Scrum or Kanban? Or maybe there is a reason to go your own way?

No matter what approach you choose, remember not to over-specify your process up front. Let your team decide what and how they want to change in the way they work. Inspect and adapt. And then inspect again. Simply try to be agile.