[Transcript]
How can we work productively in teams, without constantly bothering each other about what it is we should be working on, and how we should go about doing it? Management wants regular updates and to constantly change what it is they expect of each individual contributor, but individual contributors just want to work without being bothered. We need to interact, update each other, and remain flexible so that we can consider new ideas, while also being allowed to keep our heads down and focus without distraction. So how do we both manage and produce when the two seem to be at odds with one another? This is what we call Agile, also known as Scrum.
My name is Shaun McMillan and this is the Best Class Ever.
Back in the 1980s the big American car manufacturers could not produce a decent small car to compete with Toyota. Toyota consistently produced high quality small cars at extremely small cost. America eventually had to throw out their entire process, and learn from the Japanese. Since then we have adapted what we learned from the Japanese to produce not only better manufacturing, but also better software.
Agile, also known more specifically as SCRUM, is the method or framework which software developers use to take the feedback they collect from users to determine what modification and features their teams of engineers will build into the product.
We call it SCRUM in reference to a bizarre looking feature of the sport, rugby, in which every player, even those from opposing teams, lean in, put their heads together, and embrace one another in a competition to reach the ball at the center.
Values of SCRUM
There are four values that are critical to making Agile work. Respect, deliberation, transparency, and shared accountability.
- Respect is important because in any given team you will have to three to nine members. Each might be an expert in their different domain and each is equally responsible for delivering value to the users.
- Deliberation is important because the team is small enough that each voice can be heard and have a say in what they think the team should work on and how they should do it. A consensus should be reached, not dictated.
- For every teammate to be able to make informed decisions, transparency is critical. Everyone must have access to the critical information, and the more visually accessible that information is the better.
- Shared Accountability means each individual contributor on the team answers to every other and shares responsibility for the final deliverable.
We’ll get into the various different stages of SCRUM in the next lesson, but for today let’s look at User Stories, the backlog, and how to use Kanban boards to visualize our work.
User Stories
A user story is any feedback collected from the users. If we build a game for the classroom, we might get a complaint from a teacher that the website menu is too hard to find, and we might get a request from a student who likes our game to add a mute button. These would be two different user stories. In the first the user is a teacher, and in the second the user is a student. Both are requesting features be changed or added to the software.
Over the course of testing the product and once it reaches the open market, we will inevitably have an abundance of requests for new features. Upper management might request we add features that allow us to monetize or increase revenues. Users will complain as soon as they find something is not working. Or they may request features that are easy to implement, extremely difficult to implement, or completely at odds with other more critical features of our product. We cannot make every change that we come up with or is suggested to us by all the various stakeholders.
For this reason we must keep a list, or a backlog, of all the possible changes we could work on if we chose to. But ultimately we must rank order this list to determine which changes we will make priority, which we will delay until later, and which ones we will choose not to do at all.
This list is constantly updated as user feedback comes in, but we cannot constantly change what we are working on. So the entire team will meet and decide which of these user stories we are going to implement for the next one to three weeks, also known as a sprint. Once we decide what is important enough to work, we will work on those features until they are done. Then and only then will we have a full length meeting to present the new version of the product. Until we can deliver an update that we can test with users and collect feedback on we will focus on getting the work we have agreed to do done.
But we will have a short 15 minute standing meeting at the beginning of each day to share what we accomplished the day before and what we will do today to achieve the sprint’s product goal. If anyone has anything keeping them or blocking them from getting their work done, it will be mentioned in this brief meeting. We call this SCRUM a standing meeting because no one is allowed to sit and get comfortable. The meeting should not take more than 15 minutes.
Kanban boards
My favorite part of SCRUM is Kanban boards. Kanban boards are a simple way to visualize all of the work being done. Every user story is turned into a notecard or if we are using a digital kanban we turn it into a board which looks like a small card. Every card is placed one above the other into 4 different vertically stacked columns.
Backlog
The first and longest column is the Backlog column. This is where every possible feature or task we could do is placed. Then the product owner or the teammate tasked with choosing what work takes priority rank orders the list of tasks putting the ones that will provide the most value to the most users at the very top. Tasks that should be ignored fall to the bottom.
Doing
The second column is DOING. Duringthe Sprint Planning meeting the team will decide which user stories to take from the backlog and place them into the DOING column. During the sprint each teammate will work on and complete each and every one of those user stories.
Done
As each one feature gets implemented it will move it to the third column which we call, “Done.” Moving the cards across the columns allows every teammate to see how much progress the team is making and to feel the satisfaction of getting things done.
Once every card in the Doing column is removed and placed into the Done column, we can then meet again with all of the stakeholders to present the new version of the product and collect feedback.
Once that feedback is processed we can begin another Sprint to add more features or decide the next goal for updating our product.
Velocity
Another really great feature of Agile is called Velocity. Tracking your velocity allows your team to know how much work you can get done sustainably over the course of each sprint, and project how much work you can take on in future sprints.
The way it works is you assign each user story or task a label of either easy, medium, or difficult. Or another way is you can assign story points. We would give 3 story points to an easy task, but maybe 21 to a difficult task. Then over the course of tracking how many points you achieve each week, you’ll be able to project into the future how many tasks you are likely to achieve in future sprints.
After 3 consecutive weeks of using kanban boards, evaluating how many difficult, medium, and easy tasks you can take on, and working together to discuss what work you will do, how you will do it, and by holding standing meetings each day, you will see that suddenly work is getting done, and everyone can see it. This level of transparency, collaboration, and shared responsibility will do wonders for your production capabilities. Agile is one of those frameworks that might not sound that impressive, but is much more impressive when you see it in practice. Even if you don’t work in a team, but work alone on a project, you would be impressed how much it helps to use kanban boards and to think in terms of sprints.
And don’t forget, at the end of each sprint, to take some time to rest and reflect on what you have achieved. See if you can’t collect some feedback before diving back into the production process.
In the next lesson we’ll discuss the actual roles that teammates can take on, and we’ll discuss in more detail the different stages of a SCRUM.
To see what a kanban board looks like and for more resources on Agile and SCRUM, feel free to visit www.BestClassEver.org.
