Analogies are ubiquitous in the business narrative – it adds drama and color to a fairly drab exterior. No narrative is more popular now than using sports analogies (war analogies are so 2007.) This fans of the oval ball will know that this athlete trope is epitomized in rugby, which essentially consists of walls of tough burly men crashing into other walls of tough burly men in an over-glorified game of fetch. The definition of toughness is displayed in the rugby Scrum. It’s the biggest players on the team, men somewhere between 100-145kg of stacked muscle and sheer determination, shoulder to shoulder, literally clashing head-on with the opposing team. Here’s a close up of some rugby thighs, with a human head for scale:
Sourced from rocky writes about rugby, but found everywhere online.
Our Scrum, while agile and impressive, is not to be taken literally, as in rugby. That’s just silly, as we’ll injure our guys needlessly. Also, we’re nowhere near 100kg or 200cm tall (except for that one guy, who actually plays rugby). Which begs the question then:
Agile Scrum is a framework to communicate effectively with members of a team. That sounds a bit drab now, but we promise, there’s plenty of drama involved. Like rugby, we’re talking quick bursts of skill, determination, and teamwork to move the ball down the line. It follows the Agile Manifesto, which recognizes that workflow does not depend on one thing leading to the next. Projects are formidable opponents and are never cooperative or agreeable. Agile creators recognize this issue with project work, there are always unforeseen circumstances that delay the project. This could be anything from urgent requests, change of scope, the office catching fire, and/or earthquakes. Something is bound to happen. Murphy’s law dictates that it almost always does.
Circa 2017. Author Unkown. Found on GravityIT.
Project managers who think and organize in terms of dependent tasks (i.e, step 1 must happen before 2, then 2 must happen before 3) are essentially shooting themselves in the foot. There’s a better way to organize and even conceptualize making it happen. Once you understand that dependent thinking is just one paradigm, just one way of viewing things, it’s fatal flaw becomes obvious: if one thing goes wrong then everything does. So, don’t shoot yourself in the foot. The logic in this thinking has inherent risks, meaning you’re handicapped before you start. And you make agility impossible.
You become the not-so-mythical Sisyphus, punished by Zeus for his self-aggrandizing and hubristic cleverness by being forced to roll an immense boulder up a hill only for it to roll down when it nears the top, repeating this action for eternity. There’s another metaphor for you. Agile prevents that by having constant iterations – breaking that boulder down. Each iteration is a sprint, no longer than four weeks. At Mäd we use two-week sprints as we try to release twice a month. No one likes a Sisy(phus.)
Scrum and Zeus have strict rules to follow, for good reason. The framework has been tested and proven. The wise (ahem, Mäd) relies on empirical evidence to deliver the best and most viable product in the shortest amount of time. Agile does not focus on a perfect product, but the minimum viable product (MVP – agile metaphors, we’re back on sports again!) The MVP starts with core features, then is constantly improved sprint by sprint.
We use sprints for development and design work, but the Agile framework is useful for building any complex product, anything from building a hydroponic garden in the backyard to comprehensive health care reform. We’re going to be discussing it in terms of development work for this insight, with the players first, because the quality of your scrum reflects the quality of the team. Once more for the people in the back; Scrum quality = team quality. Who’s in your Scrum definitely matters.
The Scrum framework follows a strict set of rules which initially feels a little heavy. This quickly becomes routine and streamlines the processes, so don’t sweat if it feels a little complex right now. Like rugby, your players have different roles in the Scrum, and each one is crucial. Let’s see who these players are:
Of the same breed as a Project Manager, the Product Owner’s main role is to deliver value to our clients. They are also responsible for communicating what the clients require and prioritize accordingly. In our terms, the Product Owner is the client’s go-to person/point-of-contact, allowing the team members to concentrate on their jobs and cut out some of the noise.
This player is a solid communicator and able to break down behemoths into bite size. Mastery of these skills means that every player on the team knows what they need to do, and has a clear idea of how to deliver value to the client. Typically, documentation for features and client requirements will come from the Product Owner, to be passed to the Scrum. They function as the squawk box and filter, fluent in high-level business strategy as well as the gritty technical details needed to program applications.
The Product Owner must be available at all times if there are any questions regarding the feature from the team. They know every play and need to be able to coordinate the team at a moments notice. This player isn’t supposed to sleep.
In rugby, this is usually the player that goes head-on against the opposing team (read: the project.) The Scrum Master in Agile manages the team and breaks down user stories into features and tasks. While the Product Owner is like the team coach, working for the club’s board of many stakeholders, the Scrum Master is the captain of the team. They are on the pitch, too. Regardless of being in a rugby scrum or Agile Scrum, this player needs to have a big brain and a thick skull.
The Scrum Master is also responsible for holding sprint meetings to allocate tasks to the right person for the job. The Scrum Master is quite literally the one right in the middle of the Scrum directing the daily stand-up meetings. While most Scrum Masters will do development themselves, their main role is to make sure that everybody is on track. In some Scrum teams, the Scrum Master makes sure that the dev team follows coding standards religiously and reviews the code before delivery.
These guys are the ones doing the dirty work, finishing each sprint with blood and dirt on their hands. Most of the time it’s pretty sweaty too, depending if the air-conditioning is working or not. We’ve lost some team members due to heart failures and the survivors boast cauliflower ears from the occasional banging of heads on walls. At Mäd, we wear red shirts so you can’t see the blood.
The dev team makes up the rest of the Scrum. Outside of developers, however, designers and quality assurance team members can belong to the Scrum. This, of course, depends on the processes and culture of your business.
All in all, there are only three roles in Scrum: the Product Owner, the Scrum Master, and Developers. All these individuals follow strict rules and events to make sure that the Scrum works and the product is worthy enough to put in a museum.
There are many events in Scrum to ensure the sprint is smooooooth. We aim for a Scrum without hiccups, resembling a furiously astounding New Zealand haka dance (if you don’t know what it is, please Google it. You’ll be a better person for knowing it.) Throttled by devotion, a skilled Scrum team enjoys regular champagne baths as they complete their bite-sized, well-organized tasks on time, beyond expectation and constantly delivering value. Way better than pushing a boulder that never gets where it needs to go. Let’s talk about Scrum events.
To many Scrummers, this is one of the most taxing parts: the planning. For most Scrum teams, planning may take up to an entire day. This is not an exaggeration. Still, the more planning you do, the better the end result.
The purpose of the sprint meeting is to allocate the right task to the right person. During the meeting, the team breaks down the user stories into tasks, as small as possible, allowing the best estimate for hours to complete the task as accurately as possible. Note the detail involved: tiny tasks, clear ownership, down to half-hour breakdowns: sprints. Once you have an achievable measure of success, you can run like hell. Massive, endless projects on the other hand, constantly push success beyond the cognitive horizon. You never get there, you burn out, and there are no champagne baths. Unlike the Waterfall methodology, Agile Scrum allows for dedicated and mindful precision, which translates into hard value for our clients.
The daily stand-up meeting is the heart of the Scrum. The development team will each have to answer three questions:
- What did you do yesterday?
- What are you doing today?
- And, what is blocking you?
You’re probably wondering, do they have to literally stand up? Yes, rightly so.
Now you’re probably wondering what complex and high-tech reason there is for this. There isn’t one.
The main reason why team members stand up is to keep the meetings short. Everyone we know has attended meetings that really should have been an email. The daily habit of focusing on those three questions, quickly, and if there are any impediments, quickly, has an awesome result: everyone has a crystal clear understanding of the project’s status, always. And for those of you who actually run projects, you’ll know what a sweet sweet rarity that is.
The Scrum Master takes the reins of the stand-up meeting, but if he/she is not present, the dev team still has to run the daily stand-ups.
After each sprint, the team needs to huddle together again and see the damage. This is true for both rugby, design, and development. The review examines the tasks which were completed as well as tasks which were left incomplete. Some tasks may have been completed early. And for the ones which failed, then the team needs to see whether there was anything blocking the completion, or whether they assigned the right person for the task. Keep in mind that our sprints are two weeks long, twice a month. Rapid diagnostics help us understand how to plan and work as a team better, so we’re improving every two weeks.
In Mäd, we usually hold the sprint retrospective with the sprint review, as they go together hand in hand. The retrospective reviews the actual process of the scrum, and see where there is room for improvement. Be mindful that in summary, scrum is a framework, not a methodology. It is important to find a way to fit scrum to your business and more importantly, your culture.
Scrum artifacts are things you need to do the work: the tools the team use, the documentation, the “tangibles.” Artifacts exist in the Scrum to keep everybody in check, to improve transparency and making sure that tasks are distributed in a clear and fair manner.
Scrum without artifacts is having the cake right in front of you, but no spoon to eat it with. Every craftsperson needs their tools. You can use your hands (or Excel spreadsheets) and it will be messy. Half of the cake is probably going to end up on the floor. So you need these to get going.
The Product Owner (aka, the coach) is responsible for:
- Updating the product backlog
- Prioritizing features which will add value to the entire product
- Making sure that the backlog is available
- The content is as clear to the team as possible
- That the order is appropriate
The product backlog breaks down the user stories into features, which the development team then turns into tasks. It’s the Rosetta Stone between the development team and clients. During the sprint meeting, the team decides on the best approach, as the Product Owner focuses the team on priorities with the user stories and the acceptance criteria. Overall, it’s a dynamic roadmap to success, but where the terrain is constantly changing.
Working with clients, it is super important to make sure that they approve the feature with the right details so that the team can proceed to estimate the time it takes to complete the feature. Usually, once clients approve the feature the development team will take it to the sprint. Any changes to requirements to the feature will affect the sprint and will be pushed to the following sprint.
The moral of the story? Get everything right from the start.
So once we know the requirements, the priorities, smaller tasks, and the user stories, everything that the dev team selected from the product backlog goes to the sprint backlog. The plan is set into rapid motion. Sprint backlog items are usually little tickets that go in a software like JIRA, or in our case, Team Visual Studio, where devs responsible for the task shift the tasks depending on the progress. Remember that each task will have the number of hours depending on how many hours are required to complete the task.
Developers will spend a lot of energy during the sprint, they will be sweating uncontrollably, especially in South East Asia. Our HQ goes through about 15 liters of coffee a day to fuel these sprints. Therefore, it is important to measure how many calories they actually burn for the sake of the sprint.
As much as people dislike charts and graphs, the clearest indicator of whether the sprint is on track or not is the burndown chart. (Also, we’re the kind of people that really like charts and graphs.) At any given time, stakeholders and managers can see how much time remains, how many more tasks to complete and as we mentioned, the real-time progress. Real-time updates, all the time. It is up to the development team to make sure that they update their tasks regularly to make sure that transparency is maintained. This goes back to our daily stand-up meetings and review process. Again, meticulous details, and mad amounts of data.
Simply put, an increment is a releasable product at the end of the sprint. That’s really about it. But in that simplicity is hard results: an awesome new feature up and running in two weeks time, with the team smarter and faster at the end of it. And that’s pretty damn cool.
Ideally, the increment should be available for public release at the end of the sprint. For this to happen, all members of the scrum need to acknowledge that the increment passes their Definition of Done. This is what separates a Scrum team from a chum team. The increment depends on to the qualities that the team members attribute it to. Each scrum will have a different definition of success, so the better your team, the better your increment.
In our dev sprints, an increment is DONE when:
- The code complies with Mäd coding standards and passes code review by the Scrum Master
- The internal team completes internal testing of the application with complete functionality of the test cases
- The client QA team approves the increment in the UAT
“Done” is where Scrum starts – begin with the end in mind. “Done” establishes the standards as well as expectations of the team. The higher the requirement for “Done”, the better the end result will be. Our teams set the “Done” bar very high for a good reason: it creates a killer set of players, tough burly sprinters, stacked with brains and sheer determination, standing shoulder to shoulder every day, running at full tilt towards success. We run stats like professional teams. We train for matches, the tougher the better. It’s blood and sweat to gain territory, constantly. And we never, ever stop. It’s a real Mäd team. And definitely the guys you’d want on your side of the pitch, not against.