A while ago I got approached by a team that was struggling with their sprint plannings. To help them help themselves I put together a Planning Cheat Sheet to give them some pointers. It has come to good use since and has caught some attention where I’m working so I thought I would share it here as well for others to use.
Please comment if you found it useful and/or if you would like some tweaks to it.
A few friends and I have decided to kick off our very own consultancy firm. After much consideration we have agree to call it Emergent and our logo looks like this.
We also have a (very basic) web site that can be found at http://www.emergent.se.
In this post I’ll describe some exercises that can be used when kicking off a new team or if you want to get an existing team aligned on how it wants to work and what value they provide to the organization.
The package contains of the parts below. Depending on how far you want to take it and how you work with improvements you might want to settle for the first two parts.
All of these usually take about 3 hours to get through (including breaks).
The first thing you want to do is to talk about why you are there (you probably already touched on that in the invite) and why it is important that the whole team participates.
After that you will want to get people in the right mindset with some warm up. Especially if this is the first thing you do in the morning.
In this part you can throw up examples of teams and ask the group if they are awesome or not. Discuss why or why not. You can find your own but here are some examples and points that you can discuss.
This warm-up is a segway into the third part – Mission and Definition of Awesome. The purpose being that the team members start telling each other what they think is working well from their perspective.
This exercise builds on appreciative inquiry where you only focus and talk about what is working well or what could be working well.
Ask the participants to write on post-its what is working well today. One thing per post-it. After about 3-4 minutes you ask the participants to present their post-its one by one and talk about what they have written.
Ask the participants to imagine that you have created a time machine. You all step through this time machine and travel into the future. Depending on what context you might want to select different amounts of time but it can for instance be a year into the future. In this future you walk over to the office and meet your future selves. They say that it has never been this great. Everything is working perfectly. You are productive, happy etc. Ask the participants to write on post-its what their future selves tell them and what they see around them. Present as you did in stage 1.
The next part is to as a group agree on what the 
purpose of the team is (Mission) and
what identifies them when they are working really well (Definition of Awesome) is.
Start by explaining the format
and the rules:
Invite everyone to the whiteboard and hand out pens. What usually happens is that people start adding statements without getting questioned. The magic happens when all five slots are full. Then the teams needs to start communicating, arguing and agreeing on what they think is important. Try to give the team as much room as possible but if discussions derail ask the team to move on the something else and then go back to pick up the statement discussed later on.
When the discussions are cooling down you can enter the group again and point at the first statement and ask if everyone agrees. Thumbs up = agree, thumbs to the side = could be improved, thumbs down = this is not ok.
When the team is in agreement move on to the next part.
So now we have identified where the team wants to be – the Definition of Awesome. Let’s figure out how to get there. Here we use the classic coaching format of identifying the target condition (Definition of Awesome), current condition, obstacles and actions/improvements. In the picture to the right the rainbows and unicorns is the definition of awesome. This is where the team wants to be. The five roads represent the five statements and the swamp is where the team is today.
In this step the team writes post-its describing the current condition connected to each track. These are represented by the yellow post-its on the picture.
Here the team looks at what is preventing them from reaching the target condition. These are represented by the pink post-its.
In this part the team will identify how Awesome can be reached. We use a rotating flipchart style where you set up five flip charts or Magic Charts spread out around the room. Split the team and spread out among the charts. On each chart you talk about one of the definitions and what you can do to reach it. If the idea is complex you might want to use a Kata style approach – we put them on the upper part. Actions that are quick and straight forward are put in the bottom.
After about 5 minutes it’s time to rotate and you go to the next chart and discuss that. After four rotations everyone should have visited each chart/definition.
To have something concrete to bring back and to get started when right away when you come back to the office it can be a good idea to vote on one quick fix per chart to do right away. Assign people to take responsibility for each quick fix that are voted on.
After these exercises the team will have a lot of materials to drive improvements from. Bring it all back and try to make as much of the results visibal and present near the team. If you aren’t already using a Kata-style approach to improvements perhaps you can find some inspiration in this blog post: Toyota Kata – an alternative to retrospectives by HĂ„kan Forss.
However you do it, the important thing is that you continue to work with the results so the time wasn’t wasted and just a nice experience in a conference room somewhere.
This set of exercises have proved to work quite well for me. Off course you might want to tweak them to fit the teams needs or add other exercises if you do this as part of a full day.
I hope this post was helpful and don’t hesitate to comment below or reach out to me if you have any questions or want help in facilitating a workshop.
Good luck!
At the company I work we faced the task of assigning two new managers for a group of consultants that were without a manger and also had grown too big for just one person to look after their needs. Traditionally this was done by our CEO and some other managers who looked for someone in-house by talking to people they thought were suitable for the job or sometimes by looking for people from the outside. Historically this had sometimes worked well and other times not so well.
This time we thought we should try something new. Why not let the members of the group choose?
Our process looked something like this:
This process became quite lengthy but the really great thing about this approach is that we have eliminated a lot of risks involved in a change like this. The new manager was instantly accepted by the group and the managers knew what they were getting themselves into and knew that they were accepted in their new role by their group.
This is still quite new and we will see how it plays out in the long run but from we have seen so far this is a really good approach when appointing a new manager or leader for a group.
One of the teams I have been working with lately develop and maintain a retailing web site. Historically what they should focus on was decided by someone high up in the organization with little to no involvement of the team. After a lot of time and money invested most of those ideas turned out to have little to no impact on the number of purchases made through the site. To remedy this we wanted to leverage the collective intelligence of the team and also use a more scientific approach when deciding what to do. The approach we took drew inspiration from Lean UX and Lean Startup. We also used tools like Impact Mapping where the idea is to have a clear goal of what we want to achieve, see what actors could affect that goal and then look at what assumptions we have about those users related to that goal. After that we have our Impact Map and itâs time to get to work with the assumptions. We did this in really short iterations to keep the investments small if assumption turned out be false. One really useful way of validating ideas we found was to do lightweight usability testing. The way we did it often included theses steps:
We can usually go through this cycle in a day and that gives us really fast feedback loops and we avoid investing too much time and money in developing something just because someone high up in the hierarchy decided it was a good idea.
This approach has helped us a lot and perhaps it is something that can help you as well if it fits your context. Please post a comment below if you found this post helpful or if you have tried it yourself and have some insights or experiences to share.
Have you ever heard members of a development team complain about too many meetings? And when you look in their calendar all you find is a couple of meetings spread out through the week. As a Manager, Scrum Master, Product Owner etc. you might have thought “That’s nothing – I have meetings a day long!”. This is a natural reaction but the point you are missing is that the nature of your work is radically different compared to that of the development team. While a lot of your work is done in meetings and your days are fragmented the teams work doesn’t work that way. Paul Graham describes it very well in his post from 2009 about the Maker’s Schedule and the Manager’s Schedule (I really recommend reading the whole post). He describes that a developers day may be blown to pieces if meetings are scheduled in a way that prevents them from getting some flow in their work. To remedy this I recommend talking about this within your team and adding it to your Teams Working Agreement (because you have one of those, right?).
Examples of how this could look in practice:
I really recommend trying this out. And who knows, maybe you as a non developer find value in getting some uninterrupted thinking time as well.
Ps. You should of course still talk to people if you need help getting unblocked or help someone else get unblocked. “People and interactions over processes and tools” is still what we strive for. This is merely a tool to help getting you meetings under control if that is a problem for your team. Ds.
I just attended the SAFe training “Scaled Agilist”. In this post I’ll describe my first impressions. To start off I need to say that I was skeptical about SAFe before taking the training. I wasn’t very impressed about what I had read about it on blogs/twitter and hearing about it in short presentations. But I wanted to learn more about it as I think it is something we will need to get used to in the agile community. I wanted to give it a shot – perhaps it was something in there that was really useful that I just hadn’t seen.
Positives
I’ll start with the positives about the training.
Alright, so those were the good parts but to be honest, didn’t we already know about all of that? It is not like SAFe came with anything new – it just re-packaged what we already knew. I guess that the value SAFe adds is that it is now a model that can be “sold” to management… well, since it’s a model.
Negatives
To the negatives. Since many others have already bashed SAFe (see the first slides in this presentation) I’ll just stick to some particular things to the training I attended. (A disclaimer is that this was the first time this trainer taught this class so all things might not be according to what others are saying.)
At the end of the course I asked the trainer what companies would really benefit from using SAFe. It was an honest question since I really couldn’t see it. The answers sort of made me fall off my chair. According to him it needed to be really big multinational corporations. In Sweden (this is where I took the training), he said, we only have one of those and it is Ericsson… So why on earth would you then sell this training/model in Sweden to people who are not working at Ericsson? Is this just a new moneymaking machine for trainers to sell certifications? In this case I guess the answer is yes. Since the trainer was also selling his own model for scaling in mid-size corporations I would like to get a second opinion on that statement. Also, if you are already delivering value more frequently and are actively working towards having autonomous teams SAFe (according to the trainer) isn’t for you. Your organization should be pretty messy and would benefit from a hard reset.
So a conclusion is that if you like me is living in Sweden and not working at Ericsson – spend your money elsewhere.
Wrap up
To wrap up I’d like to quote Don Reinertsen in his foreword to Dean Leffingwells Agile Software Requirements (that describes sort of a first version of SAFe).
//…// I suggest paying attention to several things. First, try to understand the reasons why certain of these approaches work, not just what they are. If you understand why things work then you can more easily adopt them to your own unique context. Second, treat these ideas as a portfolio of useful patterns rather than a rigid set of practices that must be adopted as a group. //…//
Unfortunately these wise words are all lost in SAFe. It is taught as a “do all or it will fail”-process. Very similar to the way Scrum is taught in many places. But we all know that you shouldn’t do only Scrum by the book – it is a starting point. And that is what use I see for SAFe – a starting point if you have a really big messed up organization it could serve as a replacement and a starting point when replacing your process. If you don’t have that – consider it a patterns book. And very much like when you use a design pattern when coding, make sure that you understand what problem you are trying solve and also understand the thinking behind the pattern you are thinking about applying.
