Is it Time to Evolve Beyond the Agile Manifesto?

The colorful wall posters are ubiquitous in organizations small and large. If you’ve used the word Agile at least one time in your company, then I bet you’re keenly aware of the 2001 Agile Manifesto, which expresses the 4 value statements and 12 principles of Agile software development. Sometimes compared to the Declaration of Independence, many cherish it as the timeless artifact that ultimately spawned the Agile transformation movement. Over the years, I’ve relentlessly referred to it and have respectfully challenged organizations to learn from 15+ years of wisdom embedded within the Manifesto.

From 2001 to 2016 – Where are we now?

Fast forward to 2016 and you’ll see that we’re in a much different place than 2001. The pursuit toward Enterprise Agile and scaling is an industry buzzword and was a major theme at this year’s Agile Alliance conference. With Agile2016’s attendance at 2,500 strong, the learning and cross-industry collaboration is at an all-time high.

As a conference participant, I used the week as an opportunity to exchange learnings and experiences with Enterprise Coaching peers, as well as other leaders and practitioners across this vast space of “Agile”. Through various conversations during the week, the following two themes emerged for me:

  1. Large Enterprises continue to share many of the same opportunities & challenges.
  2. We agree that a principles-first approach toward Enterprise Agile is essential for the most effective adoption of processes, practices and tools.

In short, a guiding set of organizational principles helps adapt processes and practices in an organization’s context while successfully moving the Agile needle in a meaningful direction.

That said, I invite us to ponder the following question:

Are the principles in the 2001 Agile Manifesto still relevant in 2016?

The mid-week keynote seemed to offer a compelling answer to the question. Joshua Kerievsky’s talk on Modern Agile focused on the evolution of Agile and our need to keep pace via an adapted set of guiding principles. Here is a picture showing the 4 broad principles from the 2001 Agile Manifesto (left) and the proposed 4 principles for Modern Agile (right):

 

 

In his keynote, Kerievsky postulated that the Agile Manifesto was relevant when drafted in 2001, but in present-day, Agile has evolved far beyond its original intentions…rendering the original principles as outdated. What do you think?

This keynote article summarizes Kerievsky’s message better than I can, so I invite all of us to learn and draw our own conclusions. For those who weren’t at Agile2016, this amazing visual summary captured the essence of his talk (credit: Lynne Cazaly):

 

 

How do you make Modern Agile real in your organization?

Like the original Manifesto, there is a vast body of knowledge under the covers – including theory & science, thinking tools, practices and skills that must be understood, adopted and mastered in your organization’s context. I would also offer that, for the most part, the 4 principles of Modern Agile are easy to understand …. but extremely difficult to master – especially at the size and scale of our largest global enterprises.

How long have we been asking this question?

This question has been posed for a number of years now, most recently at last month’s Agile Europe panel discussion, and dating back to Steve Denning’s May 2011 Forbes article entitled: Applying “Inspect & Adapt” To The Agile Manifesto. Even The Scrum Guide eats its own dog food by publishing carefully-crafted revisions every few years. But it was intriguing and provocative to see this question reinvigorated yet again on the big stage of Agile2016. So, what’s next?

I’m not smart or wise enough to predict the future of the Agile movement, but I do feel that now is the time for many larger organizations to figure this out if they want to continuously deliver valuable outcomes and effectively compete in their industries.

~~~~~~

Is it time to host a well-earned retirement party for the Agile Manifesto and align toward Modern Agile? Where should Lean principles be considered? I invite all of us to engage with this post by sharing your views in the comments section below.

 

__________________

If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

How Powerful is Empowerment at Microsoft?

As you skim this oddly-titled post on your iPhone or Android device, you might be wondering what’s happening at that “other” company — Microsoft. Remember them?

Although it’s tempting to reduce Microsoft to a mere afterthought, I am quickly proven wrong simply by looking within my own household. While I edited this weekend post on a Microsoft Surface, I tested it using the LinkedIn flagship app – on an Apple iPhone and an Amazon Kindle (sorry Microsoft, but I dumped Windows Phone a while ago). Oh, and as I was writing this very sentence, my son informed me that our Microsoft Xbox One awakened with a magically improved User Experience. And I just had to ask my younger son to turn down the volume on Minecraft (purchased by Microsoft in 2014). And when I asked my oldest why she prefers an iPad over a Surface, her answer was “Because iPads are cool”.

