Tommy Norman’s Scrum Fundamentals and Advanced Live Lessons training videos help beginners to understand the basic agile and Scrum concepts.
The videos run more than nine hours, broadly divided between “Scrum Fundamentals” and “Advanced Scrum”. The video sessions use animations to explain the concepts.
“Scrum Fundamentals” provides helpful insight into the history of agile and how agile’s values and principles can inspire teams to consistently deliver high-quality products that immediately add customer value. It covers the complete Scrum framework from project initiation and executing sprints to delivering a product increment. Its topics run as follows:
- the history of agile;
- the roles, artifacts, and events in Scrum;
- how to start a Scrum project;
- essentials of writing good user stories;
- how to maintain your product backlog and release plan;
- agile estimation techniques;
- how to effectively plan for and execute a sprint;
- best practices in agile engineering;
- how to integrate QA into your sprints; and
- how to inspect and adapt your process.
“Advanced Scrum” dives deeply into the implementation and challenges of adopting Scrum, exploring how to apply the values and principles of agile and Scrum to avoid common pitfalls. This section includes:
- agile values and principles concerning requirements management;
- how to craft good user stories and when to get more detail;
- agile values and principles concerning quality assurance;
- how to incorporate good quality practices into your sprints; and
- integrating test cases as part of your requirements management.
InfoQ interviewed Tommy about these video lessons and discussed his viewpoints.
InfoQ: Was there any specific reason to go for a video instead of book? How is it more useful to the audience?
I’ve been teaching and presenting on agile and Scrum for years so taking that content and putting it into the training-video format was a natural progression. I personally feel people get more from in- person training and the video is closer to that medium than a book. I also believe viewers get more out of the training in this format since as I speak, I use quite a bit of animation that illustrates my point and helps drive it home a bit better.
InfoQ: Please elaborate on concept versus mechanisms. How important is it for a team to understand this difference?
Many people who adopt Scrum merely adopt it as a set of rules without really understanding the reasons behind them. Scrum is a framework that is a specific implementation based on the values and principles of agile. In the “Scrum Fundamentals” video, I spend a good amount of time talking about the values, principles, and common concepts in agile. To me, those are some of the most important parts of the training since eventually a team or organization may need to adapt their “rules” for some reason or another, but the underlying values and principles behind those rules should not change.
It is very important to understand the difference when you are adopting any process for your teams. For example, many teams follow the rules for the daily scrum to the letter. They ask the three questions, they keep it under 15 minutes, they hold it at the same time and place every day, etc. but sometimes you find that if you ask some basic questions after that meeting like “What is that team member working on?”, “What are the main impediments for the team right now?”, or “How close are we to our sprint goals?”, you’ll find the team cannot answer them. The value behind the daily scrum is the opportunity for the individuals on the Scrum team to interact face to face and review their plan for the sprint, determine if anyone needs help, and evaluate their progress. If you follow the rules but are not getting that value out of the meeting, then it is a waste of time.
When people blindly follow the rules and are getting little to no value from them, then their adoption usually suffers and they will not get the results they wanted. Often they say that Scrum does not work because they followed the rules exactly and did not succeed. That cargo-culture mindset can ruin the adoption of any process.
If a team truly understands the values and principles they are trying to follow with their Scrum implementation, then they can better evolve their mechanics because they can make intelligent choices of when to adapt to something different. Early in my coaching career, a team struggled with their daily scrums and then decided to go to the “walk the board” approach of reviewing each user story on their sprint task board and seeing what was done, in progress, or impeded. They were not explicitly asking the three questions but they were getting more information from the approach and better adhering to the underlying values. That’s what really matters in my opinion.
InfoQ: A Scrum team starts a project by creating the product vision. What are the properties of a good product vision?
I think giving the team a sense of purpose is very important and it often inspires them to do great work. A product vision is a simple mechanism to communicate that purpose to the team. It is basically a simple business case where you outline the target customer for the solution, how it will help them resolve some issues they have or add value, some of the ways the solution will help the customer at a high level, and how your company will benefit.
I think one of the qualities of a good product vision is that it should be short and sweet. One client of mine said they did not need a product-vision document because they had all the same content in their business-scope document. This was a 50-page Word document stored on a SharePoint server. I went to the team to see who knew what that document was, where it was, and if anyone had read it. No one had. So while the content may very well have been in there somewhere, it was not being communicated to the team and was providing no value in that respect.
I also think that the vision should be inspiring. As I have mentioned before, teams that believe in the purpose behind what they are building often build better solutions. During our on boarding at a previous company, the CEO/owner of the company came in and told the story of how he was inspired to start the company when his daughter was deathly ill and he was constantly observing the poor flow of care in the hospital. You left that session with a great sense of purpose and I know I personally was proud to be part of it and I would go above and beyond to make a great solution.
And lastly, I think the vision should be prominently displayed and often revisited. It is all too easy in our daily grind to lose sight of our actual goal with a solution. I love it when companies find creative ways to display their vision such as documenting it on a main, highly visible wall along with letters of gratitude from customers. I think it should be something leadership should bring up regularly to remind people why they are doing what they are doing and give them that broader sense of purpose.
InfoQ: You mention capturing “how to demo” steps. Can you explain more about this? Can you provide an example?
When writing my first user stories, I would outline the acceptance criteria with simple bullet points like I had been initially taught. It became clear very quickly that we were missing some implicit information that lay between the information in those bullet points. The list described various points of interest in the given feature, but did not really give a clear vision of how they came together to help the user achieve their goal. We were discovering things late in the sprint and sometimes not finishing, or when we did finish, we had to significantly revisit the feature in a subsequent sprint.
I had read about the “how to demo” approach and we decided to try it out. We would work with the product owner and applicable users to describe what they would need to accomplish their goal. It was a high-level use case that was specific in what the user needed but not so detailed as to start becoming more like a static specification. It took some time to get it to the right level of detail but once we started doing this, we immediately saw that we as a team started having a better grasp of the story. We found that we estimated better because we were catching some of the implied requirements earlier, and we usually delivered something closer to what the users actually needed.
We really integrated this into how the team and the product owner discussed a story in grooming sessions. We did lots of white boarding and paper prototyping, and focused more on discussions as the story drew closer to the sprint in which we would implement it. It was important that these “how to demo” steps were seen as negotiable and served as a reminder of our previous conversations, so we could pick it up again when we revisited a story in grooming or planning.
We also found that starting with an abstract story could be hard for the team to get their heads around. We started to use personas more and walked through actual sample scenarios. This helped focus the discussions and made them more tactile to the team. Instead of saying “As a bank account holder I want to withdraw cash so that…,” we had more discussions like “I’m a busy mom rushing to get the kids to their soccer games and need to get cash for the concession stand.” I really liked how this helped the team identify with their users more and start speaking in their voices.
InfoQ: How do you integrate testing practices into requirement-management practices?
Quality should be something that is baked into our entire process for delivering software and that definitely applies to gathering and refining requirements. If we are getting poor user stories then it does not matter how well we are doing in our engineering and testing practices because we would possibly be delivering the wrong thing for the customer.
It all starts with the user story and we must address the quality aspects from the start. That means our QA team members are involved in all the story sessions, grooming, and planning activities with everyone else on the team. Once they are included in those efforts, we must also make sure they actively participate and that our testing concerns and efforts are addressed to the same degree as are those for the construction of the application. All too often, I see the developers and the product owner being the ones primarily engaged in these conversations and QA is not contributing equally. We, as a team, have to make quality a concern for everyone, not just QA.
Acceptance criteria should eventually evolve into test scenarios and the sooner in the process we do that, the better our testing efforts will be. I described the “how to demo” approach to recording acceptance criteria and this approach makes it very easy to convert over to tests since it represents the happy path for the customer. As the team grooms a story, they should pay close attention to acceptance criteria, identifying not only the happy path with the “how to demo”, but alternate and negative paths as well. While the entire team should strive for this, experienced QA team members will naturally start asking questions about these other paths through a feature. If, while discussing a story, one of the acceptance criteria is to import files with contacts in them, I expect QA to start asking questions about what to do when the file location is not accessible, how to handle files I the incorrect format, etc. This can help expose scenarios the product owner and developers may not have initially thought about. The more we do this as I team, the more I find the team starts to think this way as a whole and our user stories start to organically get better.
Usually, once we start working on a user story in a sprint, we convert all the acceptance criteria to tests if we had not done so already. From that point on, instead of referring back to the text in the user story, our conversations now revolve around these test cases. It is important that the entire team do this, especially the product owner. Now we have our acceptance criteria in mechanisms (test cases) that the team can easily use to validate that they have met all the desired functionality. It cuts down on ambiguity, which leads to missed implied requirements, and it also can immediately tell us if we later change the solution and contradict one of these criteria.
InfoQ: How do you manage documentation in agile?
It is a common myth that agile means not doing any documentation. That’s just plain silly. While we prefer face-to-face communication and individual interactions to gather and refine our requirements, eventually we need to record and store this information in its various stages and that often means some form of documentation. With agile, I find that we change our approach when we gather and refine requirements, and according to how much detail we get and when and the techniques we use to manage them.
I also really believe in the concept that there are two types of documentation: input and output. When I’ve experienced the common issues most of us have with documentation, it has been because I am trying to use the same approach for both types of documents. Take a functional specification, for example. We use it early in a traditional waterfall project to gather all the detail about a requirement. This is what we think the user needs and what we think we will implement. This same document is also supposed to be the matter of record after we deliver to show what we actually did deliver. Since most projects of any complexity experience changes to requirements, I now have to put serious overhead into our requirements management to keep this single document updated when something changes. The more formal and comprehensive this document is initially, the more friction there is when it has to change.
When we apply the concept of using different approaches for our input documents than we use for our output documents, we can explore some better practices that reduce this friction and waste. User stories are great way for recording and managing requirements as input. They are fairly lightweight, focused, and meant to be easily changed. The product backlog is a great mechanism for managing user stories that have yet to be implemented. User stories in a product backlog are not a great way to manage our output information. Once you implement a user story, it has served its purpose and should be discarded. This concept can really blow your mind if you are used to the more traditional way of gathering requirements, but it makes total sense in agile environments.
Output documentation should reflect what was actually delivered and there are some better ways to gather and create this type of documentation than the initial user stories. If we are converting our acceptance criteria to test cases as part of our process then those tests actually become the most accurate representation of how the system works. If we are diligent about regression testing then this is even more true since these tests will be frequently validated. We can then use these tests to pull content for more formal documentation such as a functional specification if you require one. Depending on the tools you are using, you may actually be able to export this test data directly into some form of documentation and save your team a great deal of time. This can also allow you to update documentation easily after changes have been made to the system since the tests will have to be updated as part of that process. Other output documentation that may require more manual effort can be part of your definition of done at the sprint and release levels to ensure they are being created as an intrinsic part of your software delivery rather than just being something you do late in the cycle.
InfoQ: You mentioned that the role of QA changes in agile teams. Could you elaborate?
QA has all too often been seen as something that happens in a relative silo and at the end of a waterfall project. I see QA team members treated as second-class citizens in an organization and their efforts to ensure quality often compromised. I believe this is due in part to the cooperative nature of waterfall projects versus the more collaborative nature of agile projects.
Cooperation is about individuals striving for their own goals and sharing relevant information. Think about the developer whose goal is to write code to meet a specification. He may or may not be aware of the overall business goal and primarily focuses on how he can best do his own particular part of the overall process. Collaboration is about all the team members having a shared goal and there is often a sharing of responsibilities to some extent. For example, in Scrum, the team spends around 10% of each sprint assisting the product owner with product-backlog refinement. This is the team sharing in the responsibility for gathering and refining requirements, which may traditionally been seen as something a business analyst would do on their own in the analysis phase of a project.
With collaboration in mind, our QA team members will participate in all aspects of the software delivery cycle and not just testing at the end. They will help refine requirements. They will be involved in applicable design discussions that affect the resulting solution. They will include other team members in their own testing efforts. For those used to operating in their own little silo on other projects, this can be quite a change. I have found it takes people with a true mind for quality rather than those that just think they are there to find bugs.
InfoQ: Do you plan to do more on agile?
I will admit that the jump from presenting this material live before an audience to the more structured format of this videos was harder than I thought. There is quite a bit more preparation and rigor in the implementation. Both videos were great learning experiences and I am definitely open to making more. I do think I want to explore ways to capture the live training experience better and I like what Bryan Beecham did with his TDD videos that were taped versions of his workshops. I really liked diving into a topic deeper like we did in the second video and I am thinking about other areas of Scrum and agile I think we can explore further. It’s not a matter of if, but just a matter of when.
About the Author
Tommy Norman is the Agile Practice Lead at the Holland Square Group in Nashville, TN. For over 20 years he has been helping clients build solutions using both Agile and traditional approaches as a CSM/ CSP (Scrum Alliance), PSM I (Scrum.org), and a 6 year recipient of Microsoft's MVP award in Application Lifecycle Management. His career has spanned roles from infrastructure, software architect, director of software development, QA manager, and Agile coach. Tommy is the coordinator for the Agile Nashville User Group, a contributor to InformIt.com and Safari Books Online, as well as a frequent speaker at regional and national events. He blogs about Agile and ALM at www.tommynorman.com and rambles about most everything on Twitter as@tommynorman.