Xp2011 agile atscale
•Download as PPT, PDF•
0 likes•502 views
A lighning session on Agile @ Scale, that I performed at the XP2011 in Madrid. About how to organize Agile teams in a larger system, and what management should focus on, mindset and process/structure wise. For the accompanying notes, twitter me on @eelco1969
![[object Object],[object Object],Eelco Rustenburg [email_address] Twitter: @eelco1969 www.xebia.com](https://image.slidesharecdn.com/xp2011agileatscale-110525050758-phpapp02/85/Xp2011-agile-atscale-1-320.jpg)
![[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (11)
Similar to Xp2011 agile atscale
Similar to Xp2011 agile atscale (20)
Recently uploaded
Recently uploaded (20)
Xp2011 agile atscale
- 3. Agile Delivery - team level Product Owner Backlog Sprint Vision, direction Pull, work
- 4. Product line level Product Line Backlog Chief PO Vision, direction Pull
- 9. Stable Teams over Resourcing Prioritizing over Planning Products over Projects Outcome over Output Entrepreneurship
- 10. Portfolio Flywheel & Principles Stable teams over resourcing Prioritizing over planning Outcome over output Products over projects Stable Teams Prioritize Focus on Outcome Entrepreneurship V A L U E Think in products
Editor's Notes
- Intro, being me myself and I.. It is about Agile at Scale, which is fundamentally different thinking than scaling Agile. What happens when you try to scale Agile? You hit some new barriers. This pres aims to give you ideas how to first understand management and business on a larger scale level, and then help them in their mindset to enable agility on a large scale.
- When talking about agile with senior management of any BIG or small company, without execption, they get it within 5 minutes. There are in that position because they should get it. Middle management is getting it also, but remember where they are: in the worst place you could be in such an organization. I deeply respect them, and they have a hell of a job. They are the ambitious smart people growing into management roles, and then finding out that the structure of the organization entangles them into undesired behavior, forcing them to try to compromise on both sides to do a reasonable job. RESPECT. They see what is happening, cannot exactly explain why, and seek the power, knowledge and vision to share to both senior management AND the teams what is needed.
- Agile delivery of ONE team.. needs hardly any explanation..
- When scaling agile, this is typically the model that we envision and use, and it works quite well, when implemented. Yeas, you need some kind of cross team coordination, lot of literature about it, you can have architecture scrum of scrums, component owners, etc etc. Not enough time in this LT :-) LET US LOOK AT SOME FACTS OF CORPORATES..
- Used “Peter Sellers Inspector Clouseau” pic for FACTS, because this is a classic scene where facts point towards one inevitable conclusion, but somehow magically, Clouseau takes another one, which is actually right as well - a shot in the dark. Large organizations have large hierarchies. It is a fact. Because of the way most organizations have a predominant line organization, resources are planned all the time by programs and projects, constant distorting the responsibility systems of the line organization, causing more focus on control and “i need to know HOW things are done”. But what if we could have stable teams, multidisciplinary, doing their work together, and line organization would be either the only organization, or a facility where you can meet your expertise peers and learn, share, grow.
- In large organizations, there is a lot going on. Deciding on ‘acquiring a new market’, or ‘increase customer retention by 10%’ will cause the organization to do a lot of work. This has always been put into portfolio’s and programs (depending on size). Makes sense, because it is a way to structure your strategic needs into blocks of budget. The effect however, is that portfolios are planned upfront, to justify the budget they need. So multiple programs are defined, which all have multiple projects, making multiple changes in multiple systems, depending on other programs in some cases. This leads to the disconnection of the strategic direction and the operational execution of it. At project and program level, the layers above are big, the work is already planned in time, therefore we just start executing our project. The budget for the project is set, so we know when it is done, late, succesful or not, right? Well, in a shortcycled delivery system, we could maybe make a change. Wouldn’t it be nice.. if we could have fixed budgets for our strategic initiatives = portfolios, and have a list of priorities on that level to have the teams shortcycle deliver on. We could actually make a case that project A, after 20% will decrease in priority because a lot of its value has been accomplished. I have had several experiences where that happened..Wouldn’t it be nice....
- Tell: What we see in large orgs, is the focus on productivity. It turns out that value on that large a scale and accountability for that value is hard to measure, therefore most organizations have decided to measure productivity. This leads to the situation where everybody is being held accountable for producing, regardless the value. Now of course, there is value decisions on higher levels (portfolio), but teams are busy being productive, when taken the viewpoint of senior management. “We decided WHAT we want (o a global scale), they must produce as fast as possible, and we BELIEVE or HOPE that the value we envisioned will be put in the product that is produced. You could say this is managing OUTPUT over OUTCOME. Wouldn’t it be nice if we had managers looking at the outCOME. Or enable them to do so? They would like to... The compelling argument to use a short cycled delivery system is that you actually have, for the first time, a way to look at the value on the output level, and continuously give and get feedback on the deviation of the output with the outcome. Short cycled systems enable steering on outcome!!
- One thing to cover in detail before wrapping this up, is the project phenomenon. Because of how hard it is to keep an eye on the strategy when executing, projects are defined around a set of value-adding activities to ensure we will get the promised or believed or calculated result on a higher level. This leads to all kind of new behavior, because the project manager will feel responsible for doing so. And thereby he will ensure a closed environment, with own people, testenvironments, schedule etc. Makes sense, and as a project manager, I would FEEL the same. (And do so, been there, done that..) But wait.. what if we have the stable teams, working on strategic priority, etc.. we could have product teams instead of project teams. Projects would only start when we really need a separate organization, because there is something that is completely new to the organization.
- Lets put it into one picture, and make it a little visible.
- This whole thing is driven by the entrepeneurship, and drives entrepeneurship.
- Ok, there are other (big) issues with large scale organizations. The architecture of legacy, the test coverage, integration, all of these could be in your way when trying to organize. The 10 year old answer is always : “Well, what CAN we do?