Welcome to the innovation economy of today, where the technology market is as turbulent and competitive as ever.

How should Microsoft deal with this?

For the past couple of years, the software giant has been on an urgent pursuit to transform within a fiercely competitive environment – attempting to rise above companies like Apple, Google, Amazon and others. The company recognizes that it must reinvent itself to maintain relevancy over the long haul.

The question is ……… how?

What’s been going on inside the company?

This underlying sense of urgency has fueled a significant organizational transformation under the leadership of CEO Satya Nadella, which started in late 2014. My career has carried me in and out of Microsoft’s corporate culture many times over the past 20 years, and I’ve witnessed so many internal “re-orgs” that it leaves my head spinning. However, something about this re-organization “feels” different. Why?

One of the earliest changes was driven by Nadella’s philosophy to extend beyond the traditional, big-company hierarchy by empowering executives to work across previously-siloed divisions. Putting empowerment into action last year, Nadella appointed Julie Larson-Green (former EVP of Xbox and Surface) to the newly-created role of Chief Experience Officer, which crosses all of Microsoft’s product lines – from Office to Surface to Xbox and beyond. Great idea in theory, but how do you get past the silo’ed mentality that drives disconnection and hallway politics within an organization as big as Microsoft?

As part of the company’s journey into Organizational Agility, Mrs. Green sheds light on her own leadership style and the results achieved through Team-level empowerment and ownership. This gives some idea of how she is able to break down these silos and get people working toward toward a shared vision.

What is empowerment?

As we dive deeper, it begs this question: what does empowerment mean in an organizational context?

Empowerment – Power or authority given from one person (Team) to another person (Team).

Straightforward enough, yes? Actually — not really — because the implications of empowerment can be quite interesting. For example, if I empower others in an organization to own decisions that used to be my responsibility, then where does that leave me? Does it put my job and/or salary at risk?

Connecting empowerment to the “new” Microsoft

How do you feel about Larson-Green’s recent statement that Teams will walk over coals for a vision they own? Her views around Agile Leadership are well-aligned, purposeful and insightful – I invite everyone to give her post a read. For those of you who work at Microsoft, I am genuinely excited for the future of your organization under this type of leadership.

Let’s explore how Larson-Green has (and continues) to put an Agile Leadership stance into meaningful action within the company. A few [lightly paraphrased] highlights strongly resonated with me, including:

1. The ability to constantly look for new ways to do things and continue to evolve is a necessary part of any organization’s success.

This is certainly an imperative at a company like Microsoft – innovate & evolve, or risk becoming irrelevant. There are several high-profile examples of companies that did not do this effectively – like Blockbuster Video and Research In Motion. Where are they now?

2. People perform better when they are empowered to own the process and feel responsible for its outcome.

There is science that backs this up (consider Daniel Pink’s DRIVE, which has curated a lot of this research). To build further on this declaration – Agile organizations empower small, self-organizing Teams (and Teams of Teams) to completely own “how” they choose to plan and execute their work in a way that optimizes the outcome.

In this empowered situation, senior leaders have a profound responsibility, which is…

3. Leading…means creating an environment where each person has a voice and is working toward a vision that’s greater than themselves.

Creating this environment sounds simple on the surface, but it’s enormously complex – especially in big companies that foster challenging cultural belief systems that only value the voice of ‘experts’ (for example). In an Agile organization, everyone’s voice matters – the collective intelligence of the people offers incredible thinking power toward innovation and execution of the company’s vision.

How does a leader connect this collective intelligence to a larger vision? This recent post about Purpose at Work (from LinkedIn Influencer, Josh Bersin) sheds some light on this question.

4. If changes to projects and the work are necessary, you must be clear on (the) “why”.

When teaching and coaching within Agile organizations, I mentor heavily on the “why” behind everything. For example, if your organization is using Scrum or Kanban with your Teams, it’s not enough for people to learn the “what” (e.g., here are the meetings, how long they need to be, etc.). To truly anchor high performing behaviors, everyone must have a deeper understanding of “why” the meetings exist, the purpose & intent they serve, etc. More importantly, if an organization makes a strategic change in course, Agile leaders will help everyone understand “why” this change is necessary, which fosters an increased level of engagement across the workplace.

5. Leaders can struggle to let go of direct decision-making.

