Christmas is gone but I have a gift to you, a rather small one, but as it happens with almost anything in life, great things come in small packages (cof cof cof) . I’ll write about some small improvements I’ve done before that actually helped my teams a lot in finding their path and maintaining a sustainable pace.
Sometimes it is not easy to make big changes in a team, but you can do small things that will tailor the way they work and slowly will guide them in their Agile journey.
So, let us start small and make our great teams a little better. :)
1- Scripting the Scrum Events
A good thing I learned from a fellow coach was to keep a Script describing the events. You can add these in your team wiki or (my preferred way) print it and put it on the walls. Examples (and they are just examples – you should write down whatever makes more sense for your team):
Planning Part 1 (PP1) Script
- Starts at 10 am every second Monday ( next : 23 Dec )
- Scrum Room
- Product Owner Explains next User stories (next priorities) for the next Sprint
- Teams clears out any remain doubts
- Team ensures Definition of Ready is fulfilled (check here)
- Team and PO review DoD
- PO is available for any questions during Planning Part 2
Planning Part 2 (PP2) Script
- Starts right after Planning Part 1
- Team Space (in front of our team board)
- Team creates all tasks to make sure US is ready for delivery at the end of Sprint
- Team agrees on what can be committed for the sprint
- Team agrees with PO what will be delivered at the end of Sprint
- At the end of PP2, Team board should have the committed stories and task visible and ready to start
- Demo starts 14pm sharp on last Friday of sprint (next: 3 Jan)
- Everyone is invited to come
- Team should prepare Room and needed material before hand (don’t forget HDMI cable!)
- PO will approve or disapprove stories
- Participants are invited to provide feedback on Demoed Stories
- PO will consider feedback as he may find suitable
(For the demo Script is especially important if you give hints regarding the preparation of the room or devices if it is required to have a special setup)
You can script whatever events you have (including the Daily stand-up – you can write down the time it starts and where) and make it visible. Scripts are not only useful for the team but also for our stakeholders, making this information clear in team’s room avoids lots of questions or even ignorance – if info is available and transparent to all, they will most probably read it as they pass by and so become aware of how team works and when and how things happen.
2- Working Agreements and Team values
Since we are talking about hanging stuff on the wall, them let me tell you that it’s also very important to make visible both the Team Values and The Team working Agreements.
You can read more on How to set the Team Values here and also get some examples of both values and agreements here.
If they are there on the wall, people will constantly be reminded of the things they, as a team, value and expect from each other. It’s very healthy ;).
3- Definition of Ready
During these last years I’ve found lots of people never heard about Definition of Ready (including Scrum Master). As such, my advice is for you to define this with your team (which includes the PO) and make it clear and visible to everyone (yes, print it and add it to the wall). Definition of Ready will, among other things, avoid many misunderstandings and fights when User Stories are not ready to be started.
4- Buglog for Bugs
When you have lots of legacy bugs and no chance to stop production and refactor all, then I found the Buglog very useful.
5- Parking Lot
I’ve seen teams use this, and I’ve use it myself to park topics we cannot discuss right away. For example, imagine there is a topic you want to discuss with the team but only on Daily Stand-up and you don’t want to forget it, then you put it in the parking lot.
We also used it to put impeded things (when impeded by externals and we have to wait, we removed it from the backlog – informing immediately the PO, and added it to Parking Lot, as long as it’s waiting for the other teams to solve it). It’s also, and as I used it most, a good place to add items you want to discuss in Retrospective.
Here’s my template for parking lot
If you want you can user my File: parking lot
One of these days I’ll write more about scaling scrum and my experience with it, but for now I’ll leave you two simple tips for when you are scaling or have several teams who should synchronize – if not regarding the product, at least regarding their practices and experience.
6- Communities of Practice
I found this very useful. You create a community of Practice (Cop) out of anything you want as long as you have people who want to join you. Cop of Scrum Masters, Architects, Developers, Testers, etc – (role oriented) or CoPs which are function oriented like CoP of Design or CoP of architecture.
I’ve seen Scrum Masters Cops where Scrum Masters would advise and help each other with issues in their teams and also synchronizing ways of working. I’ve also seen for example CoP’s of Architecture defining Coding standards and Coding Guidelines as well as Design CoP’s defining GUI standards. So you see, as long as you get motivated people on board, the CoP will always create valuable things for everyone!
7 – Scrum Of scrums
I don’t like Scrum of Scrum’s and I personally don’t see a need to book another meeting for this. But again, this is my experience, yours is different and that is ok. Let me tell you what I do instead.
When I have more than 1 team working in same backlog or in same product and they need to synchronize regularly what I ask them is for them to send a representative to the other Daily Stand ups. So, Joe from “Team Awesome” goes as a representative of “Team Awesome” to the daily stand-up of “Team Incredible” and if he has anything important to tell them he waits until the end and them shares, also when he has is team daily stand-up he let’s his team members know about important things going on ” Team Incredible”.
With this there are no extra meetings, people get to know each other and create bounds and people hear directly from each other what is going on, without intermediaries who may shorten or not explain so well (or without context) the things happening.
Ah! And we rotate this team representative so that it’s not always the same one going.
And there you go, some small improvements you can do right away within your team. All, in the end, you’ll be surrounded of beautiful meaningful walls too!
Have a nice Agile 2014 ;)