• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Beyond the Hype! – What You Really Need to Know Before You Jump In
 

Agile Beyond the Hype! – What You Really Need to Know Before You Jump In

on

  • 596 views

Many companies adopt Agile because it is the natural thing to do. But do they know what they are getting into? In this talk we will use some anecdotes and lessons learned from Agile adoption to build ...

Many companies adopt Agile because it is the natural thing to do. But do they know what they are getting into? In this talk we will use some anecdotes and lessons learned from Agile adoption to build a model that will hopefully help our companies adopt Agile in a way that affects positively their business.

Questions we try to address will include: How does Agile affect functions outside development? How to bring the benefits of Agile to non-development functions? What can Agile affect my bottom line?

Statistics

Views

Total Views
596
Views on SlideShare
596
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agile Beyond the Hype! – What You Really Need to Know Before You Jump In Agile Beyond the Hype! – What You Really Need to Know Before You Jump In Document Transcript

    • Ill start right away with the lessons learned. Are you ready: you can start takingnotes, because this stuff is precious. This is a talk about the real process ofadoption Agile, failing, then trying again. The stories in this presentation arecollections from several companies where Ive worked at and that Ive interactedwith. At the end you will have the solution for all of your problems, dont worry!:) 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 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% shortertime-to-market), responsiveness to change (90%)The evidence is clear. Agile is being widely adopted, and now the question for you whowork in software organizations is: do you want to be left behind? Or do you want toconsciously start exploring Agile as a strategic execution focus for your organizations?Excellence in execution can be a strategic advantage (fast release cycles). 7
    • Most of you will want to or have already started adopting Agile (statistics tell us thismuch)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 realquestion that we must examine. What are the issues? How do I make it work for R&Dfirst, but then for the rest of the organization? 8
    • This question is even more relevant if you consider the odds…The hidden truth is that, unless you focus on improving your whole productdevelopment process 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’simportant to understand the context of this comment. Ken said the same to me in 2004when visiting the company where I was working, most companies run behind Agile, butnever 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. 9
    • So, we have really two challenges when adopting Agile.First, how do I adopt Agile?-What does it mean for R&D-How 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 otherfunctions. Will it be a positive impact? How do I care for and ensure that a change inR&D is positive for my business overall? 10
    • These are the questions we are tackling today. We need to figure out a way that helps usget 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 benefitmy business. Let’s try to build one together, shall we? 11
    • Let’s review some lessons learned and what steps we may be able to follow to achieveour goalThis presentation is based on experiences from several adoption processes, it isnecessarily limited but tries to establish a platform on which we can build on. That canhelp you adopt Agile throughout your whole business. 12
    • So let’s start with an obvious step.Like in the past, adopting Agile in an organization will benefit from Pilot projects. Theserelatively “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 inyour environmentThis is an appropriate step for any big change, but quite critical with Agile adoptionbecause Agile will have consequences you don’t expect (and that is ok). This is a keylearning opportunity! 13
    • 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 thatwill help you fine tune your approach. 14
    • But keep in mind that Pilot projects, even if successful are just a small sample of whatthe adoption process will be. Understand that Pilot projects are more likely to succeedbecause they are “safer” experiments.An example of how Pilot projects are “safer” is that they are typically free from politicalgames in the organization as they are “small”.Pilot projects are needed, but don’t represent the whole organization. 15
    • 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 thatdon’t do Agile?)-How will other functions in the company react to Agile projects, which put differentdemands on the organization?These are considerations you will go through when adopting Agile across R&D. That’sthe 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… 16
    • We have completed the first step towards our treasure island. Our Cheat sheet of Agileadoption if you will.Use pilot projects to learn and prepare a wider adoption, but don’t forget that pilotprojects succeed because they are isolated. 17
    • This brings us to step 2.After the pilot projects we are forced to think about and consider the impact on thewhole 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 18
    • A problem you will face is how to synchronize multiple projects ongoing in yourorganization.In Agile we follow some pretty concrete rules about software development, one of themis 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 nothave a similar clock cycle and tells your team: come back in three weeks when we doour next planning process.This leads to Agile teams not being able to deliver or even worse, delivering half-donefunctionality that breaks everything else until the next team’s work is finalized.If you have to coordinate multiple product release cycles where several teams interactand cooperate then you must synchronize the different clock cycles in your organization.But there are other things that require coordination… 19
    • As teams start synchronizing their work more often, the differences in their goalsbecome evident at first and conflicting very soon after that.Cooperating that happens at the fast rate we expect it to happen in an Agile contextrequires that the team’s goals are aligned. 20
    • This is one of my favorite issues. In the early days of Agile adoption I used to get the question quite often: “but weneed 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 oftenslow in the adoption of Agile…Not all teams in the organization work in Agile mode. Let’s imagine, for the sake of argument that R&Dhas their house in order (yeah, right!) and are following the right process in the right way (sure, sure). Buthow about other functions.Lets 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 sufferfrom not doing what we ask them. You are laughing, but this shit really happens and when it does it ismostly sad :(Going back to the point. If Im an Agile team, whos in control of the situation and need to plan somethingfor the next sprint, I run down to IT and ask them: could you please come to our Sprint Planning. Itstomorrow at 9:00 sharp and it lasts 4 hours. We will need your commitment in a couple of things. The ITmanager opens their eyes widely and says: What... things? what things? and commitment? what?Tomorrow? but thats the deadline for our TPS reports, you cant certainly expect that we will be there insuch short notice! Let me spell this problem in terms anyone can understand: "CULTURE SHOCK"! ScottAdams gets 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 from1 or two engineers) and then we need this monitoring system set-up in 4 weeks so that we can startserving our pilot customers. The Agile Team is glowing, they know their lines and hit their marks, theyknow 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 aroundwithout anything to do? No Sir-e! We run a very tight ship here and we were asked last month to reducecosts so we are giving back some VMware server blades to the hosting provider and we had to fire Jimmywho 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 whos 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 21
    • useless if IT has to plan with 6 months in advance and cannot commit to anythingincrementally.So the message is clear. Starting in R&D: drop waterfall now! Move all projects touse Timeboxes. Timeboxed sprints, Timeboxed synchronization cycles for thewhole R&D and Timeboxed projects! 21
    • This leads us nicely to this step.This step is about creating an R&D wide synchronization mechanism. By which allprojects and all teams can synchronize their work. They know what they need to do andwhen they need to do it.They come together regularly to review their work and plan the next iteration. For thewhole R&D. 22
    • We’ve talked about R&D projects so far. But there’s one role that is critical for any Agileadoption 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 Managerand team relationship.The garbage-in, garbage-out problem.The change from give requirements, came later to ask about delays. Change to: engage regularlywith 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 thechange 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 PPTs 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 whereIve worked the Product Owner is expected to interact with the team every day or atleast several times a week.Being a PO is a full time job and is very much focused on the team. This is difficult toimplement in a legacy business. The link between customer and R&D has always beenvery weak or non-existent. After all, R&D teams used to get their requirements througha requirements document, *NOT* by talking to the people who knew what thecustomers needed. 23
    • If you follow this train of thought, it is clear that you need to reconsider the boundariesof 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 tryingto do, what are you trying to optimize… 24
    • And, while we are the process of changing our R&D we will bump into obstacles thatcome from other organizations. When you bump into those obstacles (and you will) youwill have to go back to basics. Analyze your goals, analyze the other function goals andalign those!Agile cooperation will inevitably need cooperation from other functions. Do you have across-company goal for Agile adoption? Well, do you? 25
    • One step to create alignment that you will need to do relatively soon will be to includeproduct management in R&D. After all it makes sense, right? We develop products, notseparate pieces of software, right?How many of you see yourselves developing software?How many of you see yourselves developing products? 26
    • Why this step becomes quite important is that R&D can improve quality, they canimprove speed of execution, but they can’t improve the products without cooperatingwith other parts of the company, specifically Product Management. 27
    • Lesson Learnt 9: Portfolio decision making is very slow, convoluted and not stableenoughThis leads us to Lesson Learnt number 9: The product decisions are very slow. This isillustrated by this picture here. Where our Product Owner really thinks that they are incharge. We, the turtles, just hide and we actually like that the big cats take theresponsibility for the product decisions. We say “they know what they are doing”… Andin the meanwhile we get crappy, incomplete, inconsistent and frankly appallingdecisions. But most importantly the product decisions are not aligned with your agilecycles.You will start an iteration and in the middle the portfolio process leads to a decision thatbreaks everything you’ve done, sure we want change… but c’mon. I need to knowsomething before I can plan anything.Ask yourselves, can you trust your product portfolio process to deliver good qualitydecisions at timelines that are aligned with the cycles you have in R&D? 28
    • It is obvious from this discussion that we can’t really improve our business if we justconcentrate in R&D. And that is really the next challenge.R&D alone cannot improve your business. You need to look beyond R&D… 29
    • So, the million euro question. How do I make Agile work for my Business? 30
    • 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 31
    • Step 3 calls on us to embrace the whole organization. It is no longer about our little R&Dcorner, it is about the whole system. From idea to product.We need to optimize the whole system. 32
    • This takes us to the next big challenge.Whether we like it or not Sales likes waterfall: long-term, non-negotiable roadmaps. Theproblem is that R&D cannot work with those. R&D is a complex process in a complexcontext, this requires that we use adaptive processes (Scrum, XP, Lean, etc.) Agile! R&Dcannot work with long-term, non-negotiable roadmaps! 33
    • 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? 34
    • We need to a build framework that guides us, that focuses us, that delivers the guidancewe need.A Vision is one way to achieve this. A vision is a long term guidance, but that is verymuch negotiable. A Vision is a way to take the advantages of the user story model to theportfolio level.We agree on the Vision, but the team with the Product Owner then will have to adaptthat Vision to the real world. 35
    • Another side-effect of having a high-level guidance in the form of a Vision is that teamstake ownership of their part of the design process.We’ve seen teams where people take a more pro-active approach to the design processand start thinking about value, and how to deliver value rather than just concentratingon the detailed work steps that they need to follow. 36
    • But Vision are just steps in the pursuit of your company strategy. You must link yourVision to your company’s strategy. 37
    • As you deliver Vision-aligned projects you will start to see pressure, tension points in thewhole organization. Be ready for this, this is not bad, this is part of the process 38
    • When you see these problems search for alignment across your business. Define yourcross-company goals for agile adoption, work on enabling cooperation. We should all betrying to achieve the same goal, right? 39
    • 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 youmove to Kanban. Whatever the evolution is, the important thing is to understand thatwe cannot predict the future.Transform your Agile adoption process into a continuous improvement process 40
    • Recapping: We need to deliver value by considering the whole system, optimize thesystem, not R&D. 41
    • The key issue is this: We need a model. A model that can get us started, that drafts theroadmap for agile adoption.We need to adapt it as we go along, but we should have a clear Vision in mind. It isoverall business improvement that we are aiming for. 42
    • Let’s create a business-oriented, a holistik approach to Agile adoption that can help usavoid the doom we seem to be destined to (at least according to Schwaber). 43
    • Finally, I’d like to leave you with a tip that can potentially save you millions and millionsof euros.Hire someone with experience in this process! 44
    • So, in summary here is the model.3 steps, surrounded by a big bunch of lessons learned from our experience over severalyears of agile adoption in 2 large Finnish companies. 45
    • 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 tocreate connections and build a conversation that can develop our industry 46