Agile being a mindset does not dictate any process, procedures, tools, anything. Now, such mindsets do get concrete at some point when people invent tools and frameworks to embody them. This is actually necessary if one wants to leave the realms of philosophy and enter a more tangible world. Using such concretions make it easier for people newer to a subject to start implementing it in their ways of living.
It is important to see those concrete implementation of the ideas behind Agile for what they are, though. They are tools. They are helpers. Anyone who thinks about implementing Agile heard of Scrum. But Scrum is a framework of practices on Agile. It has the daily standup, it has the concept of the Sprint Backlog and the role of a Product Owner. If you want to drill down to the level of engineering practices, many people have heard of at least one or two practices described on XP. Pair Programing is a widespread practice cherished by high performance developers.
Without entering the dilemma of which framework one should be using, it is always worth discussing the fact that certain practices can be adopted alone. It is done either because they bring benefits even if not combined with the source framework but also because teams and organizations can be so peculiar that there is little evident gain about using a pre-made formula (I am not a firm believer Scrum is a solution for everything). It can be also helpful to do so in order to introduce the framework little by little, testing the waters.
The only important rule I find when adopting Agile practices comes from common sense and living in the normal world: know your tool. A company, a team, a person needs to know why they are adopting Scrum or why are they doing daily stand-ups. They need to know why are they supposed to create tests before coding and why they should limit the amount of work and the amount of disturbances for the team before the next delivery. Those things need to be known because they are tools!
If all you have is a hammer, everything is a nail.
This is such an important distinction to make. When people turn to frameworks and practices to save the day they trivialize the meaning of such tools and many times use it wrongly. They also see only the surface, which means the good gains of adopting that tool are simply lost. Then the person will be wondering why the hammer does not work. Well, because a hammer does not glue plastic together. Or because hammering with the nail-remover side will yield some very crooked nailing results.
I can think of some very common examples of misuse in Agile practices.
- Managers attending to a team daily scrum and asking questions about the project(s).
- Having a list of desirable features in a tool accessible to project managers only.
- Giving a team the list of tasks for their sprint.
#1 is easy but still so many examples of bad sessions happen everyday. The daily scrum is a tool for the team in which team mates check how much are they deviating from the objectives of the sprint. They talk about their current commitment, look at the promises made on sprint planning time and reassess. People switch off tasks or gang up to finish something that is proving challenging. Scope can be readjusted as well: simplifying a feature or (rarely) adding some improvements so the feature goes up a next level. A daily scrum is not a status meeting. It is not a place for managers to boss around and is not a place for discussing the future of the project. It is not a meeting for doing general announcements. And most importantly, it is a short, focused meeting. So it is not a place for assigning blame or solving an architectural dilemma.
#2 might not seem so obvious to many people. Scrum has a word for upcoming or desirable features called backlog. I will use this word from then on, even if when not talking about scrum. But what constitutes a backlog? Is it still a backlog if it is hidden from the teams, even unintentionally? No, it is not. For the team to be able to get creative and efficient they need to know the product/project global vision, as well as what are the next ideas coming up for the product. Without this transparency there is a disconnection between what is built now and what is expected next. This becomes avoidable rework. Always remember that because of what the future might bring to the product, certain technical or marketing decisions can and should be different. It is on everybody’s best interest to be transparent about what the intentions are for the product. One might not know about that and that is fine. But knowing and not sharing it is just plain counterproductive.
#3 is about sad times that keep repeating themselves even in somewhat Agile companies. A Product Owner (or sometimes a Project Manager) defined milestones somewhere down to the very details on how a feature is built. Basically a Gantt chart or everyday of the project divided per team members. The only thing I like about Gantt charts lies in the applications that implement them: you can push everything forward when there are dependencies. Other than that, if done for planning, it cannot contain details on when a certain feature, say an API, will release each endpoint, when will CI integration occur and when peer review is to take place. This is blatant micromanagement and it is a setup for failure. And it has nothing to do with rebellion against date setting. It is just that so many things can go wrong on the manufacturing of a feature that one main date is already good enough and it should have a meaning that is organizational, such as a date in which all integration should be done or the production deployment date. That is why it is called a milestone. It defines big, important stretches between which all other stuff happens. This “other stuff” is basically the ability of a team to shuffle their work and find solutions to the main problem and other minor problems that will arise in between. Setting other minor dates over stresses everybody because being late on these minor dates is not a predictor for missing the milestone, but it might make everybody panic like so. It is also important to notice that a team knows best how to breakdown their work. Having a list of features can make sense for a Product Owner. How to break that down does not. And the list of features has to be acknowledged by the team and a commitment to deliver it also comes from the team. When people are involved in decisions about their own work buy-off is a almost instant.
The next time you hear someone adopting a new framework or tool, if you want to help them, ask them questions on why and how they intend to use it. Let them realize not everything is a nail and that a varied toolbox is much better suited to help solving a palette of problems than just a hammer. Likewise, if they clearly have a nail in their hands, no need to get overly creative and search too far: old plain hammer it is.
Pingback: A few words on story points - All Things Agile.ca