There is no Planning in Agile. Right?

/by

Several times over the past few weeks, I’ve been told by people that there is no planning in Agile.

I believe the source of this misconception comes from the Agile Manifesto’s statement “Responding to change over following a plan“.

It does not say ‘instead of following a plan’.

I’d like to simply share a short and partial list of just a few examples of how and where planning may happen in an agile context.

In the hopes that a partial list will change this myth….

Mike Cohn, Agile Estimating and Planning –
http://www.mountaingoatsoftware.com/books/agile-estimating-and-planning

Release Planning (The Product Owner Board)  – Dave Sharrock –

http://www.agile42.com/blog/2013/06/17/product-owner-board/

/blog/2013/06/17/product-owner-board/

PO Planning Board

Vision – James Shore – The Art of Agile Development –
http://www.jamesshore.com/Agile-Book/vision.html

Planning an experiment – The Lean Startup – Eric Reis –
http://theleanstartup.com/

Agile Strategy Map – agile42 –
http://www.agile42.com/en/agile-transition/agile-strategy-map/

I know this is an incomplete list. If you feel like a book or reference is screaming out as missing, please feel free to comment. My hopes are that someone new to this topic will eventually search the term “no planning in agile” and come across a huge list of material showing this not to be the case.

As a final note; Planning can go very wrong for people and teams if not done while remembering lean principles and agile values and principles. Please take any reference material listed as information and don’t turn it into religious doctrine.

 

Keynote at “Embedded meets Agile” 2015

/by

We are very happy to participate again at the “Embedded meets Agile” conference in Munich this week. Agile software development as well as agile management approaches have been established also in the embedded industry by now. They benefit from the methods and practices both in software- and hardware development.

This year agile42 is a sponsor and I will deliver a keynote on Wednesday 25 March 2015 on the topic of Large Scale Agile System Engineering.

More and more companies are adopting Agile and Lean approaches to product development in the context of System Engineering. This includes both software and hardware development, and their integrations. Once more the biggest issues when going Lean and Agile is represented by cultural and mindset change, as today the technological possibility to support such transition are available on the market.

So how to organize large scale System Engineering using a Lean and Agile approach? How to deliver value at shorter intervals? How to coordinate hardware and software development? How to manage a portfolio of Opportunities delivering customer value, and scale development to dozens of teams? How to organize end-to-end system engineering?

We, agile42, have made quite some experiences with companies such as Ericsson, Siemens, TC Electronics and in the keynote we are going to share with the audience some insights, that these companies very nicely allowed us to publish, it’s going to be honest, it’s going to be brutal in some cases, and hopefully it’s going to help you in your journey…

Stop scaling… Start growing an agile organization!

/by

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 about implementing a model or another…

Watch the session video on YouTube. If you are unhappy with the sound quality you can try the presentation given at Manage Agile 2016 that covers the same material.

What to scale?

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… and now everybody wants to buy it, it really feels like an old story. 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 own culture.

Why scale?

Pressure to deliver faster causes quality issues and delay, over-budget and stress. The old system of work and control does not 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 decides to try an agile approach to work, as last resort, somehow as desperate attempt to solve a non well understood problem. Guess what, most of the time the Pilot Project succeeds! And you know why? Because the people who wanted to try it out in the first place, are also those who would do anything to make it succeed… so is that really a Pilot? Does one “probe” clear the way to a whole company roll-out?

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! And when motivation is high, with the help of transparency, trust is developed, and accountability and commitment will drive the team towards meaningful results. But can you really copy and paste what that team did to the whole organization? Mistakenly many people end up exactly doing that, coping the practices and the tools, and try to adopt it in the next project. Remember what it is hard to achieve? That cultural shift? Well that means that people are becoming agile and not adopting agile tools and practices, that is what we call long lasting and sustainable organizational agility!

The heartbeat of an agile organization…

Looking at agile teams, and trying to translate their successful behaviour, into a larger environment which is the organization, we can appreciate the following:

  • 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? What would we need to make that a successful journey? Dave Snowden, the creator 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! Besides what Snowden emphasizes is that the Cynefin Framework is a Sense Making framework and not a categorization framework. There are in fact 5 dimensions and those dimensions are determined by the data, meaning that are pretty much context dependent. So first comes the data, and than these data are analyzed to find a meaning, by confronting them with the context in which they have been produced, to establish in which domain they belong. Looking at the way results are produced in a specific context it is possible to identify the patterns that lead to the results, helping qualifying the appropriate domains. Organizations are containers for processes, structures, people, capabilities, technologies and products, and the way all these elements interacts with one another. It is common that depending on the context the interaction will be following patterns typical of the complex domain or of the complicated domain. We do have the tendency though, to exemplify the reality, and making it look a linear and easy to understand sequence of cause and effect relationships.

From William Schneider we learn about the 4 possible types of core culture, which can exists within an organization. Only one culture will be the primary one even if will coexist with some of the others. Those won’t be any combination possible, because we also know that the ones on opposite quadrants are incompatible with one another. Some organizations believe that success – thus the culture that they propagate reflect this – is strongly rooted on control. These organization are valuing the system of work over the individuals, which in some extreme cases are disposable (ever heard the term Full Time Equivalent FTE? A very personal way of addressing people indeed). The strong focus on control, brings the organization culture to value rules, predictability, procedures, policies, gate checks, quality metrics, KPIs of any kind to reinforce the feeling of control. In some contexts this works quite well, particularly when we are producing goods in a mechanical and repeatable way. There organizations are also very focused on the present, nearly real-time measurement. Other organizations believe that success is strongly rooted on competence, meaning that by excelling at what they do, and beating the competition is the way to succeed. These organizations strives to develop very vertical and specific market segments, in which they can excel by selling expertise related product and services. Even if these depend on people, the whole competence building is a machine to produce repeatable and reusable capabilities. Standardization and high quality are keys, and development towards the future is a natural attitude, as a consequence of the understanding of the time required to build competence. On the left side of the diagram we find more “people friendly” cultures, which in the present tend to develop a culture rooted on collaboration, and looking at the future on cultivation. The latter is about enabling talents to grow, and nurturing innovation, trusting that the collaboration between people will both provide the drive and the commitment to achieve these. Coming from the 19th century, most of the companies have been organized using a hierarchical system, with a push approach to work – from top to bottom – and defined process control, defining clear processes, instantiating workflows, creating plans, and tracking times and intermediate artefacts. While this approach worked well through the 20th century in which the problem to solve was producing enough to meet the market demand, and increase profitability by reducing cost of labours, surely falls short in our century. In the 21st century, everybody talks about being innovative, and what the markets demand today, is evermore to have exactly what is needed, and to have it yesterday! With this rapidly changing market condition, the approach that worked for years, simply can’t anymore cope with the time to market expectations, with the competitive pressure, and with the need to innovate, which requires experimentation. Shifting toward an more agile and lean type culture seems to be a good way to initiate that journey, and reshape the organization to be more reactive, innovative and customer focused.

Description of Enterprise Transition Framework™ (ETF)

agile42 Learned over 10 years of service to many customers, how to leverage this knowledge effectively, and created the Enterprise Transition Framework™ (ETF) to support organizations on that journey toward becoming a more agile, self-learning and innovating organization… Being a 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 to back up these claims. Naturally if you would try to compare any of these organizations on a practices and tools level, you won’t find many similarities, on the contrary, you will see how each of those, has grown their own agile way. So to contradict a well know slogan we could answer the question: “Does one size fits all?” with “No, not in practice… but in principles!”.

Basic principles and recurring patterns to help you grow agile

Beside Lean Thinking, System Thinking, Cynefin, the Theory of Constraints and other thinking models, we have learned to value the following change management and organizational design principles:

  1. Focus on small incremental changes: whenever changing from one way of working to another, we will go through a hybrid situation where the coexistence of two different ways generates attrition, duplications and other forms of waste. The awareness of this fact should push us in delivering changes fast and in small increments… pretty much like agile teams deliver changes, and evolve their own process by continuously learning what works and what doesn’t.
  2. Focus on value and organize accordingly: focusing on value means to make sure that there are as few obstacles as possible in the direction of the value streams. This implies that when we are setting up an organization to deliver a specific value on a value stream, we need to make sure that in that direction there will be the lowest possible number of flow discontinuity (such as handovers) and waiting time. It turns out that a good way to focus on the value is to use Lean Opportunity Canvas to create enough business and customer context to be able to determine the scope of a solution. Again following the approach of the Cynefin framework, the opportunity will be worked by teams, and will allow to identify over time, which are the most valuable streams on which to invest. Learning which features are delivering the highest value, and under which circumstances that did happen, provides a great way of codifying new patterns.
  3. Decentralize control whenever possible: decentralization of control and decision making, reduces the feedback loops, and enables faster reaction times. It requires defining goals and constraints to allow for autonomous decision making. Creating containers for self-organization is a way of determining which responsibilities and power to delegate to that containers. Through transparency the organization will learn to adapt those containers to support the most effective way of working.
  4. Avoid synchronization of flows unless necessary: De-synchronization is unintuitive, but allows for parallel distributed work, without having to carry the excessive burden of coordination and handovers. Way to often organization are aspiring at synchronizing all activities as if they were all gears of a clockwork. Unfortunately we all to well know that in many contexts the level of uncertainty is such, that is not possible to manage such synchronization without incurring in unjustifiable costs. Focus on delivering smaller valuable increments, rather than exercising in creating large packages to make multiple clients happy with one single shot. The reason is that to deliver the large package will take longer time, and for some of the features contained in it, the time to market might be already passed by. Besides working in large batches also causes peak in budget management, instead working with smaller increments generates a more regular cashflow, making the investments and profit more predictable.

As we have learned from many of our customers, there are recognizable repeatable patterns that emerge when the principles we have shortly explained are followed. What we have also learned is that very few of the practices and tools end up being transportable from one case to the next without adaptation. There is a very low reusability factor in those things. Besides, if we shift the attention towards tools and practices, we risk to fail to shift the culture of our organization to the place where we want it to be. This will probably result in a short lived, and very dogmatic adoption of agile practices, models and tools, instead of a long lasting and sustainable self grown agile transformation.

What makes a good Agile game?

/by

In my previous blog post Why we play, I focused on the value of agile games in our training. They build a safe-to-fail environment and let participants get a first hand experience of new concepts. One the one hand, playing games for learning is especially helpful for concepts, which can be easily misunderstood because they are different from existing ways of working. While on the other side, just playing a game for learning isn’t working. In this post I will summarise my understanding of a good learning game.

Clear Learning Objectives

A good game is oriented towards clear learning objectives. Many people don’t like games, because they don’t see their value. They fear that just playing is an end in itself. I play learning game and not just games to activate the class or for team building. I consider most of the games I use as the most effective way to deliver learning.

We have to be aware of what we want to teach with the game. Just playing because it’s cool isn’t enough. Some games such as the Ball Game can be used to deliver a wide range of learning objectives.

We have to be aware of what we want to teach with the game. Games are metaphors which allow us to experience situations which are educational, while keeping fear of failure low, and engagement high.

Ask yourself what you want to teach with this game and then focus the game towards this objective.

Simplicity

“Perfection is reached not when there is nothing more to add, but when there is nothing more to remove.” – Antoine de Saint-Exupery.

This is also true for games. Unwanted glitter disturbs learning from a game. Often people ask me after the Kanban Pizza Game, oh we could add “xyz” to this game. My reply is normally: “What are you trying to teach with xyz?” Too often the answer is, that this is making the pizza baking process nicer. We should always keep in mind, just adding nice things may be disturbing the important key learnings of the game.

Streamline your game towards the learning objective. Sometimes this is hard, especially if you found this idea initially so cool and now you have to let it go. If there is nothing more to leave out, its perfect.

lego game in action

Playfulness

Playful games let people dive into the situation. In a good game you get lost in a positive way. Instead of thinking too much about the concepts, the concerns and all your question marks, you can first be fully present in the created learning experience. This makes the playfulness a key part of the effectiveness of a learning game.

Most learning games are relatively short; from a few minutes to a few hours. In this short amount of time the complexity of a game could impede the playfulness, because the players are more focused on understanding how to play the game instead of focusing on the learning experience of the game.

To create more playfulness; avoid long descriptions to set the game up.
You don’t want the player to think too much about on how to play the game properly. The focus should be on playing the game itself and not on its setup and rules!

To foster the playfulness of a game I keep it as simple as possible and try to create an environment to let the situation emerge instead of prescribing everything through explicit rules.

For example in the Kanban Pizza Game we don’t prescribe rules for each player on how he has to act. We just limit the tools (pair of scissors, red pen etc.) and describe to the people please create this paper pizzas. The workflow and the specialisation emerges out of the setup of the environment. In this case every team mate picks a tools on their own, changing them in-between seems to be too complex and a workflow with several steps emerges in a reliable way.

The description of the game at the beginning is surprisingly short. The setup of the game is not dominating and the focus is on creating pizzas in a most effective way while we introduce the Kanban practices step by step. I’m still impressed with  the high energy level through the whole 90 minutes of a game and on how the people dive into the created situation, which is a key aspect to make the Kanban Pizza Game an effective learning game.

Keep in mind: A learning game needs to be playful to be effective!

Safe to Fail

For people to openly experiment and try new things, a game needs to create a safe-to-fail environment. Trying new things without fear, lets people try more active and brave new things. For example; what is the worst thing could happen in a game in a Lego-based game to build a city, like the Scrum Lego City Game? Try to use games with acceptable consequences in case of failure, so participants feel free to try and experiment.

Scrum Lego City Game in action

A game shouldn’t be designed to force obvious failure. I think a game should contain a fair chance to play well and succeed. For example in the Lego City Game most of the time, people find the first Sprint to be a disaster. I let them know that have had very few teams who were able to deliver good results from the first Sprint.

Metaphors vs. reality

Many people can’t focus on the created situation of the game if it’s too closely related to their daily work. They would constantly try to transfer their experience into the game and can’t think about new approaches.

A strong similarity to the daily work would also cause a constant comparison the game situation with the daily work. In such cases people may not be open to the learning of the game and miss the opportunity to dive into the situation.

Good games are metaphors with a distance to daily work to avoid such dysfunctions.

The distance between reality and the metaphor helps people to concentrate on the learning in the game first, before we discuss what we learned. A good game has a good story and makes it easy for the participant to dive into the story using their imagination.

For Kanban we use a pizza production process and in Scrum we build cities with Lego. Some people are sceptical at the beginning. Overall its impressive on how much this helps the participants to engage into the game.

Another thing surprised me in such games. While the games have a distance to work, its impressive on how they reflect challenges in the daily work. For example; a lot of environments which are having problem integrating functionality in real life, find they also have trouble integrating houses in the Lego City Game.

While in the real world the people can blame the complex technology, the problems in integrating in the lego city are really simple. You just have to get the house integrated to the streets in your city. This often opens up a good discussion in the debriefing. Participants realize  that the problem isn’t only a technical problems and what they experience is also applicable to a challenging technology stack.

Games are models and therefore can’t contain all aspects of reality. They can just help us to experience certain aspects in a fast and focused way.

Keep in mind: Games should help to learn new concepts through the use of metaphors. Simply simulating existing reality diminishes what can be learned.

Each session is unique

A game is an open arena. You steer through your constraints and rules. Each game is unique. You can see the background of the people on how they play the game. If you put them in your script, then you destroy key parts of the magic and dynamic of the game.

You need to be a good facilitator and have to go with the flow. Don’t insist on the one way and integrate their characteristics in your game. Steering should be done through the given constraints and rules. Integrate the reflection of their characteristics in the debriefing.

Debriefing is essential

All games require artful debrief. No game is self-explanatory. While in a good game the learning objectives should be obvious, it still needs the debriefing to be an effective way of learning. Remember the player was first hand in the situation. He needs to take a step back to reflect on the experiences he just had. In the discussion with the players you can start from openly talking about the made experiences and guide the conclusion through the right questions or exercises.

For example; Would the Kanban Pizza Game more effective if you transfer the emerged Kanban system on the table based on paper, cover-tape etc. closer to a typical Kanban board? Debrief on how Kanban principles and practices can be found in the game.

Kanban Pizza Game Debriefing

A learning game needs to have a good debriefing to be effective.

Good games are totally powerful to deliver personal and team learning and create first hand experience. Not every game is does this and be aware of it.

Use the right game in the  appropriate situation in an appropriate way and you will understand Why we play.

Thoughts On Scrum From A Newbie

/by

Here’s what I understood before attending CSM (Certified ScrumMaster) training earlier this month (a week after I joined agile42):  Scrum is something boys in short shorts do on the rugby field and women do when they’re fighting over a pair of Manolo Blahnik’s on sale.  I went in, suitably garbed in boots and leggings (just in case I had to break out into a sprint) and was surprised to find techy-types in long pants and shirts.  They seemed to me, woefully unprepared.

Training started with Dave separating the class into groups of people who had ‘lots of experience in Scrum/Agile’, ‘some practical experience of Scrum’, ‘some idea of what Scrum is’ and ‘no idea about Scrum’.  I decided there is safety in numbers and joined the ‘I have some idea of what Scrum is’ group.   I, of course, had no idea. 

I had no idea for example that Scrum is the most popular approach to agile software development.  For the first time ever, I heard about Extreme Programming (XP) and learned about Lean, which happily isn’t a weight-loss product but another approach initially adopted by Toyota in 1950’s Japan.  

I have worked in and with teams before and in various roles including coach and facilitator, and am familiar with Tuckman’s Team Development Model.  Teams according to Tuckman’s model move through stages -forming, norming, storming and performing – and the process can take several weeks.   Yet, I became part of  a highly-collaborative Scrum team within hours because when you’re part of a super cool Scrum team, your skills and experience helps the team deliver user stories (those work items that are on a priority list).   This was made especially evident during the (super fun!) Lego City exercise.

In Scrum, everyone is responsible for delivery; there is no such thing as ‘this is my job and that is your job’.   The focus is on the work itself.  The team also has an agreed-upon definition of ‘done’ and a clear understanding of acceptance criteria (clear unambiguous success criteria).

An important part of Agile delivery is the iteration retrospective meetings.  These meetings help the team make corrections to their processes, which is part of the learning-oriented approach.

Despite being completely ignorant of software development processes I could see how the iterative and incremental system of Agile project delivery can be applied to any business.  

Twitter: @ymcadam

Swarming

/by

Last week I did a presentation talk at the monthly meeting of Agile Leadership Network Houston on the topic of Swarming.

You’ve heard it before, “You are Agile now, go self-organize” and yet exactly how to do it remains a mystery. Beyond giving permission to “go Agile” what else can managers do to help teams capitalize on the power of self-organization? Who’s the real sucker here? Perhaps the question should be, “What can nature teach us about self-organization?” How can we – as managers -use the lessons nature provides to our advantage? Swarming is a dynamic act of being, of exhibiting collective action to solve complex problems which are beyond the capabilities of top-down problem solving. Natural systems have iterated over millennia to hone into simple rules. Studies of ants and bees and other beings in the natural world have revealed some of the underlying principles and techniques. These have found applicability into wide variety of problem domains (e.g., battlefields, drones, supply-chains, autonomous robots etc.)  But people aren’t robots…or insects. Is there a practical way to use these strategies, these lessons of nature, to help provide guidance for those of us trying to create an environment that supports and nurtures self-organizing teams?

The purpose of our talk is to first, elevate the conversation about Swarming in software development from the “psuedo-management-pop” notion of “everybody work on the same thing” approach. And the second purpose, in light of our understanding about how utterly un-understandable complexity really is, we invite you to join us in sharing the questions that truly unsettle us about prevalent management practices.

Why we train!

/by

Learning the underlying concepts

First of all training delivers the underlying concepts and enables us to work with the client on another level. For many people the concepts are different to their current way of working. 

Reading books and articles with the wrong mindset often leads to more confusion, as opposed to a better understanding of the concepts. Sometimes it feels like people read books using their “glasses of the past”. 

It’s too easy to say “We already do this more or less and this is something, which is impossible for us”. Many underlying concepts can’t be taught by books. They need a different way of approaching a topic. This is why we often play (Why we play!) in our training. Playing allows us to deliver first hand insights in a safe-to-fail environment.  We don’t see an alternative to teaching the underlying concepts.

This is one reason why we train!


It’s about experience as much as about the content

When we ask our clients for feedback after our training, they commonly share that they appreciate having their first agile experience already as a result of their training. The students value the fact that the training gives them a first-hand understanding of how the new way of working will look and feel like.

The students have made me aware, that it is as much about the content as about the learning through the experience in the class. To accomplish this, we organise our classes to integrate student feedback, agreeing on training rules, integrating a co-trainer such as Greg Keegan to model the ScrumMaster role, and working together in an collaborative learning environment with a shared goal. 

The goal isn’t only about efficient delivery of concepts. It’s also about this shared experience with guidance.

This is another reason why we train!

Training as a starting and consolidating point

An agile transition is a journey. There are different starting points to start this journey. One effective way to start it, is from our perspective an assessment. 

Another approach is to send some key players to a training class. Based on the above described challenges, this isn’t the worst option. The first people in the company get a better understanding and can better informed discuss on how to go on.  

A public training class can also help to consolidate and reflect your knowledge about agile. It can help to exchange ideas with people from other companies. Experiencing their challenges and their approaches to dealing with them can be a very rewarding experience. Some of the benefit is the ability to share their pain.

Good public training classes are a great way to learn fundamentals while getting the benefit of questions you may have not considered.  As others try to solve their own learning problems, this better prepares you for some of the questions that might arise in your own environments as your agile transition moves forward.  Sometimes a great idea from another company can really help you out in your own organization.

This is why we train!

Training is a key enabler of effective coaching

Often training alone isn’t enough and agile coaching is needed support and guidance to help people to establish their new way of working. 

Effective agile coaching can’t be prescriptive. It wouldn’t be owned by the organisation and it wouldn’t be sustainable. We can’t and shouldn’t learn every detail about our clients’ environments to give “perfect” advice. Our goal instead is to deliver key concepts to enable them to participate more actively in the coaching from the beginning and make it their own from the start.

Just sending some key players to a training isn’t enough. When only a few senior people come to training, this can result in a prescriptive approach and doesn’t empower others or the whole environment. This is why, in our experience it’s most effective to train all involved people.

Training can help to sync shared understanding. By having everyone on the same page, it helps to synchronize thoughts and concepts without having to have religious wars over specifics. It’s not only training. It’s a team building experience which creates the dynamic for students to have something to take out of the training into their work.

We have on occasion tried to do coaching engagements without training. This makes coaching so much harder and less effective. This is why we train!

To fulfil the described purposes of training the training needs to be effective. I’m happy to work continuously with my colleagues to improve our training. The feedback from our training classes and their impact on coaching and on our clients is motivation enough.

This is why we train!

Evento Agile for Innovation a Milano

/by

Siamo molto felici di partecipare all’evento Agile for Innovation organizzato da CEFRIEL che si svolgerà il 3 marzo 2015 a Milano, dalle 9 alle 17:30, presso il DEIB, Dipartimento di Informazione e Bioingegneria del Politecnico di Milano.

Obiettivo dell’evento è esplorare le potenzialità degli approcci Agile nell’ambito di contesti aziendali fortemente orientati all’innovazione. Come coach di agile42 Italia saremo presenti all’evento con due presentazioni per fare il punto su come evolve Agile in Italia e nelle nostre aziende.

Gaetano Mazzanti presenterà L’Agile non è nato per l’innovazione – miti e fatti in cui illustrerà approcci e strumenti che permettono di applicare valori e principi agili alla innovazione di prodotto e di servizi, sia a livello operativo che strategico, il tutto con un occhio anche agli impatti sull’organizzazione.
Partendo dal fatto che l’Agile non è nato per l’innovazione di prodotto, vedremo come la sua evoluzione e le contaminazioni con altre discipline (Lean, Systems Thinking, UX Design, ecc.) lo hanno reso applicabile ed efficace anche nella gestione dell’innovazione.

Roberto Bettazzoni presenterà il workshop Cynefin Lego Game, in cui attraverso la progettazione con mattoncini Lego si possono sperimentare quattro dei cinque domini identificati dal framework Cynefin di Dave Snowden. Il workshop è parte del training Agile Management Framework di agile42 dedicato al management.

Purtroppo al momento le registrazioni alla giornata sono al completo, vi informeremo se ci saranno ulteriori notizie dagli organizzatori, e naturalmente faremo un riassunto dell’evento appena possibile.

Building & Sustaining a Lean-Agile Organization: an Executive Panel Discussion at Mile High Agile 2015

/by

We are excited to announce that agile42 is sponsoring the Executive Panel Discussion at Mile High Agile 2015 on April 3 in Denver.  We have a world-class line-up of Executives who will speak about Building and Sustaining a Lean-Agile Organization. These executives represent a diverse set of large organizations who are well into their Lean & Agile journeys as organizations, and have hard-won lessons to share. Our panel members include:

Mile High Agile is in it’s fifth successful year after being launched with the help of our own Enterprise Coach, Brad Swanson, in 2011. It has sold out every year and we expect over 700 people to attend this year’s one-day event.