Empowerment is more than a buzzword – it means that leaders actually give their power away to other parts of the organization. In Agile organizations, the highest level of strategic (portfolio-level) decisions still live at the executive level (like at Microsoft), but what we’re finding is that Agile executives actively listen to the collective intelligence of the organization to inform their decisions – this is a powerful concept that’s playing out effectively, even in big companies like Microsoft. But as these broad decisions are made, senior executives give the direct decision-making power away to the parts of the organization that are closer to the delivery work. This empowerment continues down and through the organizational hierarchy, so that the countless number of detailed daily decisions can be made at the point of execution (i.e., within the Agile Delivery Teams and its alignment with Product Ownership).

The irony is that, as an Agile Leader, the more power I give away (responsibly, of course), the more effective I become as a leader. But what does that really mean? How much risk am I taking when I empower others to make direct decisions?

To better understand this new form of power, consider an insightful article from the Harvard Business Review that examines the shift from centralized power to decentralized empowerment in an organization.

Is this happening in your workplace?

6. Passing on day-to-day decisions allows leaders to really lead, focusing on creating the conditions for the team to make the right decisions.

Do you think that Microsoft CEO Nadella embraces this statement fully? Do you believe that he’s empowered Chief Experience Officer Larson-Green to lead in this way?

In Closing

How do you feel about Microsoft’s new leadership style? Will empowerment lead the organization toward a stronger market position in the future? Consider sharing your thoughts in the comments section below, so we can all learn from each other.

 

__________________

If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

5 Beliefs Every Agile Journey Must Avoid

What are the beliefs that are guiding your organization’s Agile journey? As you’ve probably witnessed, those underlying beliefs influence how people behave on a daily basis, and when they are well aligned with Agile principles, then the pursuit can prove quite beneficial. When there is a stark misalignment, flawed beliefs in Agile can (and will likely) result in a challenging pursuit and even a failed Agile adoption.

What have you experienced in your organization?

High performance Agile organizations share a powerful and principled belief system that leads to increased value, innovation, vibrancy and a healthy element of delivery predictability within the workplace. I’ve also found that these inspiring companies are able to identify and address flawed Agile beliefs that introduce friction against the organization’s pursuit.

Here are a few that I’ve seen play out in a number of organizational contexts:

5 Beliefs Every Agile Journey Must Avoid

Belief #1 to Avoid

We need to compare waterfall and Agile to see which is better.

This belief can lead an organization down a fruitless path of endless opinion-littered debates that waste time, money and energy. When an organization has a sense of urgency for change, then it must invest its resources into changing, not trying to compare and prove that one approach is better than another. Besides, an organization can quickly examine a number of publicly-available comparisons that are available for review and learning.

To better understand the comparison of business outcomes between sequential delivery (waterfall phases with delivery at the end) and Agile (iterative, incremental, continuous value delivery), consider turning to insight-filled works like The New New Product Development Game, this flexible vs. sequential development approach study, and the latest research from The Standish Group. The groups behind these studies have done all of the hard work of comparison for us. Use the conclusions in these (and other) works to decide if an Agile Journey is the right pursuit for addressing your organization’s sense of urgency.

Belief #2 to Avoid

Agile Teams must ‘commit’ to their User Stories at the beginning of a Sprint.

I once encountered a skeptical manager who told me something like: “I believe that *my* Teams must deliver all the User Stories that are ‘committed’.” Careful  … this is a dangerous belief that often leads to challenged business outcomes. When I first encountered this supposedly “Agile” setup, I quickly discovered that the manager was pressuring the Teams to make scope commitments each Sprint. In this situation, no one actually committed to anything except for the manager (who, under organizational pressures, made an unrealistic promise on the scope).

Not only were the Teams consistently falling short of the “commitment” (thus deteriorating Team morale and eroding the predictability element of Agile), the evolving Product was littered with increasing numbers of defects and mounting technical debt.

How do you see this? Is it a recipe for Agile failure?

This flawed belief is in direct conflict with the 3rd value statement from the Agile Manifesto:

Customer collaboration over contract negotiation

In Agile Teams, commitment is a shared value between Team Members —- not a rigid contract between the Teams and management. Once this is understood, it opens the door toward a goal-oriented way of working.

What’s so great about Goals?

