1.
Distilled wisdom from the coalface:Our lessons implementing Scrum<br />Clarus <br />26 May 2011<br />

2.
“Yeah, we do Agile”<br />Doing Agile versus Being Agile<br />Doing = following the process, executing the mechanics without understanding the philosophy<br />Being = using the philosophy to become the best product development & management organization in your market<br />The right thinking is needed to get there. This is why it is hard. <br />

3.
Why Scrum?<br />Accessible, well-defined, established way to start on your Agile journey<br />Clearly defined roles (and only three of them)<br />Clear process (you are either doing Scrum or not)<br />Well established community (over 60,000 CSM’s worldwide)<br />Established support bodies<br />Scrum works <br />But being brave enough to change your business is hard…<br />

4.
Why Scrum?<br />2<br />2<br />2<br />3<br />3<br />4<br />4<br />5<br />58<br />17<br />Source: State of Agile Development – Aug 2010<br />

5.
Tonight<br /><ul><li>Our experience implementing Scrum across over a dozen New Zealand companies

6.
Corporates to SME’s

7.
Varying cultures, businesses, needs

8.
Various challenges – it is always different</li></li></ul><li>About Us<br /><ul><li>Founded 2006

9.
Christchurch HQ and (new) Auckland branch

10.
Agile, Business Analysis, Testing, Development, Project Management

11.
Official and exclusive business partner of Scrum Foundation (Dr Jeff Sutherland – co-creator of Scrum)

12.
Edwin has worked with Jeff Sutherland, Ken Schwaber, Gabrielle Benefield, Jens Ostergaard and Kane Mar </li></li></ul><li>1. Scrum is simple, implementing it is hard<br />Implementing Scrum implementing a framework<br />Implementing Scrum = business change<br />Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into the best product development and management organization in its market. – Ken Schwaber, co-inventor of Scrum<br />

13.
Why is implementing Scrum hard?<br />People – we are Complex creatures …<br />Change – looking in the mirror and facing the truth is hard<br />Business – why are we here again? And what are we doing? And what is really important?<br />

14.
Why it’s hard: People<br />Software is a social process - it is all about people<br />People form groups and groups establish norms<br />Scrum starts small but challenges accepted norms, rules, rituals and cultures<br />Behaviour and culture - ARRGHH!<br />Huh? How I act impacts productivity? But I am an engineer – we are what we are!<br />

15.
Why it’s hard: People<br />People are often not used to <br />holding each other accountable<br />challenging each other<br />having the freedom to define the “how”<br />making their own estimates<br />making and keeping commitments<br />Clare will talk more on people<br />

16.
Why it’s hard: Business<br />Business has been built on years of false assumptions and Industrial Age thinking (relay race, the Illusion of Predictability, communicating via documents, centralised control, directive management, -all accepted norms!)<br />Lots of bad habits to undo<br />Change this on a large scale is hard<br />Increased transparency often results in attrition, conflict and misery<br />

17.
Business: time to face the facts<br />Scrum forces the business to<br />state what is and isn’t important (most struggle)<br />be committed to organisational improvement<br />Ask: What are we in business for? Is it to develop products for the customer or something else?<br />Attention turns to what the customer values<br />And we start to challenge accepted norms<br />“But that is how we do software projects here!”<br />“Yeah, but does that add value to the customer?”<br />Measurements change: customer satisfaction and cycle time<br />Must have a customer representative: effective Product Owner<br />

18.
Example: time to face the facts<br />We know that only 7% of human communication is the message content<br />We know that the remaining 93% is based on the body language, context and voice tone<br />So why do we try to communicate via the 7%?<br />Email, documents, requirements documents, Gantt charts & memos<br />Seriously - are we insane?<br />

19.
Example - the Truth Hurts<br />This is why co-location is important<br />Radical drop off at up to 10 meters<br />Note – little difference between 100 meters and 100 kilometres<br />

20.
And the engineers…<br />Customer revenue pays our salaries<br />You have a contract to sell your time for money<br />The company (Product Owner) prioritises the work (the “what”)<br />Don’t assume it is fine to work on whatever you want.<br />If it isn't on the board we are not working on it<br />

