Talking about Scrum trainings, I will be clear, I don’t like generic workshops, yes I understand that most of them try to transmit the message and purpose of the different roles, events and artifacts, etc… but I believe that workshops need to be prepared according to the industry and day to day of the assistants, I understand that for open trainings this is difficult because people might come from a big variety of industries, but when this is done internally or for a specific team then no excuses, it should be prepared according to the work and day to day of a team, no pizzas, paper boats or similar.
I feel proud of the result of a workshop that myself with my colleague Francisco Cobos prepared together.
Why I share this?
If you read twitter, blogs, etc… it’s full of people doing successful workshops, but no one actually shares the content and structure, I won’t be saying we had a successful workshop without sharing the content and structure, so this is what I will do, share the content and structure, like one work mate says… “Walk the Talk” 🙂
So the following Scrum training was designed for 3 teams with a Product Owner, Software and QA engineers, each training was done separately for each team.
Work In Advance.
Before the training, we had to prepare some things to make it valuable and successful.
We identified that in the office where those teams work there is a book library, and the process to take take a book home is by fulfilling a sheet with your name, the name of the book, etc… so it’s basically a bureaucratic and manual process, so we decided that we would be building an actual product “A Booking Management Tool” that would make this process much better and increase its potential, so we would be doing this while explaining the Scrum Framework.
Each team will be coding, would be doing software! so we needed to prepare some stuff in advance, we created a new repository for each team that contained and skeleton of an app that was showing a hello word, a hello world that was retrieved from a table in a DDBB, each team had it’s own DDBB, so we would avoid problems with the team sharing the same DDBB, each team has it’s own and they were free to do whatever they wanted.
The goal was that the day 1 before starting anything everyone should be able to pull their team repository, run a command and be able to hit http://localhost:8080 and see a hello world on the screen, that would mean the team was ready to start with the workshop.
All work areas ready, with the needed materials to be able to create the visual boards, with its tasks, even a very simple user story map that we used to explain something while we were creating a product backlog (I will explain later)
We also created a Scrum Presentation, a powerpoint with some key points for each event, roles and artifacts, nothing too deep as we wanted to explain everything better while doing the workshop, but we needed to set some context so that’s why we created a presentation we used the first day.
The presentation also contained key points around the need of technical excellence for achieving agility, mentioning the DORA report. and some XP practices among other things.
During the first part of the morning we hosted a presentation with everyone together, we went through the key points of the framework, the events, roles and artifacts, people could ask anything at any moment, we tried to engage as much as possible, we knew that would be hard and most the people would be just listening, at the end, this was the “bored” part of the workshop… but we had to do it because we needed to set the stage and set some expectations.
As said before, this presentation also covered and acknowledge key points on technical excellence and the DORA report.
During the afternoon is when workshops started wit each team individually, we were 3 trainers and we divided everyone into 3 groups.
The first thing we did was to set the working area, we basically wanted to make sure everyone was feeling comfortable at their desks, that they had all that they needed, laptops, etc.
We then created the visual board in the wall, here is when we explained why is important to create physical work areas with visual boards, why is useful for the team and at the end what are the benefits, we did not use Jira at all, we did not need that, we just created the board the team would use with the basic To Do, In Progress, Done (something the team would change later). I like to use the team-first approach, the priority is to make always things useful and valuable for the team.
DoR and DoD
We were explicit the DoR is not part of the framework, but we are currently using it so it was part of the workshop.
So, next to the board we added 2 papers, one for the DoR and one for the DoD, we of course explained and talked about them, we then created our first versions, those definitions are the ones we would use during the workshop.
We then started with the product backlog supported by a user story map, so the team could at least get some context about what a source of new user stories could be, during this exercise I was playing the role of a customer and together we created a couple of more user stories till we completed the given story map with already a pre-defined backbone. Here you have the templated we used.
During this moment we also talked about roles, it’s important to talk about the expectations of the dev team and the PO when it comes to creating PBIs.
Sprint Planning and Sprint Backlog.
The workshop continued by our first Sprint Planning, again, we talked about the roles and what to expect from them during this event, we went through the planning with the result of having our first forecast and our first sprint backlog
Time to get things done!
Once the Sprint Planning ended the team started coding, well, actually not immediately, the first thing they asked was how they were supposed to organize themselves, I told them that this was up to them, that the PO in short only cares about the value delivered (ideally represented in the User Story), how they would achieve it was up to them, if they wanted to create more post-its then fine, my point here was that they are a cross-functional team and together they should be able to achieve the work as a team.
What they did at the end was to create some post-its to organize themselves the work each of them would do.
Day 2 was mostly coding, but with 2 daily scrums and one refinement scheduled.
The first thing we did in the morning was a checkpoint about what we covered during day one, I went through the roles, sprint planning, product backlog, sprint backlog, user story…, I took the chance to have an engaged conversation with the team and see what were their understanding and perception of the topics that were covered so far, this was useful for me as a trainer to detect knowledge gaps.
The first daily scrum was not really a daily scrum, I explained the purpose of it and the different expectations for each role, etc… it’s crucial they understand properly to avoid confusion, after that they performed one.
During the morning they asked if they could update the board by adding a new column, I asked what column they think was missing (I could imagine which one was), and indeed, the missing column was “In QA”, here where I talked about a cross-functional team, the role of the QA and how it works in practice, at the end what we did was to add a swimlane under the in-progress column that was called QA, the team understood that “In Progress” Includes everything, and would make sense to have it that way.
After lunch we did another daily scrum, this time was interesting because some of them mentioned that they did not have any work to do, it was interesting because the done column was empty, can you imagine what happened? Yes the QA swimlane had a couple of user stories, here is where again we talked about what it means to be cross-functional, how the expectations of the team changes in the new context, etc… they understood that makes sense to help each other and the people who did not have any more work to do (stuff to code) started to help the QA.
After 2 hours the team actually finished everything, so it was fair that they wanted to do more, I could see how the Library Management Tool was already quite functional, they even added a lot of stuff that the PO did not ask (something I will talk when we cover the Sprint Review)
We did a refinement, basically, we together created a couple of more user stories that we added into the story map, so at this point I could explain and put in practice the difference between a Sprint Planning and a Refinement.
This was the day of the Review and Retrospective, so the way we scheduled it was by having a Daily Scrum soon as they arrived to the office, Sprint Review before lunch, and Retrospective after lunch.
Again, a new checkpoint about the topics covered so far, including the ones from the first and second day, we clarified questions & concerns.
This time the Daily Scrum was much better, I did not have to talk at all, they just did and that’s it, the only thing I said at the end was that time of the Sprint Review so they could prepare it.
Sprint Review & Increment.
As a trainer I did some pre-work here, during the workshop I saw how the team did much more than what the user stories and story map represented, so I asked the “customer” to acknowledge this, I asked him to show some surprise during the review about he none expected features.
During the Sprint Review, the product owner is who talked more, but the whole team was involved, so we inspected the increment all together, we used the Library Management Tool, adding some books, booking books… we asked the customer to use the tool by himself so he started to give feedback, positive and not so positive.
From one side he was very happy with the tool, we identified some new things the team would work in the next sprint, so we added some “draft” user stories to the backlog so the PO could start working on it and finalize them in the refinement with the rest of the team.
In the other side was the “none expected” work, so the message to the team was actually not a bad one of course, but we wanted to make the point that while we value their ideas and engagement, we are here to deliver what the customer is expecting to get, all ideas are welcome, ideas we can share with the customer, actually the Sprint Review is a good time for sharing those ideas, and if they have to be added into the Product Backlog because are valuable ideas then they will, we need to be careful with this, we should not create new functionalities just because we feel like.
We finished the Sprint Review celebrating the success, a completely functional library management tool! And a happy customer who was so happy to pay for the increment he got.
After lunch we started the retro, this retrospective was a bit special, because in this case the sprint was the actual training, so it was a retrospective about the whole thing.
The first thing I wanted was to start with some fun, some laughs so I asked the team to name the sprint with a movie name, so the team gave some names that made them laugh, my goal here was to change a bit the mood and set the stage.
Then we started with the retro, the model I used was an easy one, it was a timeline with 2 areas, a horizontal line where the area above was for whatever made the tam happy, excited, feel good, new learnings… and the part below was for their concerns and difficult situations or experiences during the sprint. We got and reviewed the feedback and with my some help they came up with a couple of action points.
Post Training Questioner
We wanted to get qualitative feedback about the training, we did not know exactly how to do it, we did not want just a range of smiley faces or scores, we wanted to see how people understood the framework, and the only way to know this is by asking them to elaborate on some scenarios.
We prepared a set of situations where each of the situations was explicitly related to each of the roles, events and artifacts, for example, the one for the Daily Scrum was something like this:
“You are a developer, and in the middle of the Daily Scrum the PO starts asking question about the progress of the work and when it will be finished, the PO also decided to include a new task into the Sprint Backlog without really asking, as developer working with the Scrum Framework what are your thoughts on this situation?”
This way of getting feedback is of course more longer for the people as they need to elaborate, but we decided to do it that way because we really needed to see how people perceived the framework, and we needed to identify the knowledge gaps for clarifying”
This is all, I hope you think like me that this way of showing and practicing Scrum is much more effective, the teams though that it was a very good way to practice the framework, so it was not too bored for them, we really enjoyed!