Agile thinking

3,117
-1

Published on

My presentation at the 2010 Canterbury Software Summit

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,117
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
49
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile thinking

  1. 1. Agile ThinkingBecoming the best product development & management organization in your market<br />Edwin Dando<br />26 October 2010<br />
  2. 2. Why Agile Thinking?<br />“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.”<br />“Traditional sequential or ‘relay race’ approach may conflict goals of maximum speed & flexibility.”<br />“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.”<br />New, New Product Development Game, Hirotaka Takeuchi and IkujiroNonaka, Harvard Business Review (1986)<br />
  3. 3. About Me <br /><ul><li>MD and founder of Clarus
  4. 4. Clarus exclusive NZ business partner of Scrum co-creator Dr. Jeff Sutherland
  5. 5. Agile Coach
  6. 6. Using Agile/Scrum since 2002
  7. 7. Software consulting background
  8. 8. Accenture, Synergy, Gen-I, Vodafone, Telecom and Clarus
  9. 9. Certified Scrum Practitioner and PMP</li></li></ul><li>“Yeah, we do Agile”<br />Doing Agile versus Being Agile<br />Doing = following the process and ticking boxes<br />Being = using it 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 />
  10. 10. “Yeah, we Do Agile”<br />Most implementations doing superficial Agile: ScrumBut<br />Done properly, Scrum is a very good framework to <br />help develop Agile thinking <br />manage the cultural & organisational transition<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 />
  11. 11. Is Agile new?<br />Theory of Constraints – Goldratt, 1984<br />The New New Product Development Game (1986)<br />Empirical Process Control – centuries<br />Toyota Production Systems and Just in Time – 1950’s<br />Lean, TQM – Named as Lean in 1990’s<br />Servant Leadership – 1970, Robert K. Greenleaf - “The Servant as Leader”<br />
  12. 12. What is Agile Thinking?<br />The philosophical concepts, based on the Agile Manifesto<br />A way of being the best you can while managing change in a transparent, cooperative manner. <br />Frameworks help us transition to Agile Thinking. <br />Frameworks alone do not equal Agile Thinking.<br />
  13. 13. Old approach to product development<br />Relay race - one group of functional specialists passing the baton to the next<br />Project goes sequentially from phase to phase<br />Functions specialized and segmented<br />Marketing people examine customer needs & perceptions in concept phase<br />R&D engineers selected the appropriate design<br />the production engineers put it into shape<br />other functional specialists carried the baton at different stages of the race.<br />
  14. 14. New approach to product development<br />Product development process emerges from the constant interaction of a multidisciplinary team whose members working together from start to finish.<br />Rather than moving in defined, highly structured stages, the process is born out of the team members' interplay<br />Team may be forced to reconsider a decision as a result of later information.<br />The team does not stop then, but engages in iterative experimentation.<br />This goes on in even the latest phases of the development process.<br />
  15. 15. Rugby Approach<br />Source: The New New Product Development Game, Hirotaka Takeuchi and IkujiroNonaka, Harvard Business Review 1986<br />
  16. 16. Findings<br />This approach is essential for companies seeking to develop new products quickly and flexibly.<br />The shift from a linear to an integrated approach encourages trial and error and challenges the status quo.<br />It stimulates new kinds of learning and thinking within the organization at different levels and functions.<br />Just as important, this strategy for product development can act as an agent of change for the larger organization.<br />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.<br />
  17. 17. Characteristics of Agile Thinking<br />Customer Centricity<br />Transparency<br />Accountability & Trust<br />Kaizan culture<br />Behaviours and feelings matter<br />Team focus<br />Servant Leadership<br />Feedback<br />
  18. 18. Customer Centricity<br />We are in business to develop products for the customer<br />Customer revenue pays our salaries. <br />Attention turns to what the customer values<br />Goodbye architecture for the sake of architecture & documentation for the sake of documentation. <br />Hello challenges to accepted norms<br />“But that is how we do software projects here!”<br />“But does that actually of value to the customer?”<br />Measurements change: customer satisfaction and cycle time<br />Must have a customer representative<br />XP – customer onsite<br />Scrum – effective Product Owner<br />
  19. 19. Transparency<br />With transparency we can inspect and adapt<br />Open tradeoffs on project constraints <br />Scope versus budget versus schedule versus quality<br />Open dialogue<br />We are committed to doing the best possible and need open communication<br />Goodbye business passing project to IT and coming back at the end.<br />Hello open dialogue, transparency and trust<br />Hello collaboration, change, adaption and commitment<br />Hello increased likelihood of meeting expectations<br />
  20. 20. Accountability & Trust<br />Create backlog of prioritised product features<br />Every iteration<br />Meet and collaboratively agree to what can be delivered in the next iteration (features & tasks)<br />Throughout<br />Track progress in highly visible way<br />Update backlog from using software, market feedback, changes etc<br />End of iteration <br />Meet to demonstrate delivery of teams commitments<br />Openly inspect team approach seeking constant improvement<br />Repeat until done<br />
  21. 21. Kaizen Culture<br />Constant improvement<br />Challenge the status quo<br />Retrospectives – critical part of inspect and adapt<br />Open forum to honestly and transparently inspect ourselves as a team <br />What are we doing well?<br />What are we not doing well?<br />How are we feeling?<br />How can we improve?<br />
  22. 22. Behaviours and feelings matter<br />It is not all about Intelligence Quotient<br />EQ is just as (if not more) important <br />software mainly delivered by teams<br />It is not all about you!<br />My retrospectives<br />Emotional seismograph<br />Opportunity to discuss behaviours, communication<br />Often new and unfamiliar, especially for engineers<br />Social norms and team contracts<br />
  23. 23. Team focus<br />Focus on teams performance<br />We are as good as our slowest member<br />Tuckman’s research: teams go through 4 stages of development<br />Forming - Individuals meet and learn about goals, opportunities. Little shared knowledge, no trust yet, strong desire for direction. <br />Storming - Conflict and polarization around interpersonal issues, roles, goals, standards and processes.<br />Norming - Team identity and cohesiveness develops, new standards evolve, and new roles are adopted.<br />Performing - High degree of cooperation and interdependence. Goals are achieved smoothly and effectively with a minimum of conflict.<br /> Bruce Tuckman - 1965<br />
  24. 24. Servant Leadership<br />Create 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 />
  25. 25. Feedback<br />Constant feedback loops back into “the system”<br />Product Owner<br />Use the latest delivered version of the software<br />Change your mind as you see fit (it is your cheque book) but not during the iteration<br />Communicate clearly with the team<br />Team<br />Make a commitment then demonstrate delivery of it<br />Review yourself regularly (suggestion: every iteration)<br />Creative criticism focused on constant improvement<br />
  26. 26. How do we think Agile?<br />We have been schooled in relay race, hierarchical thinking. <br />Changing this is difficult<br />Behaviours required<br />Courage<br />Discipline<br />Passion<br />How we help our clients do it at Clarus<br />Training: baseline knowledge for everyone<br />Coaching: putting it into action<br />Leadership: constantly improving by being Agile <br />
  27. 27. Transitioning to being Agile is hard<br />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.<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 enterprises 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 />
  28. 28. 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 is 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 />
  29. 29. ...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 />
  30. 30. Questions<br />?<br />
  31. 31. 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 />
  32. 32. Why Scrum?<br />Source: Agile Tool Survey – August 2010<br />
  33. 33. Who Uses Scrum?<br />

×