My experience with Scrum

byJose Cortes

For the last 6 years, in the major part of my projects I used scrum in many ways and variations. I will write down my conclusions, maybe right, maybe not, but they are mine 🙂

First of all, I won’t say Scrum will solve all the team-product problems, as it won’t. Processes involving people and creativity are – in a natural way – potentially problematic. But also amazing! In my opinion, being as direct to the point as possible in all the stages of the Scrum and paying attention to the strengths and weaknesses of the team are essential . Not being able to achieve these means that no methodology will be possible (call it Scrum, Kanban or whatever amazing new approach appears).

The Daily Meeting:

What did you do yesterday? What are you going to do today? Any blocker?

Some people complains about the utility of the Daily meeting due to reasons such as:  people show up late, other people don’t say anything at all – and other do not stop talking -, other talk to the Scrum Master instead of the Team…and, because of that, the conclusion is that Scrum is not useful. Disagree. The Daily meeting works well to create a high-level communication of the state of the work and features. And, as many other methodologies, implies commitment by the team. Some people are inside their comfort zone just writing code -nothing against that- but, in order to make things work, some team vision will be necessary for each member of the team, without exceptions!dailystandupmeeting-300x225

In some cases, I can hear the argument that the Daily is like a way of justifying the work that you were doing. If the Daily meeting smells like that, then a problem (not Scrum) is on the air: maybe hidden micromanagement, maybe some team conflicts…Daily is not the way to show how good someone is or to measure how productive are the members of the team. Is a tool for them.

There are some natural problems that pop up during the Daily meeting. They are not making Scrum useless but if not solved in a proper way they will. For example, discussing technical or specific details that are not urgent for the rest of the team (warning! do not miss urgent vs important!) can make the Daily a big waste of time. Also, common ego-battles can be very problematic, as it can dramatically lower the moral of the whole team. Let’s make the daily as short as possible and grab our 9 am coffee! 🙂

The whole scrum:

Some people argues that Scrum can be a distraction for the project goal. Well, in my opinion, that’s partially true. But it is a price to pay for reaching the goals. For example, some days scrum (such as Daily meetings) are more useful than others, totally agree. But, in my opinion, it will take more time to decide everyday if all the members agree to do the Daily or not. It is possible to shorten it, make it simpler – we know that urgent things pop up constantly- but it should be there. Otherwise, not doing it at all, will start to create divergencies between knowledge and opinions inside the team.

In some cases, we cannot rate in an realistic way the task we should perform and it cannot fit well inside our sprints: it is very complex, huge task hard to split into subtasks…whatever. But well, punctual problems shouldn’t be the major force to change the whole methodology, as all the approaches will have such exceptions. If you are inside a team and you say something like: “this task cannot be realistically achieved in less than 6 months”, and the team agrees, then the problem is not the methodology, is a task that creates a critical problem for the project (and maybe the whole company!).

Management areas:

Scrum  is not only part of the IT area (or development departments, to be more specific). It implies a commitmenscrum-principlest together with the management or decisive areas. The easiest way to understand it is the fact that the Input (call it requirements) and Output (call it The Product) to/from the Scrum team will strongly depend on the decisions coming from such areas. Weak management, lack of decision, doubts and chaos will change the requirements (and the formally known as Definition of Done), the priorities, the deadlines…in such cases, Scrum won’t save the product, but (as far as I know) no any other methodology will. So it is important that all the team to be on the same page to have a healthy communication and mitigate the risks and change managements in a happy way. Scrum is specially good to changing environments!

The team:

In my opinion, the team can have different level of experience (Juniors and Seniors) and different areas of expertise (let’s call it Design, Security, Architecture…). It is OK, different backgrounds can provide different points of view what is very positive for the project . In my years working in different teams as a Team Lead, Scrum Master, Product Owner and Developer what I found is that there are two major team-destroying things: Lazy (and Non-committed People) and Individualists. And, in my opinion, it will destroy the whole team. Why? The first specie of people will make the rest of the team to feel annoyed, break the team identity, to make them not feel comfortable to work together with someone without the same enthusiasm (warning! do not miss unexperienced or Junior person with Non-committed! In my experience Junior developers were some of the most motivated and committed members!). In the best case, the Team itself will remove these profiles from the Team.
The second specie, Individualists, can also be as dangerous or even more than the first one. In the best way, they just do not collaborate too much with the team but they try to do their best, what can be OK. In other cases,  for whatever reason, they feel like they are above the team (maybe they have more experience or knowledge) and they hardly accept constructive critics. They want to have the last word of the conversations (specially technical ones), they need to show their technical muscle and constantly create conflicts inside the team. In resume (quote from Barry Turner) the goal is to build: “great teams of people, not teams of great people”.

In whatever case, the problem won’t be changing the methodology, but understanding the real problems and make tunings as needed (maybe having a nice talk with the conflictive members or performing changes in some of the processes will be enough). I strongly believe that it is always possible to find a peaceful solution for all these!

So, this is a small simplification of my vision and experience about Scrum, I will keep an eye to newest methodologies and let’s continue learning! 🙂

 android, iOS, Scrum.

 Comments Off on My experience with Scrum

About Jose Cortes

Jose Cortes

Ingeniero informático, emprendedor apasionado en las tecnologías de movilidad, aplicaciones móviles y mobile marketing


Comments are closed.