The video lesson Scrum fundamentals by Tommy Norman is a downloadable training which gives an introduction to agile software development using Scrum.
In the lesson Tommy explains all the basics from Scrum like the roles, artifacts, and events, and explains how they can be used by teams. He also provides insight into the history of agile and the agile values and principles.
InfoQ interviewed Tommy about why he made this introduction training, the roles, artifacts and events of Scrum, User Stories and collaboration in teams, and on-line resources where people can learn more about agile.
InfoQ: What made you decide to make this video training on agile and Scrum? Why an introduction training?
Tommy: I’ve been training and coaching teams on Agile and Scrum for around 8 years now and I really enjoy it. The thought had been lurking in the back of my mind to put together some instructional videos for some time so when Pearson approached me I jumped at the chance. While an instructor-led class is one of the best ways to learn, that is not always an option and I think the way the Live Lessons videos are structured makes them very appealing. Lyssa Adkins and Jason Little had already done some great videos on Agile coaching and fostering change, so I wanted to get back to the basics with an introductory Scrum video. I run the Nashville Agile User Group and we have many attendees who are new to Agile and really want a solid understanding of the fundamentals of Agile values and principles and how to implement those using the Scrum framework.
InfoQ: In the video you talk about the roles, artifact and events of Scrum. What makes them so important?
Tommy: Every introductory Scrum lesson covers the roles, artifacts, and events prescribed in the Scrum Guide since they are so prominent in how people think of the framework. I tried to make sure that when I covered them I relayed how they each map to the underlying values and principles of Agile. It’s important to not just follow the mechanics, but to really understand why you are following them so that you can elegantly evolve during your Agile transition. All too often I’ve seen a team blindly adopt some element of Scrum and while they may have implemented it exactly, they may not be getting as much value out of it. For example, I see teams hold Daily Scrums where they have it in the same place and time, keep it under 15 minutes, and answer the three questions but when you ask the team members after the meeting how close they are to their sprints goals or who needs help, they have no clue. It is supposed to be a self-management tool that provides daily feedback loops among the team, but it is very easy to simply adopt the mechanics and not realize it is not providing real value. I also think it is important to cover these items in depth so that people do not simply equate them to traditional software development elements and project their assumptions onto them. I constantly hear things like “a Scrum Master is just another name for a Project Manager, right?”
InfoQ: What is your favorite agile event? Why?
Tommy: My favorite Agile event is the retrospective. To me, Agile is all about embracing change and striving to continuously improve, which I believe is what the retrospective is all about. When we had our ‘lessons learned’ meetings at the end of traditional, waterfall projects we rarely really changed anything. It always seemed like we complained about certain aspects of the project and just went right into the same approach on the next one. I love it when a team brings up something they would like to improve, really gets to the root of the problem, and then collectively formulates a plan to change moving forward. The hard thing is to keep everyone positive since it is too easy to concentrate on only the negative. When you execute it in a way that stresses improvement, then this can be one of the most constructive team events in my opinion.
InfoQ: Teams sometimes have difficulties to write good User Stories. Can you give some advice on how to do it?
Tommy: It’s important to remember that User Stories are a tool for Agile requirements management that reflect the principles of customer collaboration, delivering software frequently, and embracing change even late in development. The format of the story starts with the “role” which should represent the end user. Each story should aim at solving a customer’s specific problem and adding value with the acceptance criteria outlining how it can meet the customer’s needs. Some more traditional techniques seem to concentrate more on implementation.
In addition to trying to solve a specific customer problem, you should also strive to provide the simplest solution possible. Small, thinly sliced stories allow teams to deliver valuable functionality in short feedback loops. That way you can get critical customer feedback quickly and adjust accordingly. Users often have a problem dealing with the abstract and lengthy; narrative requirements documents may sound good in theory but it is not until they get their hands on working software that they really understand how it works and what they would change.
When you work from a prioritized backlog of these small, user focused stories, you can spend more time on gathering detail about those items that are going to be delivered imminently and have less detail about those farther down on the backlog (and therefore less valuable). When you do gather these details it is done collaboratively with the team so that there is less need for comprehensive documentation. This approach can allow you to makes changes very close to implementation without a great deal of overhead around updating documents and keeping the team abreast of these changes.
InfoQ: Can you also share your ideas on prioritizing User Stories? How can you determine the value of a User Story?
Tommy: As I previously mentioned, each story should strive to solve a specific customer problem. If you can clearly illustrate that, then it becomes a little easier to gauge the value of one story over another. This can be very hard since it is often like asking a parent which child do you love more. The business naturally wants everything all at once and it is hard to shift to an approach that forces you to make these hard decisions. I point out in the video that there are a few things that can help determine the “value” of a story and thereby dictate its priority on the backlog.
One is its outright business value which is an indicator of how much revenue or cost savings the story might provide when implemented. Couple that with the team’s high-level estimate of a story and you can also get a fairly simple calculation of Return on Investment which might point out low hanging fruit the team can implement for a quick win. Risk is another factor in that sometimes you may want to attempt a story with an unproven technology or feature early on. This way you can allot a small, acceptable amount of the team’s time to prove a concept before devoting a more serious investment. There is also the ever-present and less tangible influence of politics. We should strive to always be putting customers first and prioritize based on value, but in the real world sometimes we fall prey to the goals of individuals. There can be positive examples of this such as pushing a feature higher on the backlog for a loyal beta customer who is very involved in providing product feedback.
All of the items above can provide input to a Product Owner when prioritizing their backlog. Making that backlog very visible to the business stakeholders and being able to provide a high- level release plan to help clearly show them how the priority affects forecasted delivery, can be a very powerful tool for gauging the value of your user stories.
InfoQ: The daily Scrum helps the team to collaborate, see their progress and find out what is blocking them. What can teams do to do it effectively?
Tommy: I am a huge fan of visualizing your work using some type of task board. I mentioned earlier that I’ve seen teams struggle to get value from their standup meetings and using a board is always a good technique to get the team focused on meeting their Sprint goals rather than simply justifying their existence. A task board helps the team give context to their answers to the “three questions”. They move an item from “In Progress” to “Done” for what they worked on yesterday, and another item from “To Do” to “In Progress” for what they are working on today. There can be a separate lane (my preference) or some other visualization (like a magnet with a stop sign) for tasks that are blocked. That way all the team members can clearly see how each other’s efforts are contributing to their overall progress towards their stories which they committed to for the Sprint. When you step back and take a look at the entire task board you can also gain some critical insight into the team’s progress such as seeing that they may have too many stories in progress at a given time or that they have started work on lower priority items. To me the task board is an integral part of Scrum, but all too often teams do not use them and have difficulties tracking their progress effectively.
InfoQ: Daily stand up sometimes take too long to finish. What can teams do to prevent that?
Tommy: I mentioned the task board which is a good tool to keep the team focused on goals, rather than details. The team needs to understand that this meeting is a quick planning mechanism that can also provide a good deal of transparency to external stakeholders. When the meeting gets bogged down in details, other team members and attendees start to become disengaged. The smart phones comes out or they start side conversations which can subvert the meeting quickly. The team should respect the rules of the meeting, but it can seem very confrontational to call someone out. In the past I’ve had the team outline their rules for the meeting and post them in the meeting room so that when someone needs to be prompted to move along, it is not so much a confrontation with an individual, as it is the team enforcing rules they themselves agreed upon. I used to use the phrase, “Don’t tell me about the pregnancy, just show me the baby” as a way to prod us along with a bit of humor. The team quickly latched onto it, cutting it down to just “Show me the baby!” that I have to admit was sometimes used on me.
InfoQ: Are there any on-line resources that you recommend to teams that are new to agile? Which ones are useful for more experienced teams?
Tommy: It is almost trite now, but anyone interested in Agile should read and study the values and principles of the Agile Manifesto. They have become a staple of any presentation on the topic but now are often reduced to a simple talking point. The first company where I experienced Scrum mainly concentrated on the mechanics and we did not really understand the values and principles. It was not a very successful adoption initially and I came away thinking that Agile was the inmates running the asylum. I then had the good fortune to work at a company that just organically embodied those values and it was very eye-opening.
Once you have a good understanding of the Agile values, then I would read the Scrum Guide at Scrum.org to get familiar with the elements of that framework. It is a short, concise document that is easy to consume. When you read it, make sure to connect the dots between the implementation of Scrum and the Agile principles behind its mechanics. I would also recommend reading “Scrum and XP from the Trenches” by Henrik Kniberg, which I think does a good job of illustrating how one team applied Agile’s values using both Scrum and Extreme Programming.
For those with more experience I would suggest getting involved with your local Agile community. Most cities have a user group focused on Agile, Scrum, Lean, etc. and frequently engaging face to face with other practitioners is a great way to get new ideas and share your own insight. I especially like those groups that focus more on group discussions based on topics determined by the attendees such as Lean Coffee or something similar. Online you can participate in some long standing forums that have deep communities that often include some very prominent Agile thought leaders.
About the Interviewee
Tommy Norman is a Senior Consultant with Holland Square Group leading their Agile Solutions group. For over 17 years he has been helping clients build solutions using both Agile and traditional approaches as a Certified Scrum Master / Professional (CSM/CSP), Professional Scrum Master (PSM I), as well as a Microsoft ALM MVP. Tommy is a coordinator for the Nashville Agile User Group, one of the original founders of the DevLink Technical Conference, a past president and board member of the Nashville .NET User Group, and a frequent speaker at both local and national events. He blogs about Agile, TFS, and .NET and rambles about most everything on Twitter as @tommynorman. When not working he enjoys being at home with his family of 5, playing guitar, and music.
