Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Stop scaling... Start growing an Agile Organization!

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 50 Anzeige

Stop scaling... Start growing an Agile Organization!

Herunterladen, um offline zu lesen

Strategic advantage lies in being yourself and doing the right things the right way. Those who copy what their competitors are doing, place themselves behind the pack — a sure way of losing. This is why “scaling” agility is misleading at best, and disastrous at worst. When you take an existing model and fit your organization to that, you lose much of what makes you unique and different.

Companies small and large must instead learn to grow their own agility for their own advantage. This sounds simple — and it is, when you know what to look for.

In this keynote, Andrea Tomasini presents guidelines and heuristics for growing an agile organization. You will understand why the first step in any transition must be learning how to change. Small inexpensive experiments and empirical metrics will lead you towards your strategic goal, iteratively and incrementally.

The agile transition never ends — but you know it’s working when transitioning becomes a way of life. This not only lets you adapt to new market conditions: it also allows you to create change in the market, on your own terms.

The complexity of scaling agile in a large organization
Fundamental principles on “growing”
Concrete examples (Siemens, Ericsson…) from companies of all sizes (60-6000 employees)

The principles are simple, but they must apply to the organization, not the product or the system architecture.

The heartbeat of a growing organization.

Strategic advantage lies in being yourself and doing the right things the right way. Those who copy what their competitors are doing, place themselves behind the pack — a sure way of losing. This is why “scaling” agility is misleading at best, and disastrous at worst. When you take an existing model and fit your organization to that, you lose much of what makes you unique and different.

Companies small and large must instead learn to grow their own agility for their own advantage. This sounds simple — and it is, when you know what to look for.

In this keynote, Andrea Tomasini presents guidelines and heuristics for growing an agile organization. You will understand why the first step in any transition must be learning how to change. Small inexpensive experiments and empirical metrics will lead you towards your strategic goal, iteratively and incrementally.

The agile transition never ends — but you know it’s working when transitioning becomes a way of life. This not only lets you adapt to new market conditions: it also allows you to create change in the market, on your own terms.

The complexity of scaling agile in a large organization
Fundamental principles on “growing”
Concrete examples (Siemens, Ericsson…) from companies of all sizes (60-6000 employees)

The principles are simple, but they must apply to the organization, not the product or the system architecture.

The heartbeat of a growing organization.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (18)

Anzeige

Ähnlich wie Stop scaling... Start growing an Agile Organization! (20)

Aktuellste (20)

Anzeige

Stop scaling... Start growing an Agile Organization!

  1. 1. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Stop scaling… Start growing an agile organization Companies of all sizes need to grow their own agile way of working, becoming more agile is a journey, not a destination, it is not implementing a model or another…
  2. 2. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Andrea Tomasini Agile Coach & Trainer andrea.tomasini@agile42.com @tumma72 @agile42/coaches
  3. 3. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. What to scale?
  4. 4. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Delivery Model? Organizational Structure? Teams and Processes?
  5. 5. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015.agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. We’llhave largerProjects,we needtoscale… Ithinkscaling culturewillbethereal challenge…
  6. 6. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Why scale?
  7. 7. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. CorporateHierarchy Compliance Individual
  8. 8. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Agile Pilot Success! Teams demonstrated that Agile can deliver value faster, higher quality, and is motivating Organizations are pressed into Agile, as they can’t seem to find a way back...
  9. 9. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. The heartbeat of an agile organization…
  10. 10. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Client & Value focus Self-Organization &Autonomy Iterative & Incremental change to reduce the risk Continuous Improvement
  11. 11. agile42 | the agile coaching company www.agile42.com | All rights reserved. Copyright © 2007 - 2015. Simple ComplicatedComplex Chaotic Sense