In Scrum, for example, Teams craft and strive to meet a clear short-term business Goal each Sprint, which informs mid and long-term Roadmap Goals – all with full alignment to the Vision of the Product (or Project or Program – depending on your organization’s terminology). Goals introduce an element of flexibility, which guides Teams to deliver meaningful and valuable business outcomes on a consistent (i.e., predictable) basis. Most organizations tend to click the “like” button on this delightful rhythm – customers, users, business stakeholders, technology stakeholders, and the great Teams that are empowered with delivery responsibilities.

Continuing on the Scrum example, Teams share a commitment to each other to operate and behave in a way that maximizes their chances of reaching these Goals. When commitment is embraced as a value, then Teams are much better positioned to consistently meet the incremental Goals that ultimately realize the Product’s Vision.

How do you feel about this?

Belief #3 to Avoid

Agile Teams do not have fixed constraint contracts.

We should not confuse Disbelief #2 with the lack of contracts. Agile organizations are often faced with a contract (or an urgent situation) that has either a timeline or scope constraint.

For example, one company I coached had an urgency to deliver the first release of a next-generation app before its competitors, so they had a time-constrained Release Goal. In that situation, they invested extra up-front effort understanding the essential Features needed to deliver a competitive and cohesive first Release into the market. Once the Agile Teams were formed, they worked under the contractual constraint to deliver the first Release within the understood timeframe. To make this work, however, they had a high degree of flexibility to collaborate with the business on two fronts:

(1) the flexibility to deliver essential Features at varying levels of maturity — depending on what was possible within the time frame.

(2) the flexibility to change the Feature list in the Release Backlog — as everyone learned more, they worked together to adapt the Release Backlog to ensure that the highest-valued Features would ship with the first Release.

This flexibility was essential for delivering the first Release within the constrained time frame. I encourage your organization to learn more about the notion of Agile Contracting and how you can structure contractual relationships to operate in this manner.

How do your contractual relationships look right now?

Belief #4 to Avoid

A Daily Stand-up requires the Agile Team to stand, so the meeting will be short and focused.

At first glance, this might sound reasonable. In fact, many organizations’ Agile cultures have adopted this ubiquitous behavior. However, I have observed an alarming number of organizations where the Daily “Stand-up” was nothing more than a group of Developers standing in a circle and reporting their status to a manager who authoritatively stands in the middle of the circle. If this describes your Daily Stand-up, then watch out – because the person in the middle of the circle is not behaving as a Scrum Master and you’re missing out on the pursuit toward high performance, self-organizing Team behavior.

One of the big organizational changes in an Agile journey is the profound shift away from Team-level command & control project management and toward the emergence of small, empowered and self-organizing Delivery Teams. In Agile, daily progress & planning responsibilities shift to the actual Delivery Teams who are doing the work. In a Daily Stand-up event, the Teams don’t have to stand to maintain focus and discipline. Rather, the Teams must fully understand the purpose and intent of this event, which in turn guides their focused and disciplined behaviors during the event.

So, what is the purpose of a Daily Stand-up? It’s designed to provide a transparent and focused environment for Delivery Teams (i.e., Scrum Development Teams) to inspect their progress and adapt their plans in a way that maximizes their chances of reaching their shared Goal with the days that are left in the Sprint. The idea is to reach this outcome in roughly 15 minutes or less. If they choose to physically stand up to do this, great. If not, that’s fine too. In this event, a Scrum Master’s job is to teach and mentor Agile Delivery Teams on how to facilitate this event on their own … to the point where the Scrum Master doesn’t even need to attend.

What do you think of this?

I invite all of us to fully understand The Scrum Guide, which is the official definition of Scrum from the written words of the co-creators, Ken Schwaber and Jeff Sutherland. This will help avoid anchoring Disbelief #4 in your organization. As stated in the guide, this empirical event is called a Daily Scrum, not a Daily Stand-up – although it’s not the name that matters; what matters is fully understanding the purpose and intent of the event (i.e., the “why” behind a Daily Scrum).

If this daily event feels like a wasteful status meeting in your Teams, then consider re-aligning the name of the event and start mentoring around the actual purpose/intent as defined in the Scrum Guide. You might be surprised how quickly it can take hold and launch your Teams to a higher level of delivery performance.

Belief #5 to Avoid

<Insert a common misconception here>

What have you all learned about the beliefs that guide a successful Agile journey? What beliefs pose a danger toward that pursuit? Please share your thoughts on the 5th Belief That Every Agile Journey Must Avoid in the comments section below, so we can all learn from each other.

