When an organization decides to adopt Agile it is tempting to select a framework and put it in place without reworking the company’s mindset. It is not uncommon to organize teams around a Sprint, have Daily Stand-ups and control the work on a Kanban board and still do not reap the benefits of Agile.
Before blaming Agile or the framework being used, here are a few pitfalls to learn from when considering using any Agile implementation within the the organizational context.
1 – Resource Planning
One important aspect of Agile is the fundamental role played by the team. In every company we can have a different setup, but no matter what it is, the team is the “indivisible” unit of allocation. One should refrain from getting all worked up on Gantt charts with every team member weekly working hours, including vacation days and holidays. This information is certainly useful, but we should avoid planning for person A to take tasks of one project, person B take tasks of another project and in the end the team is actually a collection of people working in unrelated tasks that just so happen to sit together. They will not be able to unblock each other (because they will be out of context), share tasks or understand the daily standup, work together through deadlines (because who is going to risk their own dates to help a peer in trouble?), much less commit to a common goal (because there is nothing in common). Plus, people are not “resources” they are individuals. A server, a car, paper are resources.
While there can be some remote reason to adopt such an approach, for the most part let a team work together in a shareable assignment and let them break down the tasks and organize themselves on a finer grained level and humanize their job. Otherwise there is just too much micromanagement and no sense of unity in the team.
2 – Too much work
Also known as Limit Work in Progress (WIP), this mistake is many times associated with #1 Resource Planning. When people work detached from their team members or for some other reason a team ends up dealing with a lot of different topics to cover they will probably end-up context switching, not finishing one or more items and just work overall less focused. If this is Lean, this team has no flow. If this is Scrum, this is a badly selected team or a badly planned Sprint, in which no clear goal was set.
What those two frameworks are saying (and so do many other Agile frameworks) is that unless the very nature of the work of a team is extremely diverse (such as in customer or technology first and second level support teams) do not make things harder for the team. Giving the a clear goal makes everybody’s creativity and skills work with focus, thus achieving better results. Confusion, lack of focus and context switching are waste; it increases complexity and create a lot of daily impediments that would otherwise not be there in the first place.
Divide and conquer works better when we all know what we are trying to achieve/accomplish.
3 – Non-negotiable estimates
If someone in your company is using this terminology, we spotted another common mistake. Another common mistake on the other end of the spectrum is to be upset, shocked or have some other emotional reaction to wrong estimates.
Estimate: roughly calculate or judge the value, number, quantity, or extent of.
Approximate. Guess.
Some people and sometimes entire organizations seem to think estimates are something accurate. They use the word “guesstimate” trying to simplify estimates without realizing it is a big redundancy; or sometimes they rely on the number of hours, sprints or whichever unit of measure that is given as an estimate as if this was a golden number, impossible to be wrong. Imagine the triangle of Scope | Quality | Time. Imagine something has to give. Since Quality should be uncompromising, you guess where the adjustments lie. In time spent doing things.
Although people can learn to be more accurate around their own work, estimates are a guideline, not a universal truth. They allows for teams to situate themselves when sizing functionalities to build. They are not supposed to be immutable nor an element of pressure against a team.
4 – Optimizing too soon
Many people like to refer to phenomenal examples of Agile put in place like those of Spotify, but many forget the hard work that company employed and the unique path their teams and leadership used to reach their current place. Plus, the company started small, grew, and tried to keep the same startup mentality during its growth, so it is not like a company with a few thousands employees just decided to become like that.
The Spotify model is not simple and neither are many models for Agile at scale. They take into account the journey a company’s culture take while growing and becoming more Agile. They can start from a simple Kanban adoption and grow to an impressive framework but it has to:
1 – shape up according to each company’s true needs and culture
2 – start simple. Use some Kanban or Scrum among the delivering teams while at the same time working the leadership to have an empowering, enabler approach.
Anyone could put forth a revised version of Scrum, but before deciding to cut out a Scrum Master and having overlapping Sprints, how about trying the tool as is first? After all, those are empirical models, extremely simple and by using and adjusting one can have a better idea of what will be really required.
These are just a few of the issues I have observed easily in companies trying to adopt Agile and they are by no means the only ones. When planning an Agile transition a company should observe itself, its people, its culture as a whole, and decide on a gradual transformation that suits their own needs.
note: I use a lot of great free image content from Getty Images and Unsplash and I recommend you check them out!