Hinweis der Redaktion

  • Asking the question triggers the most diverse answers. It nearly seems people don’t know what they want to scale, they just know then “need” to… it feels like someone presented scaling as the ultimate solution to solve every problem…
  • Way to often the focus about scaling agile lands on the delivery of projects, and explicitly on the operational model behind that. Every true Agilist would know that agility is about continuous improvement and excellence as much as it is about delivery of value. The real challenge lays in how to make an organization learn continuous improvement and embed it into its culture.
  • Pressure to deliver faster cause quality issues and delay, over budget and stress. The old system of control doesn’t seem to work BUT… as we only know that one, we keep on trying reorganizing every 9-12 months and still end up puzzled at how ineffective that turns out to be. It feels like we are running in circles incapable of finding a way out… until…
  • Someone decided to try an agile approach to work, as last resort, somehow as desperate attempt to solve a non well understood problem. The thing is that “agile” very likely didn’t do the trick, what probably did do the trick, is the fact that for the first time in the corporate culture, real teams have been formed, which have been allowed to self-organize. All of a sudden, as a side effect, we got all brain power functioning again!
  • Looking at the Agile Teams, and trying to translate their successful behaviour, into a larger environment which is the organization, we can appreciate: the focus on customer value, the self-organization and the autonomy, the iterative and incremental approach to reduce risk, and definitely the continuous improvement. How can we bring these behaviours at an organizational level though?
  • Dave Snowden, the author of the Cynefin Framework, taught us then when we find ourselves in a complex domain, we need to experiment our way through it, by running small and safe-to-fail probes. This would allow to identify patterns that lead to success and failure, ultimately driving toward an emergent, self learning organization. There is no best practice, and no good practice in a complex domain!
  • William Schneider modelled 4 possible types of core culture, which can exists within an organization. Only one culture will be the primary one, and the one on the opposite quadrants are incompatible to one another. Coming from the 19th century, most of the company have been organized using hierarchy, push systems and defined process control. in the 21st century, everybody talks about being innovating, and adopting an Agile and Lean culture seems to be a good way to initiate that journey.
  • agile42 Learned over 10 years of service to many customers, how to use this knowledge effectively, and created the Enterprise Transition Framework (ETF) to support organization on that journey toward becoming a more agile, self-learning and innovating organization…
  • Being the framework based on principles and emerging patterns, it adapts in terms of practices to organizations of any size, at least we think so… and we have good cases of organization with 60+ people up to organizations with some thousands…
  • Beside Lean Thinking, System Thinking, Cynefin and Theory of Constraints and other thinking models, we have learned to value the following change management and organizational design principles…
  • The traditional approach to change management, coming from the same stem as the traditional organization, looks pretty much serialized, ad bit like a waterfall. First a new model is designed, than is thoroughly documented, distributed and rolled out. Many times the learning of the new processes and structures is left to individuals, supported by the management. Out of the experience many issues are identified, and the organization finds itself often in an unstable state, which requires fixes…
  • If we think at the way agile teams deliver value instead, or the way they evolve their own way of working over time, through retrospectives, we should approach change in the same way at an organization level. Using a coach to drive the change, and emerge the right patterns out of experience seems to be a sensible approach which will aim at stabilization faster, and will let the best standards emerge…
  • In order to accelerate the emergent change, and keep everyone in an organization both focused and aligned towards a common goal, an Agile Strategy Map(TM) can be created. It will allow to identify collaboratively Possible Success Factors (PSFs) which would be supportive of the defined Goal, and allow to identify small (8-12 weeks) safe-to-fail experiments, to trigger the evolutionary process…
  • An Agile Strategy Map is a framework which allows alignment within the organization around a commonly understood Goal, by following specifically identified Success Factors. It allow also to coordinate experiments within the organization and allow to measure their impact also in terms of dependencies, fostering the learning across the whole organization and encouraging standardization towards emergent successful patterns…
  • The buy-in and alignment on the Strategy can move down to the operational levels, involving all sorts of required expertise to translate the identified Success Factors in operatively actionable experiments. Collective experimental learning is the key to determine which organizational, cultural, operational, technical… patterns tend to generate better results.
  • Consider that creating-cross functional teams in a very departmentalized organization requires getting across quite some borders, regulations and policies. The transparency required to operate in a more Lean and Agile way, is often the means by which dysfunctions are exposed… and with the right framework in place, the organization can learn and convert the dysfunctions rapidly into successful patterns, instead of risking deniability and cover-ups.
  • The traditional matrix organization was design in a period when economies of scale were dictating “efficiency” was the key to success, as the demand on the market was higher than the capacity, but the competition was pushing the profit down. As a consequence, customer value was not supported by any stable and long lasting structure, but just by projects, which when completed would hand over maintenance and support to other part of the organization. The hand-over causes loss of knowledge, customer understanding, and generates often very high costs. Value delivery is hindered as well as a consequence of the parallelization of efforts on multiple projects at the same time, introducing both loss of accountability and waiting time, on top of the loss of knowledge and customer context.
  • An agile organization should focus on creating stable structures towards the customer value, and remove all the waste identified along that Stream. Coordination of people with similar capabilities and talents can be done using dynamic adaptable structures such as community of practice, or interest groups, both of which foster emergent standardization.
  • As an example consider reducing the cost of change by being able to iteratively and incrementally release the changes over time, without causing too many dysfunctions. If we were able to let those changes emerge out of specific small increments of value, delivered to our customers, we would have the perfect end-to-end environment to validate global optimization, instead of local optimization. A unified Portfolio and Program System which allows to govern the business without putting constraints on the way each “Opportunity” is worked on could hypothetically help…
  • Focusing on customer value, requires to streamline the way customer requests are identified, collected and translated into Opportunities, till they are delivered to the customer closing the loop. Ideally no interruption should occur in this process, and the people working on a specific value stream should share knowledge and learn together with their clients, how to improve the value delivered, as well as understanding what is not valuable and can be eliminated in the process.
  • Refocusing on customer value, requires changing some paradigms, and start tracking requests and opportunities from the moment they enter into an organization space. Slicing opportunities to allow incremental delivery of value, needs to be a top priority for an organization that strives to learn from their customers and markets, what to do and how to do it. Using Lean Canvas, or any other One Pagers document, to represent such opportunities turned out to be quite a successful pattern. They are concise, focused, easy to change and read, allowing for rapid decision making and reaction times.
  • Dependencies are visible thanks to different magnet colors, Canvases are developed into Epics, that are then broken down into smaller stories, flowing into different teams. Teams are empowered to develop a Canvas together with their business owners and product owners, and to pull the work, according to their capabilities and capacity. Coordination costs are highly reduced, and delivery of value is smoother and more focused.
  • The same pattern can suite much larger organization with thousands of people working, they just require quite some more space. Transparency through clear visual clues, are key factor to enable fast and well informed decisions. Clear policies help the organization to learn step by step how to pull opportunity further, and allow for timed coordination, only when strictly necessary…
  • Hierarchies are based on mistrust. As few as necessary is propagated to the lower levels, to make sure there isn’t any strategic advantage at stake, because only the upper level are aware of the rationals and the goals behind decisions and activities. This proven to be effective in environment in which mechanical work is performed, but turned out to be very poor structured in knowledge working environment, where learning is the primary product. In these organizations it is of primary importance to allow communication and sharing at all levels, to reduce uncertainty and thus risk more rapidly.
  • An agile organization is approaching control in a different way… as agile teams do, the concept of empowerment is propagated forward at various level by defining containers (CDE) with the right amount of power and constraints. Delegation is eased thanks to transparency as well, and collaboration is encouraged even between different containers.
  • There are no delays in the communication and people engage with their products much better. Not only at a team level, but also at an organizational level.
  • Traditional organization are still setup for large batches releases, and force the synchronization of all projects towards a common release, to make sure that there will be a package which will be appealing to many customers, containing a lot of functionalities. This approach appears to be the most “cost efficient” many times, because traditionally there is a separation between cost centers and profit centers. Without calculating the cost of delay, and the devaluation on invested money due to limited cashflow between one release and the next, it is a good enough approximation… right?
  • Agile organizations instead are focusing on delivering value iteratively and incrementally, every project is stated and completed with no delays, and capacity is allocated 100% on a project until that project is finished. This approach might not be the most “cost effective” at a first glimpse, but looking at the Cost of Delay and the cash flow generated, it looks very much to be the more appropriate choice.
  • Integrated software, firmware and hardware development, with short cycles experimentation is aiming at reducing the risk, removing the waste, and facilitate problem resolution with a cross-functional mindset.
  • The focus on developing one feature at a time, and multi-platform is also the choice that Babbel made, features are available on all platform (iOS, Web and Android) simultaneously, and requires collaboration between multiple teams. At Siemens they have made similar experience, reducing the risk, and validating earlier hardware implementations, lead to much faster time to market and lower development costs.
  • Agile is about continuous improvement and defining a process is going to create impediments to that continuous improvement which requires changes. The attempt to define a process is also a sign of connection to the old way of thinking, and not embracing uncertainty and accepting emergent behavior.
  • The first person you need to coach is the one you see in the mirror every morning :-)

×