21.
The Product Owner (business) decides “the what” (with your input)<br />The Team decides “the how”<br />But what happened to our autonomy? <br />

22.
2. The Product Owner role<br />IMHO the most important role in Scrum – vital for success<br />Commonly the most poorly implemented role in Scrum<br />Most implementations have either<br />no/ineffective Product Owner<br />Product Owner that doesn’t understand their role<br />The Business decides what it wants and prioritises<br />The Business and Team select the work for the Sprint.<br />The Team figures our “the how” (the Sprint Backlog)<br />The Business then needs to support minimal change, disruption and interference<br />Typically most businesses struggle to do this as they have years of bad habits to undo first<br />

23.
2. The Product Owner role<br />Lack of product owner results in<br />Going really fast to the wrong place<br />Team perceiving a lack of skin in the game from business<br />Lack of direction, vision and purpose<br />Lack of understanding of the customer<br />Typically, the first thing we address = the Product Owner<br />Lack of quality Product Ownership = one of the biggest issues in Scrum world<br />

24.
Good (& new) PO sends right message<br />If it isn't on the board we aren't doing it<br />If anyone asks you to do anything that isn't on the board then tell me<br />All work goes on the backlog & and is prioritised<br />Result = everyone rowing in the same direction, less interruptions, increased velocity <br />Bad PO sends the wrong message:<br />Arms folded and big sigh : “god I wish I didn’t have to attend these meetings. I have so much other stuff to do. You guys know what needs doing for the next Sprint – right? So why do you need me here?”<br />Result = demoralised team, Team not sure what to work on<br />“this project isn't that important”<br />Importance of the PO – real example<br />

25.
3. People<br />“Individuals and Interactions over processes and tools ”<br />- Agile Manifesto<br />“Knowledge workers are volunteers”<br />- Mary Poppendiek<br /> True motivation—autonomy, mastery, and purpose<br />- Daniel Pink, Drive<br />

26.
3. People!<br />Culture Change<br />Breaking negative cycles<br />Learning new skills<br />

27.
Culture change<br />Picture: Agustin Fest, wastingtime, http://www.flickr.com/photos/arboltsef/12718572/<br />

28.
Culture change<br />Picture: Writing Exams, http://www.flickr.com/photos/cristic/359572656/<br />

29.
Agile world view<br />Consensus<br />Collaboration<br />Team work<br />But what have I achieved? <br />

30.
Culture change<br />http://claremclennan.blogspot.com/2005/12/white-water-circus-project.html<br />

31.
Culture change<br />Out of depth?<br />

32.
Breaking negative cycles<br />©Cameron McEwing<br />

33.
Flow<br />Carlos Lorenzo, Cello Player,http://www.flickr.com/photos/carlos_lorenzo/1116911851/<br />

34.
Flow<br /><ul><li>Challenging activity that requires skill

35.
Clear goal

36.
Feedback</li></ul>“Flow” concept by MihalyCsikszentmihalyi. Drawn by SeniaMaymin<br />

37.
Who has control?<br />U.S. Navy, Sailors position aircraft in the flight deck control center, http://www.flickr.com/photos/usnavy/5405479774//<br />

38.
One good thing<br />Heather (Gruber) Williams, the daily standup, http://www.flickr.com/photos/heathershacienda/194577079/<br />

39.
Reorganise<br /><ul><li> Depressive Pessimist

40.
Jerk (Criticiser)

41.
Slacker

42.
Brake</li></ul>Study: Will Felps<br />Source: Jeff Atwood, Coding horror http://www.codinghorror.com/blog/2009/02/the-bad-apple-group-poison.html<br />Picture:Clan UiBrian, Bad Apple!, http://www.flickr.com/photos/uibriain/572588546/<br />

43.
Clare’s lesson<br />“But you’re wrong, you’ve forgotten about...”<br />“Absolutely, I agree with most of what you are saying. However there is one point I’d like to discuss more...”<br />

