Continue looking for it at allthingsagile.ca!
One of the pillars of Agility is to iterate. What I like about it is that you can iterate about almost anything. Your thoughts, your practices. And why not over tools and frameworks that we talk about and sometimes use (and misuse), such as Scrum?
Scrum is pretty simple in its essence. So simple that one must pay attention not to get lost on accessory tools that the community built around it. All very nice and useful. All NOT a must-have, though. So, forget about poker planning, Scrum boards, Jira. Forget about how big should team be, how long should iterations be. Let’s revisit what Ken Schwaber and Jeff Sutherland shared as empiric knowledge that came to be named Scrum. The major reference for it till this day still is the scrum guide, no matter how many cute, funny or structured tools and communities appear enhancing the subject. This post, like many others, is just a helper on understanding what is defined as Scrum by its creators.
- a Team (with Roles);
- some Events (sometimes called Ceremonies);
- a Backlog (Scope of work);
- and work a cycle called Sprint.
It is easy to remember those basic items when one thinks that a team must come together to deliver work periodically.
How big should the team be? How small? How varied? What skills should they posses? So many questions arise in the community, notably among novice adopters. Not to say they are not relevant, the answer lies in understanding what is a team from the perspective of Scrum. The team is composed by a group of doers, a cheerleader and a business-tuned worker. As simplistic as this might sound, that is my interpretation on the 3 roles found within a team, ideally all separate, but let us not get ahead of ourselves.
The Development Team
The doers, the worker, are called the Development Team. Those are the people who perform the actual work, the masters of the implementation of whatever is it that is needed. Those people are as generalists or as specialized as needed by a project or company and it is important to form a team having in mind they should be self-organized, independent, self-sufficient. Those people should have in their hand all, or almost all, power to deliver whatever is needed in their scope of work. When we think about software development, as a whole, the team should know or be in position to learn and use any technology in order to produce their software, API, application or whatever in the end of a cycle. These people are accountable by whatever the results may be. A big sense of ownership and accountability is required, so teams must be formed in an atmosphere that allows for this to happen.
The Scrum Master
The Cheerleader is the Scrum Master. I like this allegory because this is a very humane, fine tuned and very peculiar role. A cheerleader gives all her energy to the team. She devotes herself in trying to make the team raise to the challenge without being able to get in the field and play. The Scrum Master is observant of Scrum within the team and the organization. She is someone who makes sure Scrum is understood by the team members, practiced by the teams, by the managers. A great Scrum Master eventually gets useless as the team progresses into full self-management and Scrum knowledge. She will then work more on evangelizing other spheres of the company that might still pose challenges to the self-organized teams, coach the management layers, try and create a change-positive environment. In a much ideal scenario, she will then flee once “her work is done”. Now, in the reality, the challenges are way too many and the Scrum Master is more than just a Scrum warrior. This role belongs to someone who will spend her time helping the team to gain focus, taking in her hands activities that overwhelm the team, help the Product Owner in maximizing backlog value and find innovative ways for everybody to practice Agility. The Scrum Master (or group of Scrum Masters) is paramount in shaping the company’s outlook in Agility overall. She brings understanding to all levels of the organization and equalizes ways of work throughout the company, helps teams to increase their productivity, in short, she is a full change catalyst. It should be pretty clear that a Scrum Master is not an “Agile Project Manager”, whatever the latter might be. She is not someone preparing status reports, she is someone coaching or mentoring people and communicating with everybody. Being neither a manager nor acting on an interest of a project but on that of the team, this somewhat common definition could not be farther from the true nature and value of a Scrum Master.
The Product Owner
The Business-oriented person of the team is the Product Owner (the PO). He is a champion of the market in which the product (or product-to-be) is inserted. He understands what brings high value, what is a good timeline for features, what is enough or too much as far as the deliverables go. He is also the person who decides when a deliverable is ready to go. With Scrum a team delivers on iterations. Without this important way of working a team cannot be called a scrum team. But when working iteratively a team always gets a chance to improve a feature. To add or remove something, including on the looks or the UX. The PO can then test his expectations either alone with his own knowledge or with Beta users, or just by accepting the feature so it makes it to the market timely and can gather quickly feedback of real users, pioneering in its sector, as it happens with many startups. A good PO works with his team in sharing what is the vision of the product, what is and what is not part of the scope. The PO should refine his understanding with the team regularly so everybody know what to implement and he produces a backlog that is accessible to everybody and that gets improved / detailed with the whole team. It is also the PO who sets the tone for the Sprints and decide, given the important feedback of the team, what are the features that should be worked on, as far as priorities go.
Those are the only roles recognized under Scrum, but they are all that is needed in this simple to grasp yet difficult to master framework.
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 you only have 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 plain old 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.
Agile is a mindset. It does not mandate processes. It is not prescriptive. Neither are many of the tools that are commonly associated to it. Neither is Lean, another mindset mistakenly named as Agile, whose boundaries continue to fade and fusion, at least in the software world.
Agile aims for simplicity and focusing on objectives rather than the process to get there. It is supposed to bring freedom and focus as it shortens the feedback loop and looks for no blame but the next step or alternatives. In that sense, Agile strives for reducing complexity of any problem. Traditionally on a software context, where it was born, but expandable to other fields if you remember to use only the essentials. Agile is about getting iterating and increment.Evolving a product. Think on a bike that became a motorcycle. Think about a carriage that transformed into cars and how cars have been transforming since the first unit by Karl Benz in 1886. In software you recognize them from XP and Scrum.
Lean looks for reducing waste and keeping a state of flow. In commoners language, we do only what is required, that we know is required and keep the focus in completing that before taking on a new challenge. Think about how a house is built. You have foundation, framing and slowly fill in layers until you can turn on a light and move into it. Several layers added to a same final product. Even though it was born on engineering/assembly lines, much of it applies to software. In this you might have heard of Kanban.
Lean and Agile approaches are complimentary. None is about being imprecise, hasty or incomplete. Both are about placing stepping stones, making informed decisions based on what you know now.
I would argue the purple intersection is much bigger, almost eclipsing the differences, which I do believe lie mostly in details; they are not irreconcilable.
Again, it is not uncommon to see references that blurry the lines of this intersection. For intellectual and learning purposes it is always good to remember the boundaries, but once they are learned and applied they shift our mindset and introduce tools that are more often than not compatible (Kanban board vs Scrum board anyone?). And that is why I find their differences can become less relevant.
That is what I mean by Agile. What do you mean by Agile?