Recently I read the amazing book To Kill a Mockingbird by Harper Lee. I strongly recommend the book if you didn’t have the change to read it before.
One of the main characters, the father, Atticus Finch, in a particular moment of the story, says to his daughter “that he was defending a Negro by the name of Tom Robinson. […] There are some people who say I shouldn’t defend him”.
Then his daughter asks: “If you shouldn’t be defendin’ him, then why are you doin’ it?” And the father answers: “For a number of reasons[…] The main one is, if I didn’t I couldn’t hold up my head in town, I couldn’t even represent this county in legislature, I couldn’t even tell you or Jem (her brother) not to do something again.”
What amazes me the most is the strong personality of the father to defend the right thing, even before his own good.
If you are reading this, you may think that agile is more than just a methodology, it’s a unique way to build a self-organized team. However, there are many different ways to use agile wrong, to use it just for your own good. In fact, sometimes using correctly agile will create different opinions around you and you will probably face situations to stop doing things in the way you are doing them, just because the others say so.
The agile principles are outstanding and there are some amazing examples out there that show us how possible it is to build over them. But if the teams don’t commit in the way they are supposed to, or even if they keep or use some other techniques that are actually opposite to the agile principles, it’s like going deeply into the dark side, trying to use the force in a bad way.
I’d like to share in this article some ideas to recognize if we are killing agile in a way. Here we go:
1. Being “agile” over being a team
You certainly know that agile is not the goal, it is just a path to allow teams to delivery continuously better solutions with a constant pace. And that is absolutely right, agile must be something to help us to deliver better software (IT solutions) in every iteration. And if it doesn’t help us, we should recognize there is something we are not doing well. Maybe we need to try to understand better the principles and the values. Maybe we need to improve the collaboration among the team members. Maybe we need to stop using a specific technique to find patterns and try to break them to grow properly.
In some teams, running the events are even more important than the content the teams could share on them. Or even closing the sprint is over the quality of the functionalities delivered. In all those cases, we should inspect and adapt in the very next sprint. The Scrum Master must be focused on these patterns and try to coach the team in the events to point out those potential problems.
2. Tools and processes over collaboration
Being agile is not about using a specific application. There is a great world out there, beyond all the “project management” and “track and release” applications. If you hear from someone of the team they need a particular tool to be agile, we either have lost our way or we have never catchaught it before.
There are many different ways to fail trying to be agile. The most common one, I think has to do with this. At the end it is the easy solution you can provide a team: if you are using the application, you must be agile. And that is something actually opposite to the values of the Agile Manifesto, more specifically, the very first agile value says: Individuals and interactions over processes and tools.
I am not saying the team shouldn’t use a particular tool. I’m going further. I am saying the team should be mature enough before creating a very complex structure to organize the sprints and the tasks in progress. Using the application is a thing and being agile is a different one.
Obviously, if we use those apps properly, they will boost our collaboration and help the team’s proactivity. But again, be careful with this.
Simplify the way of using the applications in case you see your team struggles more than expected with them.
One of the most dangerous things in agile happens when we don’t really understand the client collaboration. However, there is even a bigger problem: division among the team. When the team takes a decision after considering all the possibilities, after hearing all the team members, and then they all decide how to proceed, and someone from the team doesn’t fully engage to pursue that goal.
That could happen almost in every sprint with designs and implementations, but that could also apply to the agile culture within the company.
If agile help us with something is with the idea of going all together, the idea of sharing a playground to achieve success together, the idea to inspect and adapt as a team to keep improving along the way. Besides respecting each other, agile helps us to support our team, to change our goals for the goals of the team, to think of the sprint as the objective of the whole team, not just as my list of tasks. The more united we are, the better. Team members can actually start sharing initiatives and ideas finding support on their colleagues.
If we translate this in a most positive way, we can say, being agile means knowing someone else got your back.
To avoid division, try to be transparent with your team, try to spend all the time it is possible to spend sharing different points of view and asking everyone how they would solve it. Who else than someone from the team knows better what could be the solution? But don’t run crazy. Commit anyway to the common goal and let the team itself to find improvements with retrospectives, even for those potential divisions.
Do you find any other way To Kill an Agile Bird ?