Archive
Sprint Planning
This post is meant as a few hints and tips for new ScrumMasters at Sprint Planning. None of this is meant as this is how you have to do it, but it could be a starting point from which you can inspect and adapt.
When I started as an Agile Coach back in 2007, many teams were struggling with Sprint Planning because they were uncomfortable with uncertainty, or the Product Backlog didn’t exist or was in poor shape. Either of these may result in very long Sprint Planning sessions. Interestingly I am seeing a lot of very short Sprint Planning meetings these days, where 30 minutes is taken to select items for the Sprint, with the team hardly saying anything, sometimes only 1 person is speaking. This is very efficient, but kind of misses the point of Sprint Planning.
Objective
- Agree WHAT we are committing to as a team
- Plan HOW we are going to meet this commitment
With modern implementations of Scrum, with a well refined Product Backlog (which the team have been involved in refining), that first part might be quite fast. The second part is what I now see some teams skipping, there is no conversation about how they are going to do the work. Often this is a symptom of them not really being a team. So to a few tips for new ScrumMasters:
Have a Goal 
Many teams struggle here because the top of the Product Backlog is an unrelated collection of items. Sometimes this is done to make sure the whole team is busy in the sprint based on their specialisms. If you do this you will never have a real team, and that maybe ok. Scrum however is a team game, in the pursuit of a cohesive goal, that represents the value we are going to deliver together. Therefore the first thing you do in planning is decide what you want to achieve in the next Sprint and then select the work that you will need to do. This is the WHAT part of Sprint planning. Don’t talk about How until everyone is clear about What. The goal creates clarity and a sense of purpose.
Get Commitment
Get commitment of the team to the Sprint Goal. Maybe commitment is a dirty word these days, some people prefer forecast. However real teams are not afraid of making commitments to each other, not to managers, to each other. Scrum works when the team decided what they can achieve and hold each other accountable for delivering it. Therefore they must believe their goal is achievable. Involve the team in the creation of the goal, that way they have even more skin in the game.
It’s a workshop 
It’s a workshop not a ceremony or a meeting. Most of Sprint Planning is going to be a technical workshop about how they are going to achieve their Sprint Goal. If it helps call it a technical workshop, maybe the team knows what that is. There is nothing worse than everybody siting round a boardroom style table, calling the same tasks out for each Backlog item. I suppose doing the same thing on different sides of the world is slightly worse. The team will not be engaged. As a ScrumMaster ask the team how they are going to achieve their goal and get out of the way.
Be Prepared
Be prepared as a ScrumMaster, but don’t get rigid. An Agenda can be useful to you and the team, but you will deviate and thats ok, so long as it helps the team.
Don’t touch the pen
As a facilitator, don’t be at the front of the workshop capturing everything on index cards and sticks (or in your tracking system). Sprint Planning is not where you need to put in your star performance at the centre of the stage. Think of yourself facilitating at the back of the room, observing what is happening, when the team get stuck that is when you step in with an observation or question to move the team forward. One rule I have is to never touch the pen, unless it is to hand one to a team member. In this way the team own it.
Scrum Coaching Retreats
Since the Scrum Coaching Retreats started in 2011 they have suddenly become widespread, with 6 happening in 2015. The idea was started and driven forward by a group of volunteer Certified Scrum Coaches, working closely with the Scrum Alliance. The event has grown organically and now involves small teams all over the world organizing these events, with support and sponsorship from the Scrum Alliance.
So what is a Scrum Coaching Retreat?
It is not a conference as there are no sessions or speakers, it is Agile Coaches working in Scrum Teams, diving deep into topics that they are interested in.
The collaboration begins before the event itself, as attendees start to discuss potential topics online, that they would like to work on at the event. This sets up the first session, where attendees form teams around topics that they are passionate about. New ideas will emerge, people will change groups, topics will be merged and split differently, but eventually small teams will start to form. The teams will then craft a Vision which focus’ them on the value that they wish to deliver, they select a Product Owner and ScrumMaster, and start to create a Product Backlog. Sounds familiar?
The rest of the retreat is divided into Sprints, each Sprint will start with planning, and then the teams will do some work. Sometimes the value is in the shared learning as they go much deeper into a topic than you would say at a conference workshop or open space session. Sometimes the teams will produce artifacts and material that will have value to them and others long after the retreat has finished. At the end of each Sprint the team will have the opportunity to showcase what they have delivered at a Sprint Review and get feedback. The Sprint then finishes with each team having a retrospective.
The retreats are based around a number of principles:
- Retreat: Creating time and space for focused learning and growth
- Scrum: Learning is done using an empirical framework called Scrum
- Teams: Teams are the heart of Scrum and a key differentiator at Retreats
- Deep: Teams go deep into single topics, rather than covering many broad areas
- Long: Learning, collaboration, and relationships continue long after the event
- Shared Learning: The event is designed for deep collaborative-shared learning
- Two Sleeps: Connections are made when our brains are quiet, the two nights of sleep allow for creative idea formation
So why should I attend a Scrum Coaching Retreat?
The Retreats are for anybody who uses coaching within an Agile environment, attendees range from new ScrumMasters to experienced Agile Coaches, Product Owners and Managers.
“The best part for retreat for me is to collaborate with experienced coaches intensively, which is a great learning and network opportunity. We seldom have chance to work this way with so many experts.” – Daniel Teng (Certified Scrum Coach and Trainer)
“My biggest takeaway from the Phoenix and Thailand coaching retreats I have been a part of is to be able to connect to fellow coaches, debate and discuss the art of coaching and also listen to their case studies.” – Madhur Kathuria (Certified Scrum Coach and Trainer)
For me the format provides a wonderful opportunity to grow yourself as a coach, by learning from your peers and to be part of growing the wider Agile Coaching community.
As I was looking back at some Retreat photo’s from London 2014, it stuck me how many of the people that I had met at the event with whom I have since worked with or collaborated. They are a great networking opportunity, allowing you to make lasting connections that go beyond just exchanging business cards.
“Sharing ideas with some of the most experienced Scrum coaches in the world gave me fresh insights into my own work. And it was fun!” – Alan O’Callaghan
“It was a fantastic experience. It was the first time since embarking on my agile adventure, that I felt like I wasn’t the only one going through the challenges and difficulties I and my teams were experiencing” – Sam Birkinshaw
The Team Formation
At the start of the retreat teams are formed, we have noticed that many teams struggle at first, especially in the first Sprint. As coaches this is a wonderful reminder of the journey that teams go through as they begin to try and work together for the first time, but have not yet built an environment of trust. We have found that the Retreat format provides a great balance, short Sprints where the teams can really focus and the slack time that is built into the schedule. This balance allows the teams to move very quickly from their initial struggles as they form to a point where they are a real team delivering some valuable outcomes.
“It reminded us that living in and working in a Scrum team delivering results isn’t always smooth and it isn’t always easy. It challenged the coaches to ‘eat our own dog food’ and folks GREW as a result” – Bob Galen (Certified Scrum Coach)
Time to Think
The slack time is very important, this includes the breaks, open space sessions and the opportunity to be at rest or unwind with other coaches in the bar in the evening. This time outside the Sprints is important; it allows time for thinking, and thinking done with other coaches willing to listen in a relaxed and respectful environment can be a very powerful thing.
Impressions from previous Retreats
“The groups I worked with during the retreat came up with so many important issues and ideas that we passionately wanted to address. We came up with some great ideas during the retreat and I thought about these discussions many times afterwards, some even directing my business decisions.” – David Lowe
The outcomes from the retreats can become something that has an impact on the wider community; there are online resources that have come out of teams that have continued to collaborate long after the retreat itself.
Below are some impressions from previous retreats, with links to their output.
“The excellent venue added to the whole experience enabling us to be truly agile during our retreat, with my team choosing to work outside in the relaxing inspiring gardens and sunshine (with the occasional rugby professional passing by on their way to training!) ” – Sam Birkinshaw
And a selection of video’s from Chandler (Phoenix) 2013
“One specific topics that was discussed at the 2013 Chandler SCR was Behavior Change. Individual as well as Organizational (collective of culture, structure, process/policies and people). Since then I’ve explored this topic at depth from different perspectives – still learning. It has helped me personally and professionally.” Kamlesh Craving
Scrum Coaching Retreats and the Future
The Scrum Coaching Retreats have allowed the coaches that have attended time to explore the profession of Agile Coaching at a deeper level, and have shown the collaborative spirit within the coaching community. However I believe we have a long way to grow as a community. We have many opportunities for growth, how do we…
- grow our skills as coaches?
- help customers choose the right coach?
- build coaching capability in the organisations that we work?
- transform the world of work?
- build a professional Agile Coaching community?
- deepen our understanding of the key challenges and opportunities of Agile adoption as it ventures into new frontiers?
So come and be part of taking these opportunities at a future Scrum Coaching Retreat, for a list of upcoming events see the Scrum Alliance website.
CSM and Lean Kanban Foundation with Visulisation
A new experiment in London see’s me partnering once again with RippleRock, together we are offering a series of courses beginning the week of 16th February 2014. The Certified ScrumMaster and the Certified Lean Kanban Foundation courses will be as interactive as ever, but will also benefit from graphical recording by Stuart Young from Illustration Station. We are also putting on a Visulisation/Artistry workshop, which will be free to those who sign up for another course. Each of the courses tells a story in its own right delivering value to those who attend; together the courses are trilogy, exposing attendees to a variety of practices, techniques and concepts for the Agile practitioner.
- Certified ScrumMaster course, this CSM course includes graphical recording to provide a visual record of your learning experience. With Mark Summers and graphical artist Stuart Young. Includes the Visual Artistry workshop for free. (19-20th February 2015) +free visual artistry workshop – £950+VAT
- Visual Artistry Workshop. Learn how to use visual artistry as a tool to initiate projects, enhance learning and have fun with your teams. With Graphical artist Stuart Young, supported by Agile Coaches Helen Meek and Mark Summers. (18th February 2015) – £400+VAT
- Certified Lean Kanban Foundation. Learn all about Kanban, once again your experience will be captured graphically. With Helen Meek and Stuart Young. Includes the Visual Artistry workshop for free. (16-17th February 2015) +free visual artistry workshop – £950+VAT
- CSM, Visual artistry workshop and Certified Kanban course – £1600+VAT (All 5 days)
Stuart Young of Illustration Station
Scrum Coaches Retreat Phoenix
Another long trip over to the states this week to attend the Scrum Coaching Retreat in Phoenix. My main reason for attending is that I am involved in bringing the event to Europe for the first time in 2014.
The retreat is unlike a conference or gathering, which sometimes only scratch the surface on topics; here you will go deep into issues that you are passionate about.
I am also hoping to get involved in some improvement initiatives in the CSC programme, either:
• An improvement of the application process, or
• Looking at how we better support coaches on their development path
That second issue is likely to be a central theme for the first European Scrum Coaching Retreat in London from 9th to 11th June 2014. Some information about the event is already here.
And you can register here, to get an early bird price
We will have our own website up shortly. I will keep you posted on anything interested that happens in Phoenix.
A testing bottleneck in my Scrum Team
Recently I was working with a Scrum team who were struggling to get things to Done at the end of a Sprint, they already knew that they had a bottleneck getting things tested, but didn’t really know how to resolve it. They are certainly not unique in having had this struggle, and it was really costing them partially done work, tester working long hours at the end of the Sprint, a code freeze 3 days before the end of the Sprint. I also sensed frustration because they felt things couldn’t improve unless they changed the ratio of developers to testers (6 to 1). That wasn’t going to change immediately and I do like to focus the team on the art of the possible, so what could we do?
I knew I needed to do a little bit of education on dealing with bottlenecks, therefore I gave them a 10 minutes intro on the 5 focusing steps from the Theory of Constraints and then we did a retrospective to come up with some specific actions for them to take as a team.
Identify the systems constraints
The team had already identified that the tester in the team was overloaded with work, especially at the end of the Sprint. Unfortunately the tester was also starved of work in the middle of the Sprint.
Decide how to exploit the system’s constraint(s)
In this context this basically means looking if anyone else in the team can do some of the testing work. This is also a subtle way of introducing the team to the idea of taking a whole team approach to quality, without telling them that’s what they need to do. The kind of things that came up in the retrospective here were:
- Look for opportunities for other team members to help out with the writing and running manual tests. (The team did not yet have any automated acceptance tests)
- Other team members helping out with setup activities, i.e. environments
- Production of tools that would allow the testing work to be done more effectively
Subordinate everything else
For us this meant looking at changing the way we work to get work to flow more evenly. In this area we were looking at how we breakdown work and work more collaboratively as a team:
- Break down items into smaller chunks so that they can get into test earlier
- Write stories so that they are testable, so that parts of the story could be tested earlier
- Create opportunities for earlier feedback from test, reduce waste of fining errors on test environment
- There is no such thing as a bug in a Sprint, its just work that needs to be done before the Story in Done
- Limit items team is working on (Items in Progress), team members swarm on items
- Investment in Automated Acceptance Tests, which would allow the developers to take some of the testing burden
Elevate the system’s constraint(s)
This is looking at how we can increase capacity or capability in the bottleneck area. Which for us would mean hiring more people with the testing skills or providing some kind of training (be it formal or on the job). You should only be thinking about this if you have tried everything you can think of in the previous two steps.
What the team agreed
The immediate things the team agreed to do were:
- Breaking stories down smaller and also looking for opportunities to commit code regularly, as soon as something can be meaningfully tested
- Involving the tester in design activities, so that the team could design/implement with testability in mind, also as a result there was less of a handover
- Regular demo’s to the tester and Product Owner, whenever there is something to show
- The tester would continually ask “what have you got to show me?”
- Toolset to support Testing Diagnostics
It wasn’t agreed in the retrospective but subsequently they also started to get other team members helping out with testing tasks as well.
As a result of these actions, the code freeze was no longer necessary and the test activities were more evenly spread throughout the Sprint, they had less partially done work. So this is a good step in the right direction. To take it to the next level the team will need to focus more on swarming and investing in automated acceptance testing. If they can start to do that over their next few releases, then the perceived issues of the ratio of developers to testers may become a mute point, as the team adjusts its skills and practices to be able to deliver high quality work.
Sailboat Retrospective
I use the sailboat retrospective as an activity to gather information for Sprint Retrospectives, Release Retrospectives or even when I go in as a coach to find out where teams are. It is a fun way to gather opportunities, risks and problems.
I believe I may have been inspired for this retrospective by Innovation Games Speed Boat game used for Identifying features that are holding you back.
I draw a picture, you don’t have to be an artist just see below:
The idea here is that the team are on a boat. On the right hand-side is the Promised Land it is the best development environment they can imagine: an effective team who can take pride in their work, happy customers, opportunities for learning and growth (I usually get the team to create some kind of Vision for what the Promised Land looks like). However there are anchors that are holding them back, stopping them making progress towards the Promised Land (These are the problems). In front of them there be pirates, rocks and other obstacles which could stop the team/organization getting to where it needs to be or even sink the boat completely (These are the risks). There are however opportune winds, things in the organization that we can take advantage of to fill our sails and navigate a course to the Promised Land (These are the opportunities).
So ask the team:
• What are the opportune winds that will help us propel our ship to the Promised Land
• What are the anchors that are holding us back
• What are the rocks and pirates that can sink our ship (or at least do some damage)
One problem, risk, or opportunity per sticky and ask them to write clearly. I get them to do this individually so that everyone gets to contribute.
5-7 minutes to individually brainstorm
Allow time for each person to go up and place their stickies on the picture while the others listen.
You can then get them to organize/filter them however you want. Before moving onto driving out some actions.
Affinity Prioritisation
Recently faced with the challenge of getting 136 epic stories prioritised fast with a group of stakeholders before the team started to estimate, we tried something that was new for me, using an affinity approach to prioritise.
Often that initial prioritisation of a Product Backlog can take a while as you try to assign value to each item or discuss the relative benefits of each story. However we had a team who were ready to go with estimating and we wanted some notion of priority, so that the team could focus their efforts correctly when estimating. Therefor we decided that we didn’t need business value associated with each item, that could come later, instead a prioritised list would be sufficient.
We planned to use affinity estimation to T-Shirt size the Product Backlog, so we thought why not use that kind of idea for this initial pass at prioritisation. We were able to get all 136 stories prioritised within an hour, with 5 stakeholders participating.
Here’s how it went:
Starting out
The Product Owner introduced a story and placed it on a table. The next story was then introduced and he said if he thought it was higher or lower priority, if it was higher priority it was placed on the left, if it was lower priority it was placed on the right. At this point discussion would break out and an opportunity given for others to move the story. Then another story would be introduced and placed in relative priority to what was already laid out. Some stories might bob around for a while, but eventually they settled down.
Evolution
We had time-boxed the activity to 1 hour and started a little late, but by the time we had a dozen or so stories the space on the table started to take on a life of its own, and now we had a baseline the pace picked up. There was now a group of high priority items on the left, some stories that people were talking about medium priority were in the middle and the low priority ones on the right. As the number of cards grew the cards started to be prioritised vertically as well as horizontally, still all relative, but such that the highest priority card was in the top left corner and then priority went down the column and then onto the next.
As we did this the interesting thing was that people started to discuss what it meant for something to be high priority, many of the Epic’s would need some part of them delivering to constitute a minimal viable product, but what made us want to prioritise something high up the list? It was good to let that come out rather than define it up front.
Finally
Starting from the left we then drew lines where we thought there was a step change in priority, and classified them as we had started to discuss as high, medium, low. If we had taken more time we could have been a bit more sophisticated and assigned relative numbers to each story representing the value. We ended the session with all 136 items prioritised, each with a unique priority, ready for the team to estimate.
Prioritisation does not end here, but this was a very fast way of getting an initial prioritisation, and it certainly helped start the conversation about Product Backlog priorities.
Final picture above is of me and the Product Owner, note the Vision, which is visible stuck to the TV above our heads.
3 Upper Management Challenges when adopting Scrum
Some challenges that I have encountered as an Agile Coach working in large organisations adopting Scrum and how you could approach such a scenario.
We want to adopt Scrum, but we are not willing to change anything
There is often a belief that brining in Scrum is going to be just a set of new practices for the development team and they can get benefits without changing anything. I have discovered that it is best to address this one early with the organisations senior team, otherwise they will be wasting their time. So education is important, a workshop with senior stakeholders usually does it, just getting them thinking what it will mean for the organisation to deliver working software in vertical slices rather than building it in layers, what will it mean for the organisation to have dedicated teams. These initial workshops help me and the client understand if they are ready for Scrum.
There can be only one
Different change initiatives sponsored by different members of the executive team, this can be particularly painful if you are working with the organisation to move them towards agility, but you discover some other change initiative designed to get control by introducing more management and more structure. There can be only one change initiative, therefore work to join them up, however if they are in conflict work with upper management to see what is most important for them now, sometimes organisations need to take a step back before they are ready to move forward. Just make sure they have the information to make the right decision for them.
The Agile antibody
Sometimes there will be executives who say they are behind Scrum, but behind the scenes they will be fighting a rear guard action to protect their domain, maybe even trying to kill off Scrum inside the organization. This is not always obvious at first, but it will become so when teams struggle to work with their area of the organisation. We obviously want them onboard, so an approach I would use here is to try help them understand how they could benefit from a new world using Scrum. For example the head of testing may be interested to know how in Scrum testing is central to the development process, that they would have much more scope to influence the quality of the products.
Cool Wall Retrospective
This post is republished from my old blog
At the Munich Scrum Gathering (2009), Harvey Wheaton from Supermassive Games did a presentation entitled “Growing Self Organising Teams”, which was exceptional and I found it very inspiring, the presentation can be found on the Scrum Alliance web-site. In the presentation one slide caught my attention and it was how the team had used a Cool Wall, inspired by Top Gear (popular car show in the UK). I thought that would be an excellent tool for a retrospective and used it at the next opportunity, this is how I used it. Picture not great, but you get the idea…
Using the Cool Wall to Gather Data
The team was asked brainstorm team practices/team customs/patterns/ways of working, each team member then took it in turn to add their practice to the cool wall, and share it with the rest of the team. Sub-zero was for practices where the team felt they were world class, seriously un-cool was reserved for practices that really weren’t working.
I then asked the team to vote for the practice they wanted to work on, I had forgotten my sticky dots so we used marker pens. The team actually picked a practice from Un-Cool as the stuff in seriously un-cool was out of their sphere of influence and the ScrumMaster was dealing with it already.
Using the Cool Wall to Drive out Actions
Once we had selected a practice we had some discussion to understand the root cause. We then moved to generating actions by asking ourselves what we need to do to move this practice one column to the right. Remember you only want a few actions otherwise nothing will get done.
Check-out
To keep with the car theme I then asked the team to say given their project, what mode of transport they most felt like.
Summary
The approach worked well and really helped to create a picture of the work the team does, and uncovered loads of stuff that the ScrumMaster could work on to help the team improve. Also we only spent an hour doing it.
Exploring Agility 