__________________

If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

Is OpenSpace Agility Right For Your Agile Transformation?

If you work at a company that’s in the midst of a struggling or unusually painful Agile Transformation, I invite you to ask this courageous and provocative question to your organizational leadership this week:

Should an Agile transformation be *embraced* by the people or *forced* by the leaders?

Yes, I recognize that the question only offers two possible answers – it’s phrased that way by design. I have found it to be a provocative, yet powerful question to pose to executive leaders, but be careful — it has the potential to spark a heated and uncomfortable debate. How can you guide the conversation from debate to dialogue? Understanding the concept of urgency can help.

What is a sense of urgency?

I carry the belief that any organizational transformation must be fueled by a collective sense of urgency for change. This collective urgency is often rooted within meaningful business problems (or opportunities), like:

  • Competitive threats in our industry are increasing
  • Our company is losing revenue and market share
  • Our organization’s continued survival is at risk

These are pretty urgent reasons to change, yes? A great leader knows how to establish this sense of urgency in a way that helps people embrace the need for change, even in the face of heavy resistance. Let’s face it – change is hard for many of us, so leadership must successfully inject the “why” behind an organizational transformation. This allows (most of) us to accept that change is coming, even if we don’t like it.

If this is important to you, then consider learning about the principles behind OpenSpace Agility and if it’s right for your organization.

What is OpenSpace Agility?

This emerging organizational-change approach is being led by one of the most influential and skilled Agile Coaches in our profession – Daniel Mezick.

Daniel and his Team recently published The OpenSpace Agility Handbook, which is a 130-page wisdom-packed reference for guiding organizational change with an OpenSpace Technology philosophy. Careful though – it’s pretty deep stuff.

By the way, I’m not here to sell you on the approach. It’s up to you to decide if further exploration carries benefit. What I can offer is a glimpse into my own experience with this approach to help guide your own thinking.

What do I think?

I see the wisdom within this approach as essential for those who seek to guide an urgent organizational transformation by listening to the people who will be directly affected by this change.  Allowing anyone and everyone to co-create and embark on the journey is a powerful way to address an organization’s sense of urgency for change.

Once again – it’s pretty deep stuff and it won’t be embraced by everyone, but perhaps learn more about it and decide if it’s right for you.

So, what might this mean to an organizational executive? Just let “the employees” do whatever they want and see what happens? Isn’t that a recipe for total chaos?

It’s okay to be skeptical, because skepticism invites an opportunity to learn something new. This very skepticism drove me to dig deeper into the underlying principles and practices behind this approach. What a journey it has been.

As an Organizational Agility Coach by trade, I have found that the compassionate principles behind OpenSpace Agility create a powerful bond that fuels an organization’s purpose in ways that leave me in awe. To that end, I am on a lifelong journey to fully anchor my own understanding and beliefs in this space, so I can (hopefully) bring a masterful facilitation and coaching stance for the full benefit of an organization’s mission. If you’re an Agile Coach like me, do you see it this way as well?

“Buyer Beware” (in a figurative sense)

It sounds simple on the surface; however, I assure you that if you choose to dive in further, it will open the door to a vast amount of learning & growth within yourself. It might change the way you think about ….. well ….. *everything*.

Does OpenSpace Agility actually happen in the real world?

Long before the publishing of this handbook, I had the opportunity to live through a ~ 6-month Chapter of Learning in a Fortune 100 company as a member of an insanely-talented Agile Coaching Team (all of whom were better and more skillful than me – quite humbling to say the least).

This team was led by Daniel Mezick’s skillful facilitation during a critical chapter in the company’s growth. So yes, this actually happens in the real world in real companies with an urgent need to change.

For me, the experience was profound beyond measure. Not only did it help the company’s pursuit, it literally changed my life. Note that this was within a huge company that was seeking to find its purpose and how best to let its people own the journey. It was a value-grounded endeavor that created breathtaking levels of energy that continue to guide this proud company’s Agile transformation into present-day.

As you consider further exploration into this approach, I hope you find my perspective helpful.

Thank you to Daniel and his Team for making their wisdom available to all of us through this handbook. I am grateful for the chance to learn from you all.

In Closing

What have you learned about OpenSpace Agility, a well as other approaches for guiding organizational change? Please share your thoughts in the comments section below so we can all learn from each other.

__________________

If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.