Agile india 2014: The Enterprise Experiment!
•Download as PPTX, PDF•
0 likes•629 views
The document discusses an experiment testing the hypothesis that as organizations scale, the simple theories applied to a single team will remain the same across the entire enterprise. It found that as teams are decoupled from large projects and each focus on their own small backlogs and features, the theories do remain consistent at an enterprise level. The document concludes by thanking the readers for experimenting.
Recommended
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Agile india 2014: The Enterprise Experiment!
Similar to Agile india 2014: The Enterprise Experiment! (6)
Recently uploaded
Recently uploaded (20)
Agile india 2014: The Enterprise Experiment!
- 1. The Enterprise Experiment Mike Pollard & Simon Reason
- 2. Hypothesis As we scale, then the simple theories applied to a single team will remain the same across the Enterprise. Team Features Built features
- 3. Timer STOP
- 4. Hypothesis As we scale, then the simple theories applied to a single team will remain the same across the Enterprise. “The scientist tragedy of Science — the slaying of a beautiful The great is not a person who gives the right answers, he's one an ugly fact. right questions.” hypothesis by who asks the ― Claude Lévi-Strauss - Thomas Henry Huxley
- 5. Our Theory
- 6. Let the Right one in!!
- 7. Golf course to Cash Idea -> Build -> Release
- 8. From Pot to Pot But which Pot?
- 9. One team
- 10. One team ---> One Project Multiple teams De-couple teams from Large Projects Project F Value Project E Value One Backlog Feature B Feature Feature B Feature C Feature C C Feature A Feature A Project A Feature A Feature A Feature B Project Feature B B Feature B Feature C Project Feature C C Value Project D Value Large Item Backlog
- 11. Think Small
- 12. Experiment Findings As we scale, then the simple theories applied to a single team will remain the same across the Enterprise.
- 13. Thanks for Experimenting! Mike Pollard & Simon Reason
Editor's Notes
- How many of you have experienced a success with introducing Agile into a single team. So you’ve probably didn’t get it right first time, I bet you tried lots of different experiments to make it a success. And just like a single team as we introduce Agile across the Enterprise we need to experiment to make it a success.What we are going to show through some scientific and not so scientific experiments ….. are the observations and questions that we are constantly seeing and asking when we start to scale agile in the enterprise! With these observations and questions you’ll leave with a different perspective on the way you think about agile at scale. So like any good scientist we have a Hypothesis<CLICK>
- As we scale, then the simple theories applied to a single team will remain the same across the Enterprise.Explain the hypothesis…. Single TeamWe have simple theories (this is an explanation of single team only – no comparison with multiple teams)Collaborate with the customerUnderstand capacity and flow so that we are able to negotiate with our stakeholdersWe work on highest value items first to deliver earlyWe create an environment that nurtures empowerment, learning and a self managingWell when you Scale at Agile … Can't we just scale the single team model? Why can’t it be simple?So let’s show you what we mean by a simple experimentShow items for experiment do experimentSimon can you put 5 seconds on the clock please.
- On my mark Simon … start the clock
- What works with one team works with many- Experiment output - MIKEOnce we understand capacity and its consistent we use this data to plan the backlog and negotiate with our customer. There is no reason that the simple theory of understanding capacity can not be applied to the EnterpriseThe simple theory of collaborating with the customer with a single team can be applied across the Enterprise.The simple theory of building and delivering the highest value items first remains the same across the EnterpriseThere should be no reason that the simple theory of creating a self empowered, self learning, collaborative, trusting culture for a single team should not occur in the Enterprisetime and time again we have seen and experienced difficulties when applying these simple theories across the Enterprise and we have been continually running experiments to work out why.Now like any good scientist we have tried to prove our hypothesis…...HUXLEY - Not slayed it yetLEVI - Not going to give you all the answers but you should be able to leave with ideas of what questions to ask.Transition: Let’s take a look at the theory behind proving this hypothesis….
- “Do you remember this?” – presented a number of times to senior mgt.We have gone ahead and try the theoryExplain very quickly the theory (We have large items, unpacked……. )It’s Simple Right? <Click>Lets go back to when we took those 1st few steps in introducing Agile and we started the 1st Agile team.Not too risky projectHandpicked teamWe nurture the team to encourage collaboration, self-organizingWe make sure it has what it needs to succeedWhat happens then … “I want some of that … lets make more agile teams!!”Transition: So let’s take a look at how we spin up teams…
- Our decision to try agile is now changing the way we work and build productsWe are using words like …. Co-location, cross functional, communication, collaboration, community, empowerment, knowledge share.We spend a lot of energy embedding these ideas into the first few Agile teams we set-up . So, when we scale and start creating lots of teams … do we really put the energy into every team? Do we really think about a team having its own culture or are we still thinking that it’s just a resource on a seat with a skill. Let’s do an experiment about this…LETS DO THE EXPERIMENT…… just having the relevant technical and process skills in your workforce is not enough, we also need to take into account the team dynamics, will the person fit?Describe a REAL WORLD – Nokia Music and way the recruited … Involving team in selection process, HR, personality tests, etc …Question-mark– So the question we ask ourselves when we start to scale is are we thinking about bringing the right person into a team and setting each team up for success?Who is really making the decision about bringing the right one in?Just like we do with a single team where we actively work to create an environment where the team can decide, where the team knowledge share and collaborate. So we work to support this thinking across the enterprise. This we do are: Rock-upsMy storyVideo clubsReading clubsABW Communities of practiceTransition: Ok so now we have things in place that nurture the culture that we want…. And we have focused on spinning up the teams on mass but are the teams building the right things, are the teams close to their customers?
- So lets look at what we like to call ‘golf course to cash’. Which we break-up into … Idea, build, release.Explain- IDEA – off the golf course …. BUILD – Now with a development team …. RELEASE – Well … it’s released into production.Describe theory of a single team … off Golf course, short build phases, feedback, play golf, repeat.Simple right? We are close enough to the customer … so we don’t have to wait long for ideas to get to Done. What happens when we scale? What happens to that idea, feedback and speed of getting idea to done?Describe a REAL WORLD - What we generally see is most of the energy is put into the Build and Release phase, I know that’s what I have been doing in the past. When we scale up teams we really concentrate on (TDD, Pairing, cont. delivery, good Scrum and XP practices), always pushing the boundary with our delivery teams. But … how much effort do we put into the idea phase? How easy is it to get a valuable idea from the golf course to the teams …?In the enterprise … we usually have to negotiate things like, approvals, 12 month portfolio planning, large business case, funding steercos, all this heavy governance and red tape just to get an idea into a team to start experiment with the idea.We’ve got to negotiate WHAT WE CALL ‘The organisational IDEA maze’QUESTION MARK – So the question we ask ourselves when we start to scale is … Are we close to our customer and are we able to adapt quickly to those ideas coming off the Golf course?Have we thought about the flow of work so the teams can pull the highest value items?Have we changed or even considered the Organisational idea Maze?Some things to watchout for ….. ???!?!??!?Is there still a hand off between IDEA and BUILD? - a contract negotiation from stakeholder passing accountability to the teams and PMs?have we changed the way we report to and communicate to our stakeholders and customers? Do we still complain about ‘scope creep’? Do we hear ‘Your estimates are in-correct’? Are we still asked to agree on what we will build, by when and exactly by how much cost before we can start? Do we value the success of a project on delivery of all scope on time and within budget … or do we value delivering something the customer actually wants?Do we still create teams around projects and then Dissolve them when the project ends. All that energy forming the team and getting it to a state of performing and then its dissolved.Generally we see a clash in the way we work in build and release and the way we continue to work in the Idea phase. What we’ve learnt is that we need to take a holistic view from the golf course to the cash. – one of the things we have learned is to spend much more time looking at the Idea phase.Transition: So we have looked at the questions that come up about being close to our customer when we scale… let’s take a look at how else we are hindered by this organizational IDEA maze
- Message: We ring fence our budgets around a project.Explain the experimentOne of the big advantages of working in this new way is that we can regularly build potentially releasable increments of a product. Short build time and so ability to release earlyIf we can release early and we can start generate value return.It’s very simple theory<Do Experiment> -What do we do when we start a project – We get our investment approval (it’s in the money to spend pot)We have a list of features to deliver … usually we agree some form of scope to get the budget.So now we’ve introduced some props … I think we should do an experiment…..Results:Well We delivered Value … But we didn’t manage every feature we though we were going to deliver.High value features are still in the pot … lets build them. We can’t because the project budget Pot is empty. But wait …. we have some return in this pot?Different pot mate! To get these high value veatures done … you are going to have to go back through he organisation IDEA mazeWe all know about delivering value early …. But there are things that hold us back…!Even though we have a return .. .we see time and time again that the return is not our main delivery focus.TELL STORY<CLICK> questions – So this is the question we keep asking ourselvesSo if I am the customer am I going to try and maximise the amount of value for the money I spend … or am I aiming to maximise the amount of features that get built. Are we aiming to maximise value or are we working to maximise the number of features delivered?Why are we not focused on maximizing value.Is it because I have finally negotiated the idea maze … now I have my project time in the limelight … I am going to ensure I deliver the most amount of features for the money I have in the spend pot and not necessarily maximise the amount returned to enterprises value pot.<Transition> Now imagine this with multiple projects … all wanting to spend their money on all their features?Are we sure all delivery teams are working on the highest value items across the whole of the enterprise?
- Remember the single team theoryJust like any backlog, we order it with the customer and stakeholders and the team pull the highest value items from the top. It’s Simple, Right?When we say ‘Highest Value’ what is needed right now for the organisation. Example – Products re-open feature. Is that needed for day one of the new product launch? Do we think the right priority based on right thing at right time … or are we thinking build all this scope in a promised timeframe?
- Project A down to the bottomJust like single team, we order the backlog and decompose.Mention.linking teams to projectsMention decouple teams from projectsCapacity and flow of work into teams … Show Funnels with RiceMaking decisions on what is needed … not what has been promised.We have multiple teams all pulling off the top of the Backlog and delivering the highest value items for the organization.Just as with single teams we are always looking at the backlog, we’re thinking across multiple initiativesTypically off the portfolio we prioritise based on projects but to be able to prioritise on highest value and what’s needed now by our customer we need to look at smaller granularity than a project … we have to be thinking small across the enterprise.
- We are Thinking SmallWe are experiencing the benefits of thinking small, we’re getting small high value items out the door just as we would with a single team.Other BenefitsWe see the teams looking along the backlog and merge the delivery of items across features. Just as we would with a single teamKnowledge share of initiatives, just as we would with a single teamQuestion: So what questions are we asking ourselves….Are we thinking small enough to allow us to order things together across the enterprise?Even when we are thinking small and order things together is it possible to think outside of the usual project constraints? Do we still work on fixed scope, Budgets and end dates around projects? What are the KPIs – Measurement, of success … Is it still on delivery of scope on time and to budget?Do we plan on what is needed right now for the organisation or the promised project scope??INPUT THE BACKLOG EXAMPLE!!!! – Build the right thing now.So we are still trying to prove our hypothesis.
- What are our conclusions and findings?What we have shown you today are Some of our observations as we try and prove our hypothesis and the questions that arise from running those experiment.We still believe our hypotheses rings true and the simple theories applied to one team remain the same across the enterprise …But as we’ve shown you we continue to surface issues as we experiment.So …. There is One thing we do know we have proved beyond doubt …….. that the simple theory of surfacing problems, dysfunctions and impediments in a single team remain the same as we scale in the Enterprise LessonsWhen you need answers to some of the questions you will no doubt need to experimentSo we’ll end this session with some questions to you…..When you go back to your enterprises What experiments are you going to run to provide the right culture for your teams? … Let the Right one inWhat experiments are you going to run so you work closer with your customers? … Golf course to cashWhat experiments are you going to run so that you know that you are maximizing value rather than maximizing delivery of features? … Pot to PotWhat experiments are you going to run so that you know you are delivering the highest value across the enterprise? … Think smallSome final advice ….. To be successful when experimenting … before you run any experiments you should always be able to know why you are running them and what hypothesis you are trying to prove. THE END!!