Introduce the reasoning behind the title of the presentation. Can't Cook, Won't Cook was a UK game show and cooking programme that was broadcast on BBC1 on weekday mornings usually after the Breakfast News from 20 November 1995 to 7 July 2000. Format Two chefs (one of whom could not cook and one of whom would not cook) were nominated by a friend or relative to cook a meal under the instruction of a world class chef. When the dish was cooked, the nominator would be blindfolded and asked to taste the food. Following this, they would decide whose dish was best. In the event of a tie, the aforementioned chef would decide. Then once the winner has been decided the walls of the studio open up to reveal a prize (usually a food blender or set of saucepans). Chefs Over the years the programme featured several different host chefs, most predominantly Ainsley Harriott. However, other chefs such as Kevin Woodford, Lesley Waters, Richard Cawley, Tony Tobin occasionally took on the role. We intend to look at some of the reasons why some larger companies CAN’T or WON”T meet some of the organisational changes which Scrum promotes.
Green peppers and red tomatoes actually comes from the follow-up show “Ready, Steady, Cook”. But we intend to use that as an audience participation exercise. At certain points we will ask you to vote using the cards on your seats.
My mother in law thinks she can’t cook. My own experience would back that up! Father-in-law in control the kitchen No desire to improve She is consciously incompetent at cooking. By telling herself this for a number of years she is less likely to change her ways the older she gets. This is the same problem that larger organisations face. The longer a company has been around the less likely it is to change. The fact is that she never needed to improve cook better as her family has always been content with the food they ate. * Pandered to her insecurities My wife now has a permanent hatred for ‘casserole’, and never knew any different until she left home.
Comfortable Failure West Ham United. (Apologies to any hammers fans in the audience). 2005/6 – finished 9 th + FA Cup Runners Up 2006/7 – finished 15 th 2007/8 – finished 10 th 2008/9 – finished 9 th 2009/10 – finished 17 th Millions of pounds invested to ‘survive’ Being content with mediocrity. We are ‘just good enough’. Leads to de-motivated staff, lack of innovation and creativity, and compromised quality. Eventually though these organisations/teams will get overtaken massively and it will be impossible for them to compete. They will need massive re-investment just to survive. Now it looks like West Ham will fail to stay in the PL this year, from trying to keep their heads above water for the last 6 years. Financially they have been bought out by two separate investors in the last few years.
Co-location is not a mandatory part of Scrum but most companies say they CAN’T do this. It is a CHOICE. Scrum gives teams a very easy way to make the cost of disparate teams visible. Question: Do you think your company CAN’T or WON’T address Scrum’s desire for CO-LOCATED teams? CAN’T = RED TOMATOES WON’T = GREEN PEPPERS Vote Now. (Hopefully most people will say WON’T)
One solution: Standardise 3 teams velocities. Team 1 is co-located, Team 2 is mildly-dispersed, and Team 3 is widely-dispersed. Cost/Benefit analysis of those 3 approaches and publish results to senior/peer managers.
Measure wait time Queue of people in a post office waiting for “cashier number 3 please”
Question: Do you think your company CAN’T or WON’T address Scrum’s desire for DEDICATED teams? CAN’T = RED TOMATOES WON’T = GREEN PEPPERS Vote Now. (Hopefully most people will say WON’T)
Everything is equal priority, we CAN’T possibly stop doing projects B and C. Incorrect – you WON’T stop doing projects B and C. It’s easy to start projects but less easy to stop them. Reduce work in progress, too many companies spinning too many plates. Talk about BT directories and their portfolio rationalization exercise (Went from 40 to 10 projects – it’s a start). Scrum asks some really difficult questions around priority. Only the bravest will answer them. Measure and compare velocities of dedicated and non-dedicated teams. (The average BT team was 22% effective when measuring ideal day velocity) Measure and compare project length. Payback. Earned Value.
Whilst Scrum doesn’t mandate the use of agile engineering practices, it should quickly expose that you need some! Question: Do you think your company CAN’T or WON’T address Scrum’s desire for AGILE ENGINEERING PRACTICES? CAN’T = RED TOMATOES WON’T = GREEN PEPPERS Vote Now. (Hopefully most people will say WON’T)
Raising visibility of: Maintenance costs Technical Debt (Paul’s Tech Risk Quadrant?) Bug Criticality/Repetition/Numbers Manual Deployment/Integration Times Manual Testing Cost (cost to run a manual test team in China overnight against automated test runs, value analysis of bugs reported against cost of finding them)
Hogben’s CCG (over to Geoff)
Question: Do you think your company CAN’T or WON’T address Scrum’s desire for CROSS FUNCTIONAL/COMPONENT teams? CAN’T = RED TOMATOES WON’T = GREEN PEPPERS Vote Now. (Hopefully most people will say WON’T)
Paul’s Nokia story. By stealth. Cherry pick the project and the people. Bribe people. Highlight the benefits (pairing, kudos amongst peers) Establish who the key players are and get them onside. Some sheep will follow them. Choose the right people to make it work – eliminate the no-nos (Kotter). Create a succeeding culture – we can do this. Create common goals (and common penalties!) across component teams to encourage collaboration and decrease hand-offs. Rewarding skills sharing and broadening. Pick the right product owner who will support the idea and the team.
Publish and shout about the success (the people and the process) “ this was the best project I ever took part in” – Ben Surgison “ we actually delivered something which works” – Craig Hunter
Question: Do you think your company CAN’T or WON’T address Scrum’s desire for DEDICATED PRODUCT OWNERS? CAN’T = RED TOMATOES WON’T = GREEN PEPPERS Vote Now. (Hopefully most people will say WON’T)
Chicken & Egg If you have a PM, you are less likely to get a PO. If you don’t have a PO, you need the PM more. Vicious circle
This is likely to be controversial but that’s OK. “ You are less likely to find a dedicated Product Owner if you have a Project Manager on the team” – Geoff Watts So fire the project manager. Is the term “Agile Project Manager” preventing companies from challenging this? Comfort factor of having someone there who is “accountable” and “in control”.
Give your PM’s something to do – let them work their magic Organisational change Solving these issues Sorting out hardware lead times External interfaces – streamlining and aligning HR stuff Macro-level impediments
Don’t even talk about Scrum when trying to get a PO on board. Just talk about Earlier Payback Greater ROI Earlier deliveries Real products Competitive advantage Earned value
(Does this contradict previous slide?) Scrum puts importance and value on this role, so if Scrum is supported get your Product Owners recognised. The rest of the business sits up and listens and the individual POs feel a little more empowered and valued. Create a new Product Owner role in the organisation. HR policies are going to be affected so get them involved early.
“ The significant problems we have cannot be solved at the same level of thinking with which we created them” Albert Einstein “ As soon as you blame somebody else, you give up your power to change”
Managers won’t give up control Actively oppose agile adoption Scrum gives middle-management less control Turkey’s voting for Christmas? Some places I have bee have said DON’T DO IT as it would be like turkeys voting for Christmas - where people were being managed out, transparency was very dangerous for these peoples careers
There is a lot of talk about “pragmatic” agile. That just stinks of compromise. A camel is a horse designed by committee Or A camel is a pragmatic pony. This is usually the result of companies who WON’T Scrum. You end up with hundreds of compromises.
No large company has ever succeeded with an agile transformation. But… larger companies tend to want to ‘measure’ the progress of a Scrum adoption. They want a checklist for success . Trouble is, there is no blueprint for agile adoption – therefore success is very grey. This coupled with the threat of failure leads to inaction which is the worst type of action. Any decision is better than no decision. Many reasons why something WON’T work, but the instinctive reaction is that we CAN’T do it. Scrum principle - art of the possible . What’s the first baby step we can take which will have some value?
Scrum Values Commitment, Openess, Respect, Focus, COURAGE. Most people forget the values of Scrum or disregard them as being ‘too hippy’. But they are key to Scrum’s success. Leads to Spineless, Shallow Scrum . In this case people will be more willing to take a ‘pragmatic’ approach. We make a point of saying at the start of training/coaching gigs “ only do this if you are REALLY sure you want to .” There will be pain, it will be uncomfortable. Like a new pair of shoes. But if you tackle it head on with COMMITMENT, OPENESS, RESPECT, FOCUS and COURAGE the benefits to you, your colleagues, and your organisation will be extraordinary.
Test the water by asking for training & coaching If not, see what you can do internally Read up Join user groups/forums Set up internal sessions (brown bags, lightning talks, geek talks) Run your own “free” training sessions Ask for “cheaper” support (conference admission, books,
It’s time to acknowledge the elephant in the room I know what you have all been thinking all the way through this presentation… Where can I get a copy of those slides?
We need to end on a positive… As painful as it is for me to expose my poor drawing skills to an audience, I can now get some expert feedback on how to improve and they were actually good enough so when I thought “I can’t draw’ I was actually thinking “I wouldn’t draw. Everyone has the capacity within them to draw Every organisation has within them the capacity to change. Never forget that. Just because “that’s the way we do things round here” doesn’t mean they shouldn’t change. In fact it’s all the more reason to change