You are a Scrum Master and you have the feeling, that your team “actually works fine” OR You are a Scrum Master and you would like to check what else there is to do to help your team to improve? OR You are a Scrum Master and you are looking for confirmation that you are doing the right thing?
My partner Mel and me went on a short trip to Barcelona. We created a backlog with things to do, used backlog refinement and 1-day sprints to manage ourselves in the 3,5 days there. The following post describes our experiences.
A backlog for the trip?
Similar to an Agile software development project you normally want to get the best possible ROI (Return of Invest) from your holiday. The holiday ROI, of course, is different for everyone and not neccessarily connected to a monetary value.
Similar to a lot of projects out trip had a fixed time (in our case 3,5 days).
Mel and me have never been to Barcelona before, so we populated our backlog with sightseeing tips and places to eat from a city guide book as well as asking family and friends who have been in Barcelona before. (Asking my Facebook friends resulted in at least 15 Backlog items…\o/) And that was already the first version of the backlog! A very rough list with items on Post-Its like “Stroll through Barri Gotic”, “Eat Churros” or “Familia Sagrada”, but good enough to start our trip.
I experienced a lot of Agile projects that started the same way: An appropriately detailed list of user stories with no guarantee of completeness or sufficiency. That’s why we want the backlog to be emergent. For Mel and me this provided the best flexible way to travel and also the chance for serendipity.
Some of the backlog items were described with more details, information or restraints (our “acceptance criterias”) like “Get tickets online to avoid queues.” or the adress of the restaurant; mostly as a result of talking with each othet or reading the city guide. We also used diffferent Post-It colors for different types (sight, eating place, transport, …).
The first prioritization of the backlog and Sprint Planning was done at the hotel bar after we arrived late night in Barcelona.
Our Scrum Flow in a way then was then every night: Review (“What did we do today?”, “What was your highlight?”), Retrospective (“What can we do different tomorrow to have an even more awesome trip?”), Planning (“What do we want to do tomorrow.”). Backlog Refinement took place almost all the time, either because we read new stuff or liked places we wanted to re-visit (definitely El Born, “Looks like a nice restaurant/bar.”) or recognized we will not have enough time to do it and therefore threw away the Post-It.
Stakeholder, Product Owner, Scrum Master, Dev-Team
In a way the Scrum roles were implicitly realized:
Mel acted more like the Product Owner because she read the city guide more seriously than I did. Therefore she had better arguments on he ROI. I was more the Scrum Master because I pointed out several times that we can’t do all of the sights or made clear the consequences.
The Dev-Team was the people and the city of Barcelona. At least in a way: They not only offered us a wide range of possibilities on how to maximize our ROI but also “delivered” awesome sights. 🙂
Stakeholders or users were Mel and me ourselves, but also our family and friends (“Have you visited the place I told you to?”) or our employer (“Have fun and relax to be happy back at work.”).
[OK. The role comparison is a bit lame.]
Mel an me had a great time in Barcelona. It was the first time that we organized the things we want to do with a backlog, but both of us really loved it. Every evening we were happy and sometimes astonished how many sights we visited (moving Post-Its in “Done”). We gained very clear insights that we can never see all sights within those 3,5 days and felt OK with that.
We also understood that we should do a little more planning next time to avoid standing in front of a closed museum (although it was mentioned in the city guide… :)).
Have you ever used the SWOT Matrix? Did the results bring about a decision? And then? Have you used the results after some time to validate your decision again? This post describes how I used a SWOT Matrix to help a team to try working with Scrum. After 4 months we validated what we thought then defined as strength, weakness, opportunity or threat.
A “SWOT analysis (alternatively SWOT Matrix) is a structured planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture.”
Prepare a four-square quadrant using 4 or one huge flip-charts. Each quadrant is named one of the following words: Strengths, Weaknesses, Opportunities, Threats.
Strengths: characteristics of the business or project that give it an advantage over others Weaknesses: are characteristics that place the team at a disadvantage relative to others Opportunities: elements that the project could exploit to its advantage Threats: elements in the environment that could cause trouble for the business or project
I asked the team to write on post-its what the strengths, weaknesses, opportunities or threats are if we try working with Scrum for 3 months. After everyone had finished writing, explaining and sticking their post-its, we simply clustered the post-its and then dot voted the cluster (“What are the most relevant cluster for that quadrant?”).
By now the SWOT Matrix helped the team already to identify and address all factors related to the change (“Try working with Scrum”), both positive and negative. It also helped team members to understand that they are not the only ones who see a threat or an opportunity. Or the other way around: Team members understand that their identified weakness of the change might as well be ruled out by several strengths of other team members.
Having identified all the factors with the SWOT Matrix I pushed them in a direction with the final question: “How high is your resistance to try working with Scrum for 3 months?” (I made some good experiences in the last months with avoiding “Yes-No-Decisions” but rather to start an experiment with asking about the resistance to something and then try to reach an agreement.) As the resistance to try it was rather low, we worked with Scrum in the last 4 months.
This week we validated our decision to work with Scrum and as well checked which of the assumed strengths, weaknesses, opportunities or threats really came true.
It was great to review the dot voted clusters from 4 months ago and then validate if those have proved true. For this purpose I simply prepared a flip chart with a range from “yes” to “no” next to the names of the cluster and asked for each “After 10 Sprints: What has proved to be true?”
As a result we had a good discussion about the clusters that didn’t turn out to be true and what to do about it. (Could be a nice topic for a post as well. :)) Again we finished the meeting with asking about the resistance to keep on using Scrum. As you can see: There is hardly any resistance.
In one of the last retrospectives a team member complained about the “not very sexy” tasks the team had to do. Well, we all know that life is not all beer and skittles. Nevertheless I think, the team member was actually pointing out, that the “sexiness” of tasks can have impact on the general motivation of the team, of course. That’s why I was introducing the “sexy <> not-so-sexy” activity in the last retrospective. (As this idea originated in the team member’s comment I also call it “The Thomas S. Approach”. 🙂 )
In general, the team’s job is split in tasks on a support level (approx. 65%) and project tasks on a product development level (rest of their time). The team is working with a Kanban system and is using several Scrum ceremonies (regular retrospectives, review meetings, agile estimation for project tasks etc.).
The “sexy <> not-so-sexy” activity fits perfectly in between the check-in (“Setting the stage”) and “Gather Data” activities and is as easy as this:
1) Prepare a chart that shows a line between “sexy” and “not-so-sexy”.
2) Put all “done” tasks on the table and let the team stick them on the line accoring to the task’s “sexiness”.
3) Discuss (“Any suprises? Any patterns?”)
Why I think this acitivity works:
The team is reviewing their finished tasks while sticking it to the flipchart. (Reflection: “Cool, we have done quite a lot.”)
The team is re-evaluating the tasks. (Reflection: “Wow. That was a cool task.” or “I really hated that task.”)
The PO (Note: The team decided to have their retrospective with the PO.) realizes that different tasks can have different motivation.
Of course, the activity also shows the big gap between doing tasks that have value (“sexy”) and tasks that are simply stupid mechanics (“not-so-sexy”). Team members are aware of that. And it does have impact on the motivation if you are only doing “not-so-sexy” tasks.
As there will always be “not-so-sexy” tasks: Maybe there is a way to morph “not-so-sexy” tasks into “sexy” tasks? Any suggenstions?
UPDATE FEBRUARY 2013
The activity has been refinded after discussing it with one of the team members. He pointed out, that value is more “valuable” than sexiness. As a consequence I added the value dimension to the chart.
Fortunately retrospectives are already a standard at our company now. Not only our developers teams, but also our sales team, our team assistents and as of late also our management (surprisingly, the last.. :)) have regular retrospectives. Because it has become standard to have retrospectives there is also the chance of falling into a dull routine, both for the team members and the facilitator (mostly myself). To counteract this dull routine we try to do different activities. I tried the following Check-In activity in the last weeks:
Esther Derby and Diana Larsen suggest in their book “Agile Retrospectives” as a Check-In activity to ask every participant “In one or two words: What are your hopes or wishes for this retrospective”. No post-its, no explanation, just one or two words. This always works great.
This question inspired me to ask participants an even more general question as a Check-In excercise: “Why are we doing retrospectives anyway?” I do this as a kind of fast brainstorming and jot everything down on a flipchart. It is surprising what the participants are coming up with. I heard everything from “I don’t know.” (Oops!) and “Because you told us to.” (Ooooooops!) to “Kaizen. Continuous Improvement.” (Thx.) and “We don’t want to do mistakes a second time.” (!!!)
It is also a good excercise to remind the participants of the principles of the agile manifest, one of them is: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” (Dare to ask if everyone knows and understands the Agile Manifesto… and maybe be surprised.)
And, of course, it is a good excercise to jolt the participants from their retrospective routine.
choose and practice techniques the team and/or product group has agreed to try, until they are well understood
experiment until you find a better way
When I try to find this Kaizen practice in my work of the last years, it fits to what I call the “soft agile transition from nowhere to Scrum.” 😉
Here is the formula: (0) Nothing > (1) Daily communication > (2) Visual Workflow > (3) Kanban > (4) Scrumban > (5) Scrum
When we started working with agile techniques we had a divergent mindset in our product teams. Only one team was ready and willing to start with Scrum straight away. Other teams were reluctant to try anything agile and stayed with “Nothing” or were led by project management.
By now all our teams are somewhere in the “soft agile transition from nowhere to Scrum” and I’m happy that all of them have passed step “(1) Daily communication” already.
The above described Kaizen was my fundamental line of action to move step by step from (0) to (5).
What are your experiences with introducing agile techniques to your company?
Characteristics of the “soft agile transition from nowhere to Scrum”
– Black Box
– Led by Project Management
It’s great to witness how a company changes from somewhat “old school-ish” to something agile-like: Last week we finally started with a Scrum of Scrum and it turns out to be working pretty well only after a few days.
Actually most of our teams have been working with some kind of agile process for some time now: some are doing Scrum, some Scrumban, most are doing Kanban (although predominantely it’s more a visualized work-flow than “real” Kanban). All of them were having a Daily Stand-Up (or Daily Scrum) right from the beginning: some were having theirs in the morning, others before lunch and others after lunch.
I visited several Daily Stand-Up every day and experienced what happens to issues or tasks depending on other teams. Either a team member was planning to talk to the other team (and most often forgot about it right after the meeting: Damn short term memory…) or the issue was bounced via a project manager like myself (who most often missed the crucial part. Sorry…) or the team just simply complained about the fact that it had to wait for another team (but was not doing anything against it). In the end the tasks normally moved to the “pending” column and stayed there for much too long.
Funny enough we actually were doing a kind of Scrum od Scrum since about a year: It was the earliest meeting of the day with all Tech Leads dealing with only one question: Are you about to put something in another team’s way today? It is only natural that the info that was given in this meeting was not up to date anymore (as the last Daily Stand-Up of the teams were at least over 16 hours away).
Introducing a Scrum of Scrum does not only optimze communication but also enables fast and direct communication. We now have a synchronisation of all teams within 30 minutes: First all Daily Stand-Ups of the teams, then the Scrum of Scrum meeting.
All dependencies or impediments between teams are solved or at least communicated within 30 minutes. There is no failing because of short term memory, project manager etc. (see above).