44.
Learning new skills<br />“And now for the really good news. The skills required to master high-stakes interactions are quite easy to spot and moderately easy to learn”<br />Pg 25, Kerry Patterson et al, Critical Conversations<br />

45.
Dialogue skills are learnable<br />Silence and violence<br />Suckers choice<br />Victim – It’s not my fault<br />Mutual Purpose<br />Appreciative Enquiry<br />Paraphrasing<br />

46.
4. The changing role of management<br />People don't set out to fail each day - they set out to succeed <br />Successful managers create an environment for success, empower their people and then stand aside <br />Servant leadership<br />Define the "what" not the "how"<br />Accept that people don't work for money, they work for AMP<br />Autonomy, Mastery, Purpose<br />The world is changing and Gen-Y are helping challenge the status quo<br />Manage them as you would a team of volunteers<br />

47.
Servant Leadership<br />Create a highly fertile environment that <br />nurtures success<br />allows constrained failure<br />harnesses multiple perspectives to problem solving<br />Removes impediments to the teams progress<br />environment<br />bureaucracy<br />interruptions and distractions<br />executive communication<br />organisational and cultural change<br />

48.
5. Quality<br />Ian – over to you<br />

49.
6. Governance & Accountability<br />How to get things done with no power<br />Transparency is the key<br />Organisational impediments <br />stuff the governance group can help us resolve<br />put the facts on the table<br />let the executives make the decisions<br />Include HR (culture, people), marketing, R & D, IT, support etc…<br />

50.
7. Benefits of Scrum<br />Often sold (bought?) on productivity gains<br />Real benefits are:<br />Increase visibility<br />`Empirical data provides visibility and increased predictability<br />Increased predictability<br />Increased quality<br />Engaged staff<br />However don’t forget – attrition is common at first<br />

51.
8. From the horses mouth:<br />“While all the books on Scrum tell you this, you don't really appreciate how powerful the process is until you do it. We used to have the standard weekly one hour one-on-one meeting, which frankly has about 1% as useful as the communication we now get from Scrum daily.” <br />“The best thing about using Scrum is knowing exactly where we are at and what we are doing as a team. We can now rectify issues and see results immediately thanks to Scrum's feedback.”<br />

52.
Transitioning to being Agile is hard<br />Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.<br />The role of an enterprise’s management changes from telling people what to do to leading and helping everyone do their best to achieve goals.<br />Source: Ken Schwaber, Scrum is Hard and Disruptive, 2006<br />

53.
Transitioning to being Agile is hard<br />Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centres on the changes in the enterprise that are needed.<br />Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.<br />The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.<br />Source: Ken Schwaber, Scrum is Hard and Disruptive, 2006<br />

54.
...but worth it<br />I am indebted to you, Agile & <company name> - I find IT fun again. I was seriously investigating making a career change and had dabbled in lecturing last year; the way the BA role was going at <old job> and other corporates, it just wasn't fun or rewarding. This is the most fun and job satisfaction I've had for at least 7 years. I like how we can all cross over into each other's domain at any time, if that's what it takes to get something done. You've put together a great team that knows how to deliver but still enjoys themselves every step of the way.<br />You have left us (and me personally) with a small revolution in the way we work here. Agile is just what we need here to re-build our teams and re-focus this company. Thank you.<br />

55.
Questions<br />?<br />Don’t forget upcoming training:<br /><ul><li>Certified Scrum Product Owner - Christchurch 25 & 26 July

56.
Certified Scrum Master - Christchurch 11 & 12 Aug </li></ul>Also<br /><ul><li>Certified Scrum Master - Auckland 08 & 09 Aug

57.
Certified Scrum Master - Wellington 15 & 16 Aug </li></li></ul><li>About Clarus<br />We improve the business of IT<br />Consulting – delivering outcomes<br />Mentored Learning (injecting our IP into your via business training with mentoring)<br />Project Resourcing<br />Certified Scrum Training<br />Project Quality Assurance<br />Project & Technology Audit<br />IT Management<br />Business Continuity<br />Agile Adoption & Coaching<br />Business Analysis<br />Software Testing<br />Project Management<br />Software Development & Architecture<br />