My presentation at the 2010 Canterbury Software Summit

1. Agile ThinkingBecoming the best product development & management organization in your market Edwin Dando 26 October 2010

2. Why Agile Thinking? “Companies have discovered that it takes more than high quality, low cost, and differentiation to excel. It also takes speed and flexibility. This calls for a different approach.” “Traditional sequential or ‘relay race’ approach may conflict goals of maximum speed & flexibility.” “Instead, a holistic or ‘rugby’ approach— where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today's competitive requirements.” New, New Product Development Game, Hirotaka Takeuchi and IkujiroNonaka, Harvard Business Review (1986)

4. Clarus exclusive NZ business partner of Scrum co-creator Dr. Jeff Sutherland

5. Agile Coach

6. Using Agile/Scrum since 2002

7. Software consulting background

8. Accenture, Synergy, Gen-I, Vodafone, Telecom and Clarus

10. “Yeah, we Do Agile” Most implementations doing superficial Agile: ScrumBut Done properly, Scrum is a very good framework to help develop Agile thinking manage the cultural & organisational transition 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

11. Is Agile new? Theory of Constraints – Goldratt, 1984 The New New Product Development Game (1986) Empirical Process Control – centuries Toyota Production Systems and Just in Time – 1950’s Lean, TQM – Named as Lean in 1990’s Servant Leadership – 1970, Robert K. Greenleaf - “The Servant as Leader”

12. What is Agile Thinking? The philosophical concepts, based on the Agile Manifesto A way of being the best you can while managing change in a transparent, cooperative manner. Frameworks help us transition to Agile Thinking. Frameworks alone do not equal Agile Thinking.

13. Old approach to product development Relay race - one group of functional specialists passing the baton to the next Project goes sequentially from phase to phase Functions specialized and segmented Marketing people examine customer needs & perceptions in concept phase R&D engineers selected the appropriate design the production engineers put it into shape other functional specialists carried the baton at different stages of the race.

14. New approach to product development Product development process emerges from the constant interaction of a multidisciplinary team whose members working together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members' interplay Team may be forced to reconsider a decision as a result of later information. The team does not stop then, but engages in iterative experimentation. This goes on in even the latest phases of the development process.

15. Rugby Approach Source: The New New Product Development Game, Hirotaka Takeuchi and IkujiroNonaka, Harvard Business Review 1986

16. Findings This approach is essential for companies seeking to develop new products quickly and flexibly. The shift from a linear to an integrated approach encourages trial and error and challenges the status quo. It stimulates new kinds of learning and thinking within the organization at different levels and functions. Just as important, this strategy for product development can act as an agent of change for the larger organization. The energy and motivation the effort produces can spread throughout the big company and begin to break down some of the rigidities that have set in over time.

17. Characteristics of Agile Thinking Customer Centricity Transparency Accountability & Trust Kaizan culture Behaviours and feelings matter Team focus Servant Leadership Feedback

18. Customer Centricity We are in business to develop products for the customer Customer revenue pays our salaries. Attention turns to what the customer values Goodbye architecture for the sake of architecture & documentation for the sake of documentation. Hello challenges to accepted norms “But that is how we do software projects here!” “But does that actually of value to the customer?” Measurements change: customer satisfaction and cycle time Must have a customer representative XP – customer onsite Scrum – effective Product Owner

19. Transparency With transparency we can inspect and adapt Open tradeoffs on project constraints Scope versus budget versus schedule versus quality Open dialogue We are committed to doing the best possible and need open communication Goodbye business passing project to IT and coming back at the end. Hello open dialogue, transparency and trust Hello collaboration, change, adaption and commitment Hello increased likelihood of meeting expectations

20. Accountability & Trust Create backlog of prioritised product features Every iteration Meet and collaboratively agree to what can be delivered in the next iteration (features & tasks) Throughout Track progress in highly visible way Update backlog from using software, market feedback, changes etc End of iteration Meet to demonstrate delivery of teams commitments Openly inspect team approach seeking constant improvement Repeat until done

21. Kaizen Culture Constant improvement Challenge the status quo Retrospectives – critical part of inspect and adapt Open forum to honestly and transparently inspect ourselves as a team What are we doing well? What are we not doing well? How are we feeling? How can we improve?

22. Behaviours and feelings matter It is not all about Intelligence Quotient EQ is just as (if not more) important software mainly delivered by teams It is not all about you! My retrospectives Emotional seismograph Opportunity to discuss behaviours, communication Often new and unfamiliar, especially for engineers Social norms and team contracts

23. Team focus Focus on teams performance We are as good as our slowest member Tuckman’s research: teams go through 4 stages of development Forming - Individuals meet and learn about goals, opportunities. Little shared knowledge, no trust yet, strong desire for direction. Storming - Conflict and polarization around interpersonal issues, roles, goals, standards and processes. Norming - Team identity and cohesiveness develops, new standards evolve, and new roles are adopted. Performing - High degree of cooperation and interdependence. Goals are achieved smoothly and effectively with a minimum of conflict. Bruce Tuckman - 1965

24. Servant Leadership Create highly fertile environment that nurtures success allows constrained failure harnesses multiple perspectives to problem solving Removes impediments to the teams progress Environment Bureaucracy Interruptions and distractions Executive communication Organisational and cultural change

25. Feedback Constant feedback loops back into “the system” Product Owner Use the latest delivered version of the software Change your mind as you see fit (it is your cheque book) but not during the iteration Communicate clearly with the team Team Make a commitment then demonstrate delivery of it Review yourself regularly (suggestion: every iteration) Creative criticism focused on constant improvement

26. How do we think Agile? We have been schooled in relay race, hierarchical thinking. Changing this is difficult Behaviours required Courage Discipline Passion How we help our clients do it at Clarus Training: baseline knowledge for everyone Coaching: putting it into action Leadership: constantly improving by being Agile

27. Transitioning to being Agile is hard The most serious impediments to using Scrum are habits of waterfall, predictive thinking; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren't even aware of anymore. 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. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. Source: Ken Schwaber, Scrum is Hard and Disruptive, 2006

28. Transitioning to being Agile is hard 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 is needed. 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. 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. Source: Ken Schwaber, Scrum is Hard and Disruptive, 2006

29. ...but worth it 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. 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.

30. Questions ?

31. About Clarus We improve the business of IT Consulting – delivering outcomes Mentored Learning (injecting our IP into your via business training with mentoring) Project Resourcing Certified Scrum Training Project Quality Assurance Project & Technology Audit IT Management Business Continuity Agile Adoption & Coaching Business Analysis Software Testing Project Management Software Development & Architecture

32. Why Scrum? Source: Agile Tool Survey – August 2010

33. Who Uses Scrum?