- devise a solution together
- plan the execution of the solution
- build a business case (eg, to justify spending some money). Is it clear now that the benefits are much higher than the costs? Etc.
Thursday, December 31, 2015
Wednesday, December 30, 2015
This is the 3rd of 4 parts. Part 1 is here.
Now we come to a harder meeting. The Sprint Review. It is hard because no one in this Team is used to showing anything completed in 2 weeks.
They are used to showing Powerpoints. Vaporware. “Thoughts.” With knowledge workers or managers, when they show this stuff, can you tell if you have made any progress? Of course they say they have done excellent work. Meaningless. How do you know? You don’t. Sometimes they have actually made tons of progress. Other times, the progress is negative. Very hard to know when it is progress (they always say it is).
Ok, then, we have to change things then. We need to have a better fix on whether we have made progress or not. And, if progress, how much.
Sprint Review. Alright then!
First, the MST has to do a general 'review' of things over this Sprint. The CEO does this quickly. An example:
- • We committed to the following 8 stories in the Sprint Planning Meeting. (He lists them.)
- • We completed 7 of them. We did not complete the last one. We started an additional story, but did not complete it.
- • Our Velocity for the Sprint was 18 SPs (story points, or units of work).
- • That gives us an average velocity of 20 over the last 3 sprints. With that velocity, we expect to deliver X on Y date and A on B date. Just a bit later than what we said 2 weeks ago.
Note that the PO is summarizing for the Team. And the business stakeholders are there.
Necessary talking and summary. Blah, blah, blah. Keep this part short! Very short. This is altogether too much like the usual BS song and dance stuff they have been trained to waste time with….and they have done it for 5+ years. People have been promoted for no reason except that they are good at this Powerpoint BS. I could express this more kindly, but I won’t. As a shareholder of many companies, I am disgusted at the long wasteful meetings that this stuff is usually done in. Any questions?
But I do agree, we need a short, very short, summary by the Product Owner (CEO). 10 minutes? Something like that. Short!!
The other people can talk some at this point. Not much. These people are all good talkers. The BS meters are running high at this point. Watch out.
Now, they have to show the real stuff. Demo.
Quickly, they have to demo the working stories. Whoa! (Neither demo nor 'working' imply or mean that the product must be released every sprint. Depends on many factors. A typical situation is that it takes multiple sprints for a product to be built enough to release to customers, whether internal or external.)
We need good independent 'business stakeholders' (BSHs) to be there to give good, independent feedback on what has been accomplished. We need to know if we have made real progress. Or, have we just been 'working hard' and accomplished nothing?! Hence, independent feedback. Feedback that represents the 'customer' for each story. Some stories build 'product' for external customers and some stories build 'product' for internal customers. And 'external customers' much too often these days means 'the regulators'.
We need people at the demo who can quickly give us feedback that these different customers will like (or not like) what the MST has finished this sprint. And I call these people (BSHs). Note: your firm may call them lots of things. Examples: customers, managers, shareholders, consultants, Board members, dept heads, SMEs, gurus, wise old heads, customer relationship managers, product managers, etc, etc, etc.
Also, often the word 'business stakeholder' already has a meaning in your firm different than my meaning. Watch out for that. Picking the right BSHs (as I defined them) is hard. And important.
And we need the BSHs to give complete, detailed, honest feedback now. So, you will not ever get perfect BSHs, but do the best you can. "The bad news does not get better with age."
For the MST people, receiving honest feedback can be tough. They have often not heard that in a good while. All kinds of 'acting out' can happen. Some want to 'shoot the messenger'. Or blame Scrum.
This can be tough on the PO (CEO) in at least 3 ways: (a) he or she is getting way more negative feedback than in the past, (b) the direct reports are complaining loudly about the negative feedback they are getting, and (c) the CEO can see that the 'team' culture that had been 'talked about' for ages does not really exist in the way they had hoped. This can be tough to swallow.
If there is not much negative feedback, there are two possible reasons. (a) Everyone is Steve Jobs (or pick another business icon). Unlikely. (b) People are lying or don't know how to give feedback. Often because we picked patsies as the BSHs (and deep-down knew they would give only 'sweet' feedback).
Get good and honest BSHs. Insist on the truth. Remind people that the bad news is the good news. Because "the bad news doesn't get better with age." Meaning: now that we know it, we're gonna fix it now, before it becomes more expensive to fix.
Be patient. "Little things are big." (Yogi Berra.) And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.
Well, to be a bit more honest, at some point the CEO is very likely to see that someone 'needs a promotion to another company.'
The CEO again needs to be patient. These people are good people in various ways. And the company's culture (or someone's culture) has mis-trained them for many years now. So, it will take more than 2 sprints for all the dysfunctions to come out and for all the re-training to occur.
So, give people a reasonable chance to adjust. But at some point, one person is likely to be 'at the far end of the scale' and you have to give them a 'promotion to another company'. (Often we say "It's not you; it's me." I say this only partly to add a bit of levity.) And it is tough, but it is also the best thing for that person at that point.
Part 4 is next. Feedback is always welcome.
Tuesday, December 29, 2015
Part 2. (See here for Part 1.)
Now, the work of the sprint needs to be defined in small 'stories'. To me, for two weeks, 8 stories for a team of 7 is about small enough.
Team. Did I mention that this is and should be a cross-functional and multi-functional team? The 'people' within the MS Team are all about the Team accomplishing the Team goal(s)! So, we are expecting the people in (parts of) the MST to help each other. We expect multiple people (parts) to typically work on each story.
Done. We also expect the stories in the sprint (the work of the MST) to be 'completed' by the end of the Sprint. To be 'working product' that can at least be 'inspected' by someone independent (eg, some independent business stakeholders). The BSHs should look at it and say 'this is good; customers are really gonna want this stuff'. Or, at least, this is the feedback we want at the end of the sprint, on each and every story. The truth is we often learn that the BSHs are not happy with a couple of stories (that had seemed to be ‘working’). And, the bad news does not get worse with age. (Each failure is an opportunity to learn.)
So, each story must be demo-ed at the end of the Sprint.
Writing small stories that can be demo-ed is a new art for the MST people. Well, they can write stories that will never be demoed (Sorry! I mean stories that can be demoed after they have left the company.... Sorry! I meant stories that can be demoed in 5 years). [Too much sarcasm? Sorry.] But, seriously, writing stories that can be completed and demoed in 2 weeks is hard for them at first, because they have never done it before. If you have never done something, in fact it usually feels impossible! It is not impossible at all, but they probably will feel like it is. These are tough guys to coach.
Remember that 'completed' requires that you have a good 'definition of done' and that always includes some 'verification and validation' by a competent and independent V&V person. With software, we call this well-tested by a good QA person. This also is trouble for the MST people, since they have never done this before, usually. Or they have never made transparent what they do or don’t do for V&V.
Daily Scrums. Daily. Any questions? I mean, seriously, can there be any question?
A 15 minute stand-up where each person answers the 3 questions.
You will hear some lame excuses about why they can’t attend or did not attend. 'I have another meeting at that time.' 'A customer called.' 'The President of the US wants to see me in 5 minutes.' You can't make this stuff up. Honestly, some of these 'distractions' are important. But the root cause: They do not think the Team is important and they have forgotten how to work as a Team. They do not see how the Team is going to help their career.
Jon Defriese thinks this is because the Leader, (in our case, the CEO) has not established the right culture. Often the Leader has not dealt well enough with these issues in his or her own head.
In any case: Daily Scrum. Daily. Answering the 3 questions. Slightly rephrased.
- • What did I (or my home team) do yesterday that helped the MS Team meet the Sprint Goal?
- • What will I (or my home team) do today to help the MS Team meet the Sprint Goal?
- • Do I (or my home team) see any impediment(s) that prevents me or the home team from meeting the Sprint Goal (of the MS Team)?
‘No impediments’ is almost never a reasonable answer. Unless the people are perfect and the situation around them is also perfect. Rarely does this happen. Anything that slows them down from a perfect and fast delivery (of any story) of the highest value is an impediment.
Also, they need to tell each other the truth at the Daily Scrums. (Stop that laughing! We are serious here.) Also, not make 'political' statements. And then, help each other.
Seriously, it can be tough to coach this team at first. Often they have totally forgotten how to work together with any team, and especially each other. Some of you have a better culture; so if you have that case, be mindful when a new person joins the MST, often he or she comes from a company with a very different culture. Give that person some time and some coaching to adjust.
Part 3 is next.
Thursday, December 17, 2015
Wednesday, December 16, 2015
Jeff Sutherland has recently done a great job in describing his ideas on scaling.
Here are a couple of things I think are key:
1. Scale down. That is, it is complex to get lots of people involved in one problem or effort. Simplify.
2. Use patterns.
3. There are alternatives. While there are some common patterns, and they can work, do not assume every pattern will fit your situation. Be judicious and experimental. Expect experiments may not work out well (for a variety of reasons, including ineffective execution).
Here are the modules. They include video and slides. See both.