Agile Development – Do Not do List
written by gunther gerlach-2011
This is a list of the most common mistakes that I have seen again and again along my career in small and large corporations in their intention of implement Agile as the primary development process. I hope while you are reading this, help you to understand what is the logic behind every single practice and try to adapt (shape) to fit into your environment. Remember, the goal is not just follow the best practices but to achieve the goals behind each one.
Read more…
Daily Scrums
The goal: The goal of the daily scrums is to allow each developer or SDE to speak up “face-to-face” to each other not only the progress that is having in an incremental but also, the planned work and blockers (if they exist). Because a blocker could be anything from unavailable resources to lack of knowledge about the work that needs to be done, Engineers need to have a secure environment where they can speak not only freely but also comfortable.
I have witnessed in multiple occasions where Directors, GMs and other influence people try to intervene in the Scrum process by letting external people to attend this daily stand-up meetings, from other group’s managers to indirect PGMs/PdMs, etc. Sometimes also inviting multiples groups to run the scrum together (Devs and QA teams). The problems with this model are several;
· Time Consuming; A large number of individuals in an scrum team make the stand-up so long that even if the team focus on answering the three basic questions, this will take more than half an hour or more. Over time, if a daily stand-up take more than 15 min, make individuals to lose interest but more important for you, you are losing a precious time from your resources every day.
· Honestly; When Engineers have to face other outside of their own groups, they tend to step back with whatever comment that may negatively impact the team, keeping important insights out of discussions. An engineer will never tell publicly if he/she doesn’t have the knowledge to accept or reject work when others “piers” are present. This is a competitive environment and everyone will do their best to look good, even when this will impact the overall performance.
· Fear; Engineers will tell to their direct manager or piers when something is wrong and somehow will impact the project but, they will never be that honest with an executive in the room or present during the scrum. Engineers don’t see a GM or Sr. director as another Engineer but as a God that is impossible to say no. I have seen multiple times when Engineers just keep their thoughts and chose do not speak during the scrum because they fear to this executives being present during the scrums.
· Pre-Scrum; sometimes, the scrums become so large in numbers that independent groups start preparing what they are going to say during the stand-up by a pre scrum meeting…can you imagine the waste of resources every day? Furthermore, do you realized that the fundamental “core” goal of the scrum is lost in this process? Engineers should be able to speak freely and to everyone what is happening and not filter this information in a pre-scrum meeting. Also, the idea of this quick stand-up is also save time and hundreds of email with communication during the day, but in this scenario, nothing of that is happening.
So, How Can We Make it Work!
There are a number of small processes that we can follow to make the daily scrum not just operational but also constructive and goal oriented. Some of these are based in common sense but other requires a Strong Program Manager (not easy to find…).
Scrum by team not by project: Let teams to meet independently for the daily scrum and DO NOT try to mix them with other teams because you are breaking multiple Agile rules like; simplicity, short stand up, trust against unknown participants, confidence in front of other people, etc. Developers need to feel confortable and more important in a protected enviroment. You as a PGM have to protect this or you will lose your advantage.
When teams are mixed by projects, what happened is that daily Scrum become inefficient after the number of participants grows out of control, the number of trends being discussed also grows but most important, become useless for some participants of the scrum. You have to keep this meeting as short as possible and the number of people attending this, needs to be controlled.
pizza team: Keep the size of each team in pizza teams to allow easy and quick stand-ups. Pizza team is a concept that basically defines the number of people that you can feed with a pizza (4 to 6). So, keeping this in mind, try to get the team to be in this size and so the scrum.
goal oriented: Remember, the scrum are efficient is the subjects being discussed are not only accurate and related with the daily work but also, everyone is aware of what is in the table. To do this, simple keep the team organized and focused on the three basic questions;
1. What did I do yesterday? à successes? If not, why and what was done in instead?
2. What do I have for today? à what else do I have if this activity become blocked?
3. What is blocking me? à PGM needs to be alert of this and take immediate actions!
once a day: DO NOT allow team members to have additional meetings to cover what is supposed to be part of the scrum. It is common practice that in some companies, managers and developers want to have a quick sync-up before the scrum to “agree” on the message that is about to be sent during the scrum. This is just wrong! The core goal of the daily scrum is that each one of the developers will face each other to show their progress and also bring any possible issue on the table avoiding bureaucracy and making the process more agile.
reduce audience: Do NOT allow people that doesn’t belong to the team or have no value to participate on the scrum. It is important to keep it small and flexible. Small tams move faster among the questions and answers. Small teams also are more productive (Star-Up class) and friendly. So, as a PGM your responsibility needs to be make this clear for everyone and not just say it but enforce it!
