Download to read offline
Uploaded byJohn McIntyre
If agile is so great, why do we constrain it to software projects
This document discusses applying Agile principles and practices beyond software projects. It provides a timeline of Agile's development and defines key Agile concepts. The document advocates targeting business areas wanting change, training them in Agile techniques, and coaching them to define and measure success through iterations. Visual boards and simple messages are recommended. Adopting Agile ensures continuous optimization of investments. Key points include modeling Agile in PMOs, focusing on willing teams, and coaching the incremental learn-apply process.
More Related Content
Similar to If agile is so great, why do we constrain it to software projects
If agile is so great, why do we constrain it to software projects
- 1. If Agile isso great, why do we constrain it to software projects?
- 2. Who here woulddescribe themselves as Agile
- 3.
- 4. Timeline of Agile 19902001 2009 2010 2011
- 5. Timeline of Agile 19131978 19861930
- 6.
- 7. Agile is nota noun! • Nouns – People, Places, Animals, Things • Adjectives – Describe nouns Fast! Rapid! Quick!
- 8. Agile is simple •Take small steps and adjust your understanding based on what you have learned.
- 9. Agile is simple •Take small steps and adjust your understanding based on what you have learned. • Not sure what to do? Take the path that makes future change easier.
- 10.
- 11.
- 12. We are doingthe business a disservice
- 13.
- 14. Unshackle the AgileManifesto Delivering Value
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. What does anAgile Culture look like? • Does understanding Scrum make me Agile?
- 21. What does anAgile Culture look like? • Does understanding Scrum make me Agile? • Agile Processes and tools are the install mechanisms for culture
- 22. What does anAgile Culture look like? • Does understanding Scrum make me Agile? • Agile Processes and tools are the install mechanisms for culture • Performant Agile teams: • Generalists – not specialists • “change is cool” • Work as a team • Learn from mistakes • Measure their performance
- 23. Target areas ofyour business who want to change Who hasn’t had that awkward moment when they push the door when it clearly says ‘pull’?
- 24. Train them inAgile Techniques
- 25. Leader Manager MentorTrainer Coach Set vision andensure resources Define processes Track Progress, Measure team productivity Share how we have done this in other markets Teach new skills to increase our chances of delivering the project Work with the team to maximise attitude, effort and production All roles are essential to achieve the goal Then Mentor & Coach
- 26. Drink your ownChampagne!
- 27. How do wemeasure success? • You don’t. They Do. You are not creating more KPIS for yourselves, you are enabling the business!!!
- 28. How do wemeasure success? • Work Done per Iteration • Work committed vs work done • # Actions completed from Retrospectives • Attendance at Demos
- 29. Visual boards andsimple messages • Iteration Objectives clearly stated. To Do Doing Done
- 30. What about thosewho say it won’t work?
- 31.
- 32. “Adopting agile principlesand practices in your marketing capitalizes on value that has been proven through the software delivery industry and that closely aligns with needs of marketers. Building an agile foundation of practice ensures that you are continuously maximizing and optimizing the marketing investment.” - Roy Huhta, Chief Product Officer at digital media and marketing agency West Cary Group
- 33. Key Points • ModelAgile in your PMO • Focus on teams who really WANT Agile first (Pull process) • Teach them agile tools and techniques • Help them shape their backlog and make it visible • Coach them to define their KPIs and get into that increment-learn-increment way of working.
- 34. Further Reading Enjoyed thispresentation? You may find the following links interesting: • I blog regularly about all things PMO at https://www.hotpmo.com/ • What is Agile HR? http://www.hrsg.ca/what-is- agile-hr-and-is-it-right-for-you/ • Applying Agile to Marketing - http://www.agilemarketing.net/what-is-agile- marketing/
Editor's Notes
- #3 Who would describe themselves as Agile? Question to the room – show of hands – Are you Agile? Are your team Agile? What does Agile even mean? In PMO-world we tend to associate the term ‘Agile’ With software projects that aren’t very well defined up front… Let’s look into it a bit more….
- #4 A good place to start is probably the Agile Manifesto. At least you’d thing so? But there is a problem. The Agile Manifesto is WRONG! (explain software reference) How many people here who put their hands up and said they were Agile, are, right now, developing software? Because if you look closer at the Manifesto – it is explicitly about delivering software. “Manifesto for SOFTWARE development”, “Working Software” over comprehensive documentation. So maybe the Agile Manifesto is not such a good starting point.
- #5 From origins in software, moving to Agile, Scrum. Agile Manifesto moving to lean. – see how we’ve moved from waterfall project management to something that looks a lot like a manufacturing line. Scum conceived – 1990 (Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX (now GE Medical).) Agile Manifesto – 2001 PMI Agile COP – 2009 (Which lead to the PMI Agile Certified Practitioner program in 2011) First Scrum Guide – 2010
- #6 From origins in software, moving to Agile, Scrum. Agile Manifesto moving to lean. – see how we’ve moved from waterfall project management to something that looks a lot like a manufacturing line. Back further– we see that what we call Agile today draws heavily on 1930 - physicist and statistician Walter Shewhart of Bell Labs began applying Plan-Do-Study-Act (PDSA) cycles to the improvement of products and processes. He went on to teach Deming who used it to great effect at Toyota 1975 – (post WW2) Taiichi Ohno developed the Toyota Production System – Muda removal and continuous improvement. 1986 – the New New Product Development Game (Harvard Business Review) - Hirotaka TakeuchiIkujiro Nonaka, Studying manufacturers that were releasing successful innovations far faster than competitors, the authors identified a team-oriented approach that changed the design and development process for products such as copiers at Fuji-Xerox, automobile engines at Honda, and cameras at Canon. Rather than following conventional “relay race” methods of product development — in which one group of functional specialists hands off its completed phase to the next functional stage — these companies were using what Takeuchi and Nonaka called a “rugby” approach, “where a team tries to go the whole distance as a unit, passing the ball back and forth.” Crucially, none of these innovative ideas involved the ‘S’ word – SOFTWARE. 1913 – Mass Production at Ford. - Ford was another pioneer of what we look at today as Agile. The mass production models align heavily with the models use in agile today – teams focussed on delivering software at regular intervals in the same way as a manufacturing plant may.
- #7 .So as we move towards a model where we deliver project deliverables using operational models, what we do is build in Agility. We make it easier to change, easier to switch. Whilst we know that Ford famously made his car available in ‘any color you like as long as its Black’, he could have switched colours quickly and started rolling out pink cars simply by adding new paint – without having to go back to the drawing board. In fact, for those who are in the service industry – you we are in an even better position. We don’t need to invest in machining or any other the other capital overheads that Ford had to deal with. We can keep the production line model of delivering iteratively – regardless of what the business needs. We use the tools and techniques that we call ‘Agile’ to give our businesses ‘Agility’ to make them nimble. To get to market faster.
- #8 In a sense we’ve gone full circle here too – As agile is seen more as a noun, we differentiate and start talking about Aility instead – Agility is at the heart of what we are trying to achieve. It is at the heart of what PMOs do. External people may look at PMOs and see us as a policing function, a control function, a team that generates process and red taps – but we know, WE KNOW that in reality, the PMO is here to make it faster to do things. To make decisions rapidly. To make the right decisions first time to avoid timewasting. To make it easier to get things done. In the truest meaning of the term, our PMOs are enablers for Agile and Agility. Are you Agile? No. You are you. Can you be described as Agile? Yes. And can you help teams in your organisation get to the point where they can describe themelves as an agile team? Absolutely yes.
- #9 But when you strip it back – agile is simple. Take small steps and adjust your understanding based on what you have learned. Not sure what to do? Take the path that makes future change easier.
- #10 But when you strip it back – agile is simple. Take small steps and adjust your understanding based on what you have learned. Not sure what to do? Take the path that makes future change easier.
- #11 Two sides with a reveal – we change software using an iterative model – Scrum, DSDM, Kanban – whatever. We do it incrementally. But how do we change the business? KOTTER!
- #12 Kotter 8 step model that looks like this – it’s a waterfall. So as we saw in our timeline, we’ve known since the 1980s that incremental is better, yet we – PMO, project managers, business schools, continue to insist that we change the business with an 8 step waterfall process. WHY???
- #13 By doggedly sticking with Kotter, whilst limiting Agile to software, we are doing the business a disservice. We are not doing our jobs properly! Kotter should be relegated to history.
- #15 Cut the word software out of it. Start talking about delivering value across the business.
- #16 With small, incremental change. Learning as we go. Where do you start? Learn from mistakes, Small steps, adjust understanding as you go.
- #17 Learning is a big part of Agile, this idea of constantly learning and refining. So we’re going to look at some research. Why do Agile implementations fail? CULTURE
- #18 Of those who contributed to the report, 87% said the top benefit was ability to manage changing priorities 85% said it increased team productivity 84% said it improved project visibility. Why would we limited those kind of benefits to our IT teams?
- #19 Learning is a big part of Agile, this idea of constantly learning and refining. So we’re going to look at some research. Why do Agile implementations fail? CULTURE
- #20 Learning is a big part of Agile, this idea of constantly learning and refining. So we’re going to look at some research. Why do Agile implementations fail? CULTURE
- #21 Understanding scrum doesn’t make me agile – in the same way that just because I understand the concept of the Atkins diet – I am not slim
- #22 The tools and process that Agile frame works have sort to codify are the install mechanisms for the culture. Get your team working together in certain ways and tracking certain metrics then you are putting the building blocks in place for that culture.
- #23 The tools and process that Agile frame works have sort to codify are the install mechanisms for the culture. Get your team working together in certain ways and tracking certain metrics then you are putting the building blocks in place for that culture.
- #24 Pull process – not push Talk about why you need to focus on the teams that want it – then let others come to you.
- #25 Whilst the manifesto says ‘Software’ the tools of the trade are flexible. Iterations, Retrospectives, Daily meetings. And the whole team working to common goals
- #27 How are the PMO able to coach and mentor? By drinking their own champagne – by being Agile themselves. Be a change agent for the company – you need to build relationships and people should be happy with their PMO.
- #29 Some generic examples – include happiness.
- #31 Remind everyone of the triple constraint. Show me a team that doesn’t have a time and cost constraint each month . If they have fixed time and fixed resources, then Agile is the only way to go, because the only lever you have left is scope. Agile lets you flex scope by prioritising a backlog and working your way down.