Agile is easy! It's making it work with your business that is hard
•
2 gostaram•1,007 visualizações
A talk about the next level of Agile adoption. How do we make it work for our business? How does Agile adoption affect our R&D, our sales, our product management and ultimately our business success?
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (11)
Semelhante a Agile is easy! It's making it work with your business that is hard
Semelhante a Agile is easy! It's making it work with your business that is hard (20)
Mais de Vasco Duarte
Mais de Vasco Duarte (9)
Último
Último (20)
Agile is easy! It's making it work with your business that is hard
- 1. Vasco Duarte, Turku Agile Day 2010 Agile is easy. Making it work for your business is hard!
- 2. Vasco Duarte @duarte_vasco in internet-speek
- 4. Vasco
- 7. 90% Agile Projects are 37% Faster to Market than Industry Average Said Agile either improved or significantly improved their ability to manage changing priorities 2009 data, VersionOne Evidence mounts: Agile works and is being widely adopted 83% No: 18.5% Of respondents showed either improvement or significant improvement in project visibility Yes: 81.5% 2009 data, VersionOne 2007 data, VersionOne
- 8. Question: how do I make it work for me and for my business?
- 9. Ken Schwaber: 75% of organizations fail to benefit from Agile/Scrum as expected http://www.agilecollab.com/interview-with-ken-schwaber
- 10. Two Challenges: 1 How do I adopt Agile? 2 How do I make it benefit my business?
- 11. Would be nice: Have a model to adopt Agile and benefit my business
- 12. Agile adoption is hard, long term. But there are some lessons we’ve learned by having done this for many years.
- 13. Step 1: Pilot projects Introduce the method in a way that does not risk your business, a safe experiment Provide a learning opportunity for your people. Making sure that they learn the method in a lower risk environment Increase your knowledge of what are the likely consequences of Agile adoption in your environment. Understand your context deeply
- 14. Step 1a: Use output from Pilot Projects to prepare wider adoption
- 15. Lesson Learnt 1: Pilot Projects succeed because they are isolated and different!
- 16. Taking Agile to the rest of R&D is different than running Pilot Projects…
- 18. Step 2: Consider the impact on the whole R&D!
- 19. Lesson Learnt 2: Different clock cycles in the organization lead to conflict
- 20. Lesson Learnt 3: Align goals across projects and teams that must cooperate
- 21. Lesson Learnt 4: Agile requires Timeboxes. Drop waterfall now!
- 22. Step 2a: Synchronize projects across the whole R&D!
- 23. Lesson Learnt 5: Product Owners/Product Managers must serve R&D needs!
- 24. Lesson Learnt 6: As you need to support Agile adoption you need to consider the R&D boundaries
- 25. Lesson Learnt 7: As you bump into obstacles from other organizations you need to align goals. Do you have a cross-company goal for Agile adoption?
- 26. Step 2b: Include Product management in R&D. We develop products, not software!
- 27. Lesson Learnt 8: R&D can only improve speed of execution. Other parts of the company need to take advantage of it!
- 28. all your products are belong to us!
- 29. Lesson Learnt 10: R&D alone cannot improve your business!
- 30. The 1,000,000 Euro question: How do I make Agile work for my Business?
- 33. Lesson Learnt 11: Sales and portfolio management work with “long term, non-negotiable” roadmaps. R&D cannot work with those
- 34. Lesson Learnt 12: Agile R&D teams can iterate fast towards the wrong product
- 35. Step 3a: Have a Vision in place for every project that is shared across the whole organization!
- 36. Lesson Learnt 13: Projects where the goal is clear are more innovative and engage the whole team
- 37. Step 3b: Link your project Visions to your company’s strategy
- 38. Lesson Learnt 14: Agile adoption in R&D uncovers problems elsewhere
- 39. Step 3c: Align all business units with the goals for Agile adoption
- 40. Lesson Learnt 15: Competitors are improving also. Make the improvement your agenda – long term!
- 43. 3b: Link your project Visions to strategy
- 44. 3c: Align all business units with the goals for Agile adoptionLesson 11: Sales and portfolio management work with “long term, non-negotiable” roadmaps. R&D cannot work with those Lesson 12: Agile R&D teams can iterate fast towards the wrong product Lesson 13: Projects where the goal is clear are more innovative and engage the whole team Lesson 14: Agile adoption in R&D uncovers problems elsewhere Lesson 15: Competitors are improving also. Make the improvement your agenda – long term!
- 45. The key issue: We need a modelbased on experience that helps achieve a business improvement
- 46. HOLISTIK We need a business-oriented approach to Agile adoption
- 47. Here’s a tip you can take to the bank: Hire someone who has done it before.
- 48. Lesson 4: Agile Requires Timeboxes, drop waterfall now! Lesson 1: Pilot Projects succeed because they are isolated! Lesson 3: Align goals across teams and projects that must cooperate Lesson 10: R&D alone cannot improve your business Lesson 8: R&D can only increase speed, others still need to take advantage of it Lesson 2: Different clock cycles in the organization lead to conflict Step 1: Pilot Projects Step 2: Consider the impact in the whole R&D Step 3: Deliver value by considering the whole system. Optimize the system! Lesson 6: Reconsider your R&D boundaries Lesson 5: Product Owners must serve R&D needs Lesson 9: Portfolio decisions are too slow and not stable enough Lesson 7: Align goals for Agile adoption across the whole organization Lesson 11: Sales and portfolio management work with “long term, non-negotiable” roadmaps. R&D cannot work with those Lesson 13: Projects where the goal is clear are more innovative and engage the whole team Lesson 14: Agile adoption in R&D uncovers problems elsewhere Lesson 12: Agile R&D teams can iterate fast towards the wrong product Lesson 15: Competitors are improving also. Make the improvement your agenda – long term!
- 49. Currently an Agile Coach in Nokia, Vasco Duarte is an experienced product and project manager, having worked in the software industry since 1997. Vasco has also been an Agile practitioner since 2004, he is one of the leaders and a catalyst in the adoption of Agile methods and an Agile culture at Nokia and previously at F-Secure. Vasco's contributions to the improvement of the software development profession can be read in his blog: http://softwaredevelopmenttoday.blogspot.com. You can follow Vasco on twitter: @duarte_vasco Foto credits: Flickr users http://www.flickr.com/photos/snips/72812469/ http://www.flickr.com/photos/will-lion/3133263572/ http://www.flickr.com/photos/66164549@N00/3005367325/ http://www.flickr.com/photos/ecstaticist/2589723846/ http://www.flickr.com/photos/celinet/606291449/ http://www.flickr.com/photos/datadevil/1344989797 http://www.flickr.com/photos/katphotos/2216663973/ http://www.flickr.com/photos/markkilner/2069380415 http://www.flickr.com/photos/clintjcl/2722008496 http://www.flickr.com/photos/mikelo/534441248 http://www.flickr.com/photos/muehlinghaus/3505426440
Notas do Editor
- I'll start right away with the lessons learned. Are you ready: you can start taking notes, because this stuff is precious. This is a talk about the real process of adoption Agile, failing, then trying again. The stories in this presentation are collections from several companies where I've worked at and that I've interacted with. At the end you will have the solution for all of your problems, don't worry! :)
- The facts are most companies have or are considering adopting Agile (typically in their R&D) Agile delivers more visibility (83% of the case), faster time to market (37% shorter time-to-market), responsiveness to change (90%)The evidence is clear. Agile is being widely adopted, and now the question for you who work in software organizations is: do you want to be left behind? Or do you want to consciously start exploring Agile as a strategic execution focus for your organizations? Excellence in execution can be a strategic advantage (fast release cycles).
- Most of you will want to or have already started adopting Agile (statistics tell us this much)But how do I make it work for my business. Sure R&D may benefit from it, but will it, in the end benefit my business? This is the real question that we must examine. What are the issues? How do I make it work for R&D first, but then for the rest of the organization?
- This question is even more relevant if you consider the odds…The hidden truth is that, unless you focus on benefiting your whole business it is unlikely that you will be able to benefit your business. This is what Ken Schwaber one of the early developers of the Scrum process said… It’s important to understand the context of this comment. Ken said the same to me in 2004 when visiting the company where I was working, most companies run behind Agile, but never really take agile adoption to the level that benefits their whole business.This is the problem we have to face, our challenge if you will.
- So, we have really two challenges when adopting Agile. First, how do I adopt Agile?What does it mean for R&DHow do I make R&D faster, achieve better time-to-market, etc.But, second: how to I make it benefit my business?- R&D is only part of the company. And surely any change in R&D will affect other functions. Will it be a positive impact? How do I care for and ensure that a change in R&D is positive for my business overall?
- These are the questions we are tackling today. We need to figure out a way that helps us get Agile to the business level, to the point at which it improves our whole business.We need some “rails” on which to put our Agile adoption train. It would be nice to have this model, a model that would help us adopt Agile and benefit my business. Let’s try to build one together, shall we?
- Let’s review some lessons learned and what steps we may be able to follow to achieve our goalThis presentation is based on experiences from two adoption processes, it is necessarily limited but tries to establish a platform on which we can build on. That can help you adopt Agile throughout your whole business.
- So let’s start with an obvious step.Like in the past, adopting Agile in an organization will benefit from Pilot projects. These relatively “safe” experiments will serve several purposes1- Introduce the method in a way that does not risk your business2- provide a learning opportunity for your people3- increase your knowledge of what are the likely consequences of Agile adoption in your environmentThis is an appropriate step for any big change, but quite critical with Agile adoption because Agile will have consequences you don’t expect (and that is ok). This is a key learning opportunity!
- As you complete your Pilot Projects you will have your own set of lessons learned.- How does your organization react to Agile adoption? Where are the tensions showing up? What roles feel threatened ? What functions take up the change, what functions resist or even rebel?These are just some of the questions that you will answer during this process and that will help you fine tune your approach.
- But keep in mind that Pilot projects, even if successful are just a small sample of what the adoption process will be. Understand that Pilot projects are more likely to succeed because they are “safer” experiments.Pilot projects are needed, but don’t represent the whole organization.
- Taking Agile to the rest of R&D is different than running a couple of Pilot Projects.The tensions are different in higher risk/higher stakes projects.You will have to consider:how to use Agile in larger projects (potentially), how to use Agile in different contexts (fixed price? Fixed scope? Within customers that don’t do Agile?)How will other functions in the company react to Agile projects, which put different demands on the organization?These are considerations you will go through when adopting Agile across R&D. That’s the next step. Breaking out from the pilot projects and tackling R&D-wide adoption. But before we go there let’s review some of the ideas we’ve covered so far…
- We have completed the first step towards our treasure island. Our Cheat sheet of Agile adoption if you will.Use pilot projects to learn and prepare a wider adoption, but don’t forget that pilot projects succeed because they are isolated.
- This brings us to step 2. After the pilot projects we are forced to think about and consider the impact on the whole R&D.R&D is diverse within itself.What happens when you have Agile and non-agile projects at the same time?How to ensure we make the right products, not just products faster?Let’s dive into these questions as we consider the impact in the whole R&D
- A problem you will face is how to synchronize multiple projects ongoing in your organization. In Agile we follow some pretty concrete rules about software development, one of them is Continuous integration and continuous deployment (even if not to the end-customer). Think about this case: R&D teams will depend on each other (for many reasons)One team asks another for something in the next Sprint, but the other team does not have a similar clock cycle and tells your team: come back in three weeks when we do our next planning process.This leads to Agile teams not being able to deliver or even worse, delivering half-done functionality that breaks everything else until the next team’s work is finalized.If you have to coordinate multiple product release cycles where several teams interact and cooperate then you must synchronize the different clock cycles in your organization.But there are other things that require coordination…
- As teams start synchronizing their work more often, the differences in their goals become evident at first and conflicting very soon after that.Cooperating that happens at the fast rate we expect it to happen in an Agile context requires that the team’s goals are aligned.
- This is one of my favorite issues. In the early days of Agile adoption I used to get the question quite often: “but we need to cooperate with this other project that is using waterfall, how can we do it?”.Well the answer is simple, but here’s the illustration of what I mean. Let’s take a common problem that you will face, which will be R&D teams using Agile that need to cooperate with IT for product development/deployment. IT is often slow in the adoption of Agile…Not all teams in the organization work in Agile mode. Sure R&D has their house in order (yeah, right!) and are following the right process in the right way (sure, sure). But how about other functions. Let's take a simple case: how about IT? Well.... Surely the poor R&D management are not supposed to fix *ALL OF THE* problems in the company right? Just kick IT! Get it into their score cards so that they suffer from not doing what we ask them. You are laughing, but this shit really happens and when it does it is mostly sad :(Going back to the point. If I'm an Agile team, who's in control of the situation and need to plan something for the next sprint, I run down to IT and ask them: could you please come to our Sprint Planning. It's tomorrow at 9:00 sharp and it lasts 4 hours. We will need your commitment in a couple of things. The IT manager opens their eyes widely and says: What... things? what things? and commitment? what? Tomorrow? but that's the deadline for our TPS reports, you can't certainly expect that we will be there in such short notice! Let me spell this problem in terms anyone can understand: "CULTURE SHOCK"! Scott Adams get's a field day out of Agile adoptions alone!So, to sum it up. An agile team goes to IT and says we need this server installed by next Sprint (in 2 weeks) and we need to have this continuous delivery system implemented (requires only a couple of hours from 1 or two engineers) and then we need this monitoring system set-up in 4 weeks so that we can start serving our pilot customers. The Agile Team is glowing, they know their lines and hit their marks, they know what they are expected to deliver and they just need a tiny-small contribution from IT. Right? Wrong! IT will come back and say: what do you think we have here? A slave shop with people laying around without anything to do? No Sir-e! We run a very tight ship here and we were asked last month to reduce costs so we are giving back some VMware server blades to the hosting provider and we had to fire Jimmy who was in charge of the monitoring system. Sorry old chap, we have a lot to do. If you need something, talk with Helen over there who's the (single) project manager for IT projects and get your work scheduled. With any luck we will get to it before Xmas. Well... you know where this is going, right? Agile in R&D is useless if IT has to plan with 6 months in advance and cannot commit to anything incrementally.So the message is clear. Starting in R&D: drop waterfall now! Move all projects to use Timeboxes. Timeboxed sprints, Timeboxed synchronization cycles for the whole R&D and Timeboxed projects!
- This leads us nicely to this step.This step is about creating an R&D wide synchronization mechanism. By which all projects and all teams can synchronize their work. They know what they need to do and when they need to do it.They come together regularly to review their work and plan the next iteration. For the whole R&D.
- We’ve talked about R&D projects so far. But there’s one role that is critical for any Agile adoption to succeed. That role is the Product Owner (aka Product Manager). The hidden truth is that Agile does not work without a good Product Owner/Product Manager and team relationship.The garbage-in, garbage-out problem.The change from give requirements, came later to ask about delays. Change to: engage regularly with the teams. Follow-up on what they need from you. Your job is very critical for the team.This leads to confusion:Another common problem is that Product Owners will be utterly confused by the change in behavior by the teams. See, they used to be called Product Managers, spent most of their time in trade shows, talking to customers, meeting with sales, writing PPT's about their products etc. Now, if you are using Scrum the role of the Product Manager is completely changed. Now we expect them to work with the team regularly. In fact, in the companies where I've worked the Product Owner is expected to interact with the team every day or at least several times a week. Being a PO is a full time job and is very much focused on the team. This is difficult to implement in a legacy business. The link between customer and R&D has always been very weak or non-existent. After all, R&D teams used to get their requirements through a requirements document, *NOT* by talking to the people who knew what the customers needed.
- If you follow this train of thought, it is clear that you need to reconsider the boundaries of your R&D organization… how far does it expand?Should product owners be in R&D?Should deployment be in R&D?There’s no single answer to these questions, you need to understand what you are trying to do, what are you trying to optimize…
- And, while we are the process of changing our R&D we will bump into obstacles that come from other organizations. When you bump into those obstacles (and you will) you will have to go back to basics. Analyze your goals, analyze the other function goals and align those!Agile cooperation will inevitably need cooperation from other functions. Do you have a cross-company goal for Agile adoption? Well, do you?
- One step to create alignment that you will need to do relatively soon will be to include product management in R&D. After all it makes sense, right? We develop products, not separate pieces of software, right?How many of you see yourselves developing software?How many of you see yourselves developing products?
- Why this step becomes quite important is that R&D can improve quality, they can improve speed of execution, but they can’t improve the products without cooperating with other parts of the company, specifically Product Management.
- Lesson Learnt 9: Portfolio decision making is very slow, convoluted and not stable enoughThis leads us to Lesson Learnt number 9: The product decisions are very slow. This is illustrated by this picture here. Where our Product Owner really thinks that they are in charge. We, the turtles, just hide and we actually like that the big cats take the responsibility for the product decisions. We say “they know what they are doing”… And in the meanwhile we get crappy, incomplete, inconsistent and frankly appalling decisions. But most importantly the product decisions are not aligned with your agile cycles.You will start an iteration and in the middle the portfolio process leads to a decision that breaks everything you’ve done, sure we want change… but c’mon. I need to know something before I can plan anything. Ask yourselves, can you trust your product portfolio process to deliver good quality decisions at timelines that are aligned with the cycles you have in R&D?
- It is obvious from this discussion that we can’t really improve our business if we just concentrate in R&D. And that is really the next challenge.R&D alone cannot improve your business. You need to look beyond R&D…
- So, the million euro question. How do I make Agile work for my Business?
- So, what have we covered. In step 2 we should consider the impact on the whole R&D, and understand the value/importance of Product Management for your R&D
- Step 3 calls on us to embrace the whole organization. It is no longer about our little R&D corner, it is about the whole system. From idea to product. We need to optimize the whole system.
- This takes us to the next big challenge. Whether we like it or not Sales likes waterfall: long-term, non-negotiable roadmaps. The problem is that R&D cannot work with those. R&D is a complex process in a complex context, this requires that we use adaptive processes (Scrum, XP, Lean, etc.) Agile! R&D cannot work with long-term, non-negotiable roadmaps!
- But let’s not be idealistic here. Many teams adopting Agile will want to iterate fast, but forget that they need guidance (product and other), they need support. You can let a team loose, but where are they going?How many of you have been in a team that was working great, but producing nothing?
- We need to a build framework that guides us, that focuses us, that delivers the guidance we need.A Vision is one way to achieve this. A vision is a long term guidance, but that is very much negotiable. A Vision is a way to take the advantages of the user story model to the portfolio level. We agree on the Vision, but the team with the Product Owner then will have to adapt that Vision to the real world.
- Another side-effect of having a high-level guidance in the form of a Vision is that teams take ownership of their part of the design process. We’ve seen teams where people take a more pro-active approach to the design process and start thinking about value, and how to deliver value rather than just concentrating on the detailed work steps that they need to follow.
- But Vision are just steps in the pursuit of your company strategy. You must link your Vision to your company’s strategy.
- As you deliver Vision-aligned projects you will start to see pressure, tension points in the whole organization. Be ready for this, this is not bad, this is part of the process
- When you see these problems search for alignment across your business. Define your cross-company goals for agile adoption, work on enabling cooperation. We should all be trying to achieve the same goal, right?
- Finally, Agile adoption is not a short term process. Your competitiors are not sleeping. You have to keep improving. Agile and the methods we regularly talk about are really a framework for improvement. You start with Scrum, and then you move to Lean. Or you start with XP and then you move to Kanban. Whatever the evolution is, the important thing is to understand that we cannot predict the future. Transform your Agile adoption process into a continuous improvement process
- Recapping: We need to deliver value by considering the whole system, optimize the system, not R&D.
- The key issue is this: We need a model. A model that can get us started, that drafts the roadmap for agile adoption.We need to adapt it as we go along, but we should have a clear Vision in mind. It is overall business improvement that we are aiming for.
- Let’s create a business-oriented, a holistik approach to Agile adoption that can help us avoid the doom we seem to be destined to (at least according to Schwaber).
- Finally, I’d like to leave you with a tip that can potentially save you millions and millions of euros.Hire someone with experience in this process!
- So, in summary here is the model.3 steps, surrounded by a big bunch of lessons learned from our experience over several years of agile adoption in 2 large Finnish companies.
- I’d like to invite you to continue this conversation on Twitter and on your own blogs. We, as a community, need to develop our knowledge and blogs and twitter are great tools to create connections and build a conversation that can develop our industry