Excited to share slides from my workshop/talk at PMI Professional Development Symposium in Toronto today. Great group. Great questions. A lot of motivated, caring people in the room today.
Agile Mindset Summary
“Agile is both a set of practices and a mindset. Success lies in understanding both “Doing Agile” as well as “Being Agile”. In this hands-on session, 5 key practices to support an Agile Mindset will be demonstrated so that you have some practical tools use immediately at work. You will also be left with some deeper challenges about what it takes achieve Organizational Agility.”
Top 2 Tips
If you are having culture challenges with your organization, you are not alone.
80% of participants at a recent conference (Scrum Gathering in Orlando) reported that the dominant culture in their organization is not supportive of progressive working environment such as Agile.
Where is Your Organization?
The infographic below show my simplification of the Laloux Culture Model. You can hand it out or show it on a projector and explain the model. Then ask: “What is the dominant culture in your organization?”
Culture Challenges show in Scrum Gathering Results
Here are the results when I asked this question at the Scrum Gathering in Orlando in April 2016.
A whopping 80% or participants are in organizations that are predominantly Red/Amber or Orange.
Agile culture is compatible with organizations predominantly green or teal as per diagram below.
Only 20% or the session participants evaluated their organizations as ones supporting Agile. This can be seen as the gap between Doing Agile and Being Agile. Lot’s of organizations trying to Do Agile without creating cultural context to Be Agile. No wonder there is so much failure around Agile.
Similar results in 2012!
In 2012, I reported almost identical results: Agile Failure and Culture – Agile 2012 Workshop Results. In this survey, I used the Schneider model with people reporting that 70% of companies were in control culture (similar to red/amber or orange). This suggests that as an industry we have not improved. Or perhaps that the improvements have been shadowed by growth of “Doing Agile”.
What Can You Do About a Culture Gap?
Trying to “Be Agile” is not a recipe for success. Instead we may see it as an invitation for real change to the fabric of the organization. Real change requires organizations to focus on their own goals and dreams – not cut and paste Agile in their organization. This is why I advocate stopping Agile initiatives and Conducting “Agile is NOT the Goal” Workshops. Please keep in mind that survival is optional – companies do not need to change their culture.
What can you do? Start a conversation about this! Listen to hear what the system wants for itself.
Doing Agile and Being Agile are different. Here is a popular infographic that explains what Agile really is and illustrates common misunderstandings about it:
Doing Agile is about the practices: standups, user stories, iterations, etc.
There are significant benefits from using Agile practices – I see it as “common sense” of getting work done. Adopting these practices will lead to benefits. Perhaps 20% or more from what I have seen. This is widely reported by industry research such as Version One’s Annual report.
Being Agile is about our Consciousness or way of being. We may also refer to this as Mindset or Organizational Culture. It’s about how we see ourselves. How we relate to each other. How we behave. What we value. A recent post explains more about this: Agile Culture –> Self-managing People.
I put the ROI on this at 3x to illustrate how much impact this has on team and organizational effectiveness. It could be much more. We are talking about reinvention here – not applying a process change.
Being Agile is NOT the Goal
After looking at this diagram, many people decided that “Being Agile” is a worthy goal. Real change requires organizations focus on their own goals and dreams – not cut and paste Agile in their organization. This is why I advocate stopping Agile initiatives and Conducting “Agile is NOT the Goal” Workshops.
Bob Hartman noticed and coined the concept that Doing Agile is not Being Agile. See his slides.
We do a deep drive at our Certified Agile Leadership Trainings around the world, where we take leaders and guide them to a higher level of performance, effectiveness and influence in their organization, while reducing resistance. Check the Calendar Here:
Here is my one page summary of some key differences between Agile and Waterfall.
(I created this when I was asked to explain this to an exec earlier this month about this and I didn’t have anything good in my toolkit nor could I find something on google.)
Key Differences between Agile and Waterfall
- In waterfall, the focus is on creating documents that capture what is needed. In Agile, the focus is on working software.
- In waterfall, people tend to work in sequence – like a relay race. In Agile, people collaborate – like a soccer team.
- In Agile, the focus is on working together as a team and learning how to improve. There is a different mindset or culture.
- In Waterfall, there is usually a messy whirlpool at then end where people abandon documentation to start figuring out how to make things work and/or what users really want.
- In Agile, software is delivered incrementally so it is much easier to predict delivery dates.
If you have your own one page summary, please add a link in comments section so we can all learn from each other.
Excited to share slides describing the latest evolution of my story (at the Toronto Agile Conference). I talk about how we may dare to create environments where Agile may flourish so we have Organizational Agility. This requires reinventing organizations.
My message is really simple:
- If you want Breakthrough Results
- Cultivate Culture to
- Create Places People Love to Work
- Start with Yourself.
Slides for Reinventing Organizations for Agility
One of my clients was struggling with Kanban vs. Scrum as a starting place. They really like the energy of Scrum: teams, collaboration, learning but from a workflow perspective needed the adaptability of Kanban: urgent requests, different ticket types, able to change direction quickly. This happens when the management and culture is there but there are too many short-term needs and/or external dependencies.
This is not new for me. I have been helping clients with this situation for the last few years – finding a comfortable hybrid between Scrum and Kanban. What is new, is that I finally made a drawing that summarizes what the flow looks like. Hope you enjoy it.
The left side of the diagram illustrates what typically happens with most Agile teams I work with. It doesn’t matter whether you are using Scrum or Kanban, teams usually benefit from:
- Sense of purpose (vision)
- Inception Deck – this will save hours or days if you have a month long project. Skip at your peril.
- Stories (or tickets)
- Effort estimates (Story Points or S, M, L)
- Rough plan (backlog) – here it is depicted with a form that matches the structure of the work – by feature area what we do now, later and even later.
- Ability to make forecasts on work
In the diagram, artifacts are in dark green and activities are in light green.
This diagram shows a physical board that helps teams collaborate to get work done. It is essentially a Scrum Board that where the team uses a single story pull model instead of a sprint batch model. One big difference is that there’s an expedite lane for urgent work. Let’s walk through the columns.
- Next: Here we see the stories for the team to work on next. Often this box sits on the backlog board – doesn’t really matter where it is as long as everyone knows what to do. Some teams skip this an pull directly from the ordered and prioritized backlog.
- Planned: A Planning meeting may structurally be the same as a Scrum Planning meeting, but here we are only planning one story at a time. Stories are broken into tasks to increase shared understanding of the work. So it may be the whole team but more likely just the subset of the team that needs to be involved in that story. Of course, very simple, small tickets or stories, may just go to in-progress without creating tasks.
- In-Progress: What tasks/tickets are getting worked on by whom. The Daily Standup meeting is where we make our best plan for the day. We may walk the board backwards to focus on completing work.
- Done: What tasks/stories are done. We may have Demo and Review meeting on a weekly or bi-weekly basis to check against our definition of done and show our progress.
- Retrospective: We meet at some regular frequency to learn how we can work better.
Structure of Kanban, Energy of Scrum
“Energy of Scrum” means keeping the essential bits of Scrum that makes it unique and valuable. These are:
- Shared Ownership – the team is collectively responsible for delivering. One small example is that we may have a task labeled “testing” (that anyone can do) but there is no Kanban step for “QA”.
- Learning – there is a large focus on learning culture. This comes through retrospectives and Scrum Master(!).
- Scrum Master – A Scrum Master represents and investment in learning and getting better. It’s about having someone focused on growing the system. This role works great with Kanban!
- Team Alignment – In Scrum a premium is placed on keeping a team in sync through planning, review, standup. Keeping these meetings let’s us keep the high levels of alignment.
Here’s the full diagram if you want to use it:
- Intro – People over Process.
- Agile = Culture. Whole Agile.
- Focus on People: Vulnerability, Authentic Connection, Safety & Trust (VAST)
- People-centric organizations (Laloux Culture Model)
- People-centric Change
You can also see earlier version of slides and video summary.
There is a huge world of difference between Enterprise Agile and Agile Enterprise. They are both valuable and accomplish very different things.
Enterprise Agile addresses the question – “How can we use elements of Agile to improve typical corporate environments while staying within the existing paradigm of traditional (Tayloristic) management. This is Orange level in Laloux Culture model.
In the diagram we see that traditional management practices are in part replace by Agile ones. In this case we are adopting Agile practices and may well have small pockets of Agile culture as well. SAFe is a good example of practice adoption. We typically see a very structured approach to orchestrate activities that are all about top-down steering and control.
The industry term Scaling Agile is about how can we scale Agile practices to support the Enterprise. It is essentially Enterprise Agile that is focused on adoption in large-scale environments. In contrast, Agile as a mindset or culture is about a way of being and does not require specific practices to scale.
With the Agile Enterprise the we are evolving an organization that is very adaptable and resilient to change. Anti-fragile is a good description for this type of organization.
In the Laxoux Culture model this would be represented by Green or perhaps even Teal levels.
In an Agile enterprise, there is leadership at all levels. The people who are closest to the work are the ones driving decisions. Here we replace top-down control with a clear organizational purpose, shared values, visibility and trust. Since everyone is contributing to the shape and direction, the results are emergent. Like a living organism, everyone is sensing and responding to the environment. The intelligence that emerges from the collective is what allows our organization to be ‘Agile’.
Fostering an Agile Enterprise will usually require a complete reboot of the cultural operating system of the organization. As such it is a much more significant undertaking that adopting Agile practices.
Both Enterprise Agile & Agile Enterprise Have Value
It is important to re-iterate that both Enterprise Agile and Agile Enterprise have value.
Enterprise Agile allows organizations to improve their operational capability so they may execute better.
Agile Enterprise is about creating an adaptable future-proof organization.
It’s not about which is better. It’s about what is right for your context.
Four years ago, I argued that Agile is a Culture System focussed on Collaboration and Cultivation. We may build on and refine this understand to see that Agile points towards a higher level of organizational consciousness and the benefits that come with it. In particular, Agile is about valuing people and setting them free to deliver.
The Agile Manifesto & Principles
Let’s use the Laloux Culture Model as a lens for understanding the Agile Manifesto. If you haven’t read about this yet, it is fantastic – go read it now – otherwise this post will not make much sense.
When we colour code each of the manifesto statements to match various stages of consciousness we get:
Individuals and interactions over processes and tools (Green)
Working software over comprehensive documentation (Orange)
Customer collaboration over contract negotiation (Green)
Responding to change over following a plan (Teal)
We see that the Agile manifesto is a mix of ideas from different levels.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (Green)
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (Teal)
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (Orange)
- Business people and developers must work together daily throughout the project. (Green)
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. (Green)
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (Green)
- Working software is the primary measure of progress. (Orange)
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (Teal)
- Continuous attention to technical excellence and good design enhances agility. (Teal)
- Simplicity–the art of maximizing the amount of work not done–is essential. (n/a)
- The best architectures, requirements, and designs emerge from self-organizing teams. (Teal)
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (Teal)
Note: Some principles are not colour coded since I didn’t really see how they fit. If you have ideas, please post a comment.
Agile is Teal/Green
When we tally up the results, we get the following for Agile Culture:
- 6 – Teal Stage – Self-management, Distributed power, and emergence.
- 6 – Green Stage – People: purpose, values and empowerment
- 3 – Orange Stage – Achievement
In a diagram, it looks like this:
The Agile Manifesto is pointing to a way of working that is at the Teal/Green stage. Elements of Scrum such as emergence and self-organizing teams are very closely connected with the Teal stage.
In summary, Agile Culture is about organizations operating at a higher level of consciousness with self-managing people.
Implications for Using Agile
For organizations at the orange stage (most large companies) Agile will be experienced as a disruptive force. As all the elements of culture need to shift together, Agile will by necessity be watered down or contained. This is what we typically see – Agile Adoption – with Enterprise Agile or Scaling Agile.
The main challenge for Agile Culture is that it is only a partial specification for operating at a Teal/Green stage. As can be see from Whole Agile, we need to consider other cultural and organizational elements for a holistic solution. We must look beyond Agile to allow Agile to succeed. This is the path of organizational transformation.
Agile is incomplete. We need to augment it to create the “whole product”. But what is it?
There are many ideas: transformation approach, culture, leadership, but something is still missing.
In order to fully unleash the potential of workers we need to augment Agile with Valuing People and rewire the Organizational Model.
Valuing People is about building a place where the whole person is welcome so they are fully engaged in work. A place where there is safety, trust and authentic connection.
Organizational Model refers to the approaches we use to run organizations: organizational structure, planning & control, roles & titles, compensation, performance management, information access, leadership and power. These need to shift for us to reinvent our organizations to unleash people’s capabilities.
This is essentially what I have been doing the last few years. Now I have a good name for it. I will be writing more about Whole Agile in the coming weeks but in the meantime, here is a video summary and slides.
Why “Whole Agile”?
An obvious question is: Why do we need something more than Agile? Why make up a new name?
One answer is that Agile is great at a team level but provides no guidance at an organizational level. We need to replace burdensome organizational processes and with lightweight ones that foster self-organization and engagement.
The most important reason for selecting a name is that we want to create a movement within the Agile community. Not everyone will be interested in building whole organizations and that’s OK.
Here are some alternative names:
- Holistic Agile
- Conscious Agile
- Evolve Agile
- Beyond Agile
First, I would like to thank my dear friend and colleague Olaf Lewitz who has been deeply involved in developing this. Other key contributors include: Melanie Meinen and Laura Powers. Thanks also to those who responded to my online survey: Clint, Jeff K, Fanny, Olivier Gourment, Shyam Kumar, Geir, Peter Trudelle, Frank Olsen, Alistair McKinnell, Justin Reyna.