ISSUE #4 - APRIL 5, 2022
Making agile frameworks work for your team
What are the most common reasons agile frameworks do not work as expected? How can you make agile frameworks work for your team? What is the right agile framework for your team?
Since their conception, agile frameworks have been a big point of discussion in product communities. They radically changed the way software was delivered, creating whole new roles within product teams, as well as whole new markets. Today, there are various courses and certifications available for product people. In essence, agile frameworks like Scrum, Kanban or other variations of them look like straightforward recipes that were created to help teams to improve their reaction to market changes, increase their development speed, as well as the collaboration within the team.
Yet, I have rarely seen teams following those frameworks “by the book” (which is not bad). Or even if they do, they are not working as smooth as they would expect. And there are good reasons for that. It is one thing to try and apply the principles of each framework within the context of your team and a whole other thing to make this work for you. Teams end up being frustrated, since the frameworks that were supposed to help them solve their workflow problems, end up creating more friction. Team leaders start iterating using different frameworks in their effort to make the framework work, but quite often that does not work as well.
The goal of this post is not to shed more light on the principles of those frameworks. There are millions of resources available that cover this. The questions answered in the next parts are:
- What are the most common reasons agile frameworks do not work?
- How to make agile frameworks work for your team?
- Is there a right framework for my team? If yes, which one is it?
Common reasons agile frameworks do not work
Imagine that: Your team’s backlog is full. There is chaos all around and people do not know from which task they should start. The pressure for delivery is immense. The team is frustrated and you need to find a solution as soon as possible. So, you come up with the magic phrase: “Let’s use Scrum” (or Kanban or whatever else). Problem solved? It is not that easy.
There are no “one-size fits all” solutions
As I said earlier in this post, there is a good reason that teams do not follow agile frameworks by the book. Each team has its own special traits and consists of different people. Even within the same company there are massive differences in the way teams are working. And it makes sense. Each part of the product is different. Consequently, the problems faced by each team and their nature are different. The people and the characters in the teams are different too. So, the solutions that work for each team are different. As a result, it makes sense that many times frameworks are not followed by the book. The teams needs to make adjustments to make them work, solving their own special problems.
Wrong expectations & impatience
You have to understand that there is no magic wand and the perfect solution will not be the first one that you will use. The team has to understand this as well. Much like a product, fully optimizing your team’s workflow takes time and needs various iterations. In the vast majority of the cases, the first iterations will not work well. You are going to need to iterate and then iterate again and again. Until you reach a point where what you have works well for your team. Time, patience and persistence is what it takes.
Lack of a clear owner to the process
More often than not, teams start their journey of agile transformation and the product lead or the tech lead is the person embracing and pushing this process. Guess what happens then though. As with anybody else in the team, day to day kicks in and that person will pay more attention to their daily tasks. The result? Nobody is there to take care of the team workflow’s optimization and keep the team accountable. Naturally, the team is getting complacent and getting back to their old habits.
Lack of team buy-in
Unless your team is onboard with what you are doing, they will never embrace this. Obviously, it is quite rare to have full consensus from the team. If there is a big enough number of people though, that are not engaged with the adoption of the process, failure is almost guaranteed.
How to make agile frameworks work for your team
So, we went over some of the most common reasons that teams fail to successfully adopt agile practices. This list is by no means exhaustive, it highlights though some very frequent cases. Making agile frameworks work for you team is a process by itself. There are certain steps that need to be taken.
Understand your team’s inefficiencies
You need to be able to deeply understand and prioritize your team’s problems, so that you can pick the right solution for you. This must be very specific. Think about what your team is not doing well at the moment and what is the impact. Are you failing to release good products? What is finally released is not what has been initially planned? Are priorities constantly changing and this is creating chaos? Are the forecasts of the team inaccurate? Are the specs not clear enough? Is the team understanding well what has been asked of them? Is the plan clear to the team?
Those are only some examples of things that might be going wrong. It is important that aside from your perception of the problem, you involve the team into this. Talk with each member of the team and ask for their honest opinion about the matter. What do they think that could be improved? What makes their lives harder every single day? At the end, create a list of the biggest problems, prioritized. Remember, you cannot solve all problems at once.
Ask for help from people with knowledge and experience
As mentioned, there are various certifications or courses that product leaders can take. And it is great to have a good understanding of those frameworks as a product leader, but this is not your job. If you want your team's agile journey to succeed, you need to ask for help from someone with experience and knowledge who will be solely focused on this. And the name of that person is the “agile coach”.
Once you find this person, you need to sit together and analyze the team’s problems (remember the previous step). Let them observe the team and the way it operates before you jump to thinking about solutions. Sit together and set clear goals, on what you are trying to achieve.
Then, jump into discussing what would be the best place to start from. Maybe radical changes are not necessary. Only small tweaks to begin with. The responsibilities of this person would be:
- To coach the team on agile methodologies.
- Constantly help the team optimize its workflow.
- Train the team on the agile process and keep the team accountable as far as the process is concerned and finally.
- Encourage the team’s and the management's buy-in in the process (we will further talk about this later on the post).
A common push-back that I’ve observed to this, is that an agile coach would not be a good idea, since “the team is too small and it would not be a full time role”. This is a valid concern, but there is a clear solution to that. Most often, agile coaches are working on a part-time or on a contract basis with the team. Or at least, this is how it all begins. It is reasonable, since you might no longer need an agile coach with the team, once the team has adjusted. In spite of that, my opinion is that the agile coach should remain with the team to oversee the process in the long term.
Another common argument against that is that “we can easily replace the agile coach by the product owner or the tech lead. They could be acting as the agile coach”. To my experience, this has never worked and it is also silly. The role of your product owner or the tech lead’s role is not to coach your team on agile methodologies. They are getting paid to think what and how should be built. They are obviously important stakeholders in optimizing the team’s workflow, but they are in no way the people that should be acting as the agile coaches.
Get your team’s buy-in to the process
This is critical in order to give your team the best possible chance of succeeding. You need a critical mass of your team to believe in what you are doing and what you are trying to achieve. This needs to be at least 75% of your team. If you manage to get the buy-in of the vast majority of your team, even if there are still people that are not engaged with the process, they can be influenced by the rest of the team.
But how to achieve that? As mentioned earlier, involve your team in this from the early steps. Ask for their opinion about the team’s problems. Once you come up with a few potential solutions, ask for their take on the matter. Do they think this would work? Are there any better ideas? They need to feel that this is something of their own (and this is actually the case). Also, set the right expectations. The team needs to understand that this will take time and iterations. In case you are working with an agile coach, their help on this is of paramount importance.
Iterate, Iterate, Iterate
Last, keep in mind that most probably you will constantly need to iterate. Do not be afraid to make major changes. Remember, the goal is to find something that will work for your team. It does not matter if you do things completely different from how things are described in the text books. Your agile coach should also be fine with this and actually embrace it. The goal is to find the best possible working framework for your team and achieve your team’s goals. Not succeed in some kind of agile exam.
What is the right agile framework for my team?
Moving towards the end of this post, that is “the million dollar question”. As you must have surely understood by now, there is not a straight answer to that. However, I can share my experience on where you should start building from, depending on your team’s circumstances. This is an oversimplification though.
Selecting an agile framework, is influenced by various factors. Those include the maturity of the company and the product, as well as the market circumstances and the team’s comfort with the product.
Usually, in immature environments, such as early stage startups, the team is relatively new. The team's ability to accurately forecast is not great, because its knowledge of the tech stack is usually not deep and extensive. Priorities are quickly changing since the company is probably still in the process of finding a product-market fit or simply market circumstances are changing fast. In those cases, I have come to observe that frameworks based on Kanban or some mix of Kanban with Scrum work better. It is a bit more flexible, which bodes well with the team, since there are no hard requirements in roles. Especially Kanban, emphasizes on improving the work which is currently in progress, while at the same time limiting your work in progress. Also, it has much more continuous feedback loops which are way more helpful under those circumstances.
In more mature environments, where things are a bit more predictable and market changes along with the priorities are not changing that rapidly, Scrum or variations of it, seem to be working better.
But again, the above is an oversimplification and should be used only as a starting basis. No matter where you start from, Scrum or Kanban or something else, the important thing is to be diligent and commited to your process and its optimization. Keep iterating until you find what is actually working for you. Remember that having a process, even if it is a bad one, is better than not having process at all.
For example, in his book, Konstantinos Giamalis, describes a fully custom framework which he and his team developed in order to address their challenges. They started from more traditional frameworks and the evolution is what they now call “Nero”. What I find most interesting in this book, is the iteration framework they used to optimize the team’s workflow and come up with a custom process. Many of those ideas have been also mentioned in this post.
Last, one of my favorite quotes is “people over processes”. So, make sure that whenever you are trying to optimize your team’s workflow and processes, the people always come first. A process should always serve the purpose of the people and not the other way around. A process in which people are not feeling comfortable with, is not a good process, no matter how effective it might look on paper.
Past Newsletters
ISSUE #3 - MARCH 1, 2022
Breaking into product management
How can someone become a product manager? Is a software engineering background necessary? What are the fundamental skills that make a great..
ISSUE #2 - FEBRUARY 2, 2022
The challenge of delegating
Advice for managers on when, what and how to delegate effectively. Avoid frustration, subpar deliverables and missed deadlines.
ISSUE #1 - JANUARY 4, 2022
My year in books
Read through my reviews of the books that I read during the past year. Some of them are "must-reads", some of them I trash. The topics vary across..
The Product Notebook by Manos Kyr.
Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.
Latest Newsletters
ISSUE #25
What to do when you don't know what to do next
ISSUE #24
When good docs go bad: Learning from a PM's misstep
Copyright © Manos Kyriakakis