The Agility Series

First published on LinkedIn.com

Agile at scale or scaling Agile? Which is a more appropriate description?

Steve Denning recently wrote about Microsoft's 16 keys to being Agile at Scale in an article at Forbes.com. The first key he cited was to Pursue “Agile at Scale,” not “Scaling Agile”.

Denning described the distinction between the two perspectives this way:

Let’s begin by noting that managers at Microsoft talk about being “Agile at scale,” not “scaling Agile.” There is an implicit recognition that “scaling Agile” makes no more sense than “scaling the legal department” or “scaling the cafeteria.” The methodologies of “Agile” and “Scrum” do not constitute, as zealots sometimes imply, a panacea for every possible managerial or leadership issue. There are many aspects of an organization’s activities, including strategy, planning, finance, marketing, and sales, where the goal of “working software” as prescribed in the Agile Manifesto is simply not relevant, at least without significant modification.

The question addressed at Microsoft is: “How do we make the whole organization agile?” not “How do we scale Agile or Scrum?” In answering this question, the methodologies of Scrum and Agile in software development have a huge potential contribution, but they are only part of the story.

He went on to note:

Nor is “Agile at scale” at Microsoft a matter of requiring the teams to comply with the goals of the organization, whatever they happen to be. Inherent in “Agile at scale” as practiced at Microsoft’s Developer Division are the core Agile values. This includes a tight focus on delivering continuous value to customers, not merely generating quarterly profits or boosting the current stock price. It also rests on a deep respect for the talents and capacities of those doing the work, and the teams in which they work, not treating workers as “resources” that are assignable, optimizable and ultimately disposable.

In our book Agile Value Delivery: Beyond the Numbers, which was published about 6 months before Denning's article, we concurred with Microsoft's perspective with the following:

One of the hidden benefits of the model in our book is that we believe, at some point in your propagation of the blended practices within it, that people will have stopped referring to Agile as something that is separate from how the rest of the organization works.

Once that happens, people will stop calling it Agile and simply see it as how they normally work.

This is the state we refer to as “Next Generation Agile” and the point at which we can stop using the term entirely.

Until that time occurs however, a lot of change must occur not just within individual organizations but also in what we teach in universities and business schools.

Agile is not itself a methodology or a set of processes.

Currently, the primary focus for many in the IT industry in particular is on the methods (e.g. Scrum) rather than on Values side of it that help to inculcate the right mindset. But if Agile is a mindset, then clearly it is about people – not process, methods, or practices. It is when it becomes how we think that we can stop referring it as a named something.

This will also be when we can stop talking about trying to scale Agile. To get there we need to start recognizing what that means in practical terms for people who are members of Agile teams.

Microsoft had some additional advice beyond their 16 keys for other big firms setting out on an Agile transformation

• Get good at the science of Agile and Scrum but don’t be overly prescriptive
• Don’t copy others: learn from others
• Build the culture you want … and you’ll get the behavior you’re after
• Stop trying to predict the future
• Optimize around customer feedback

What do you think? Is it Scaling Agile or Agile at Scale?

I'd love to hear your thoughts.

Previously published on LinkedIn.com

Last August I had the good fortune and privilege of both sponsoring and participating in a golf tournament here in Ottawa benefiting the service dog program of www.woundedwarriors.ca which was organized by Barry Finlay and his lovely wife Evelyn (www.KeepOnClimbing.com).

After the golf was over a young lady who had served our country and had loved everything about her job including the overseas deployments, stood up and related a very powerful story of what it is like to suffer from PTSD. From being proud to wear the uniform and not thinking there was a better calling she found herself losing the thing that she felt meant the most to her – her service in the military due to a medical discharge for an injury suffered in the field. She was no longer deployable and deemed to be no longer of value as a soldier. Everything she felt had defined her was taken away.

She talked about the symptoms of PTSD she experienced: the bursts of anger, the bouts of depression, and eventually attempting suicide - twice. And even being angry for being rescued from suicide the first time.

Then she talked about what her service dog Bauer has meant to her. How Bauer creates a safe zone around her. How he has become so attuned to her fears and anxieties that he will nudge up against her to bring her back into the moment. How he will pull her away from a situation that is causing her to feel stressed, as he did when she tried to attend the 2014 November 11th ceremony at the War Memorial in Ottawa (she became overwhelmed by anxiety as the crowd closed in around her so he led her to a police woman to get help). How he will put himself between her and anyone he feels is causing her anxiety to mount. How they work together every day so he can continue being her protector.

Bauer creates a safe zone for her on a daily basis and in the moment. He is trained to sense when he needs to do to make his presence felt so that she can be brought back into the moment. So she can both recognize and control her anxiety and depression. To feel that she is safe.

As I showered the next morning it got me thinking about what it means to be a servant leader and to exhibit servant leadership.

While servant leadership is a timeless concept, the phrase “servant leadership” was coined by Robert K. Greenleaf in The Servant as Leader, an essay that he first published in 1970. In that essay, Greenleaf said:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.

“The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived?“

From https://greenleaf.org/what-is-servant-leadership/:

“servant leadership is a philosophy and set of practices that enriches the lives of individuals, builds better organizations and ultimately creates a more just and caring world. <> Some of the most well-known advocates of servant leadership include Ken Blanchard, Stephen Covey, Peter Senge, M. Scott Peck, Margaret Wheatley, Ann McGee-Cooper & Duane Trammell, Larry Spears, and Kent Keith.”

The philosophy of being a Servant Leader is often discussed as being one of the key ingredients necessary to create and support an Agile culture. The idea is that the role of the leader is not to tell people what to do, but rather to create an environment in which they can experiment and try new things without fear. To allow them to self-organize and self-manage. To on the one hand feel they have autonomy in their work, while on the other hand to know their leaders have their backs. That the leader should do as my good friend Rod Collins (@collinsrod) suggested - create the container and let the team worry about the content. To create a safe zone.

In your role as a leader, are you creating a safe zone for the people in your organization? Do you sense when they need you to step in and be their protector? Do they feel you have their backs?

Previously published on LinkedIn.com

As a child growing up in the sixties and early 1970's one of my favorite TV shows was "Get Smart" (1965-1970) with Don Adams as Maxwell Smart from Control. Max and Agent 99 were constantly fighting the villains from Chaos. Invariably Max's bungling led to losing the small battles along the way to Chaos after which he would utter the iconic phrase "missed it by that much!" By the end of most shows Max, Agent 99, and Control would win out over Chaos (actually it was mostly Agent 99 (Barbara Feldon) that outsmarted Chaos). 

It's a great metaphor for the world that most leaders and their organizations now find themselves in as they face the chaos of accelerating change coupled with ever increasing ambiguity and uncertainty. Some are trying to control the chaos from afar with multi-year plans while others are trying to exhibit control at the edge of chaos.

This concept is also at the heart of complex adaptive systems  (CAS) theory which states that in order to harness change with no anarchy, CAS strives to maintain a balance between the completely ordered, “frozen” regime and the completely disordered, chaotic regime, which is known as operating on the “edge of chaos” (McKelvey, 1999). 

The "edge of chaos" is also where we need to be in order to manage at the pace of change. Does this mean that we always should expect to be successful? Of course not.

In Agile we talk about the need to inspect and adapt which is based in empiricism - we adjust based on what we now know based on what we just did. When operating at the edge of chaos it is highly probable that we will miss the mark occasionally. We will, as Max Smart would say, have "missed it by that much!". And that's OK. 

In a prior post on Being a Servant Leader I talked about the role of a leader in creating a safe environment for their teams to experiment and try new things without fear. When operating at the edge of chaos failures will occasionally happen. It is not that they will happen, it is that how we react to them that matters.

Do we follow our Agile ways and inspect what happened and why and then adapt and adjust based on what we find or do we start apportioning blame? 

Based on the accelerating nature of change in the modern world can we afford to do anything else but inspect and adapt? To do otherwise would actually put us over the edge rather being on the edge. Inspect and adapt is one of the ways in which we can bring order to the edge of chaos.

Inspect and adapt does not mean pressing on in the face of overwhelming evidence that something is not working.

We don't know what we don't know. It is through doing that we uncover the things we don't know. In Agile we call this emergence. Most typically, emergence has been contextualized to the concepts emergent architecture or emergent design. But it also applies to the problem space as well - we devote Chapter 7 of our book to the different types of emergence. Inspect and adapt, when considered as part of an emerging understanding and clarity around the problem we are trying to solve, can enable us to respond in more considered ways to what we now know that we did not know previously.

This leads to the main point of this post. Leaders will often afford their teams the ability to fail and recover but not always themselves. This kind of bravado can be dangerous to both you and your organization.

So it is important that you also have the courage to acknowledge when you miss it by that much in front of your teams. This level of transparency, rather than leading to a perception of weakness, will actually embolden them to also operate at the edge of chaos. Your stature as a leader will increase if you do. 

Continuing to exhibit control at the edge of chaos by inspecting and adapting to your emergent understanding of the problem will enable you to eventually overcome the current chaos so you can move on to the next set of chaotic challenges. 

As a leader, do you allow yourself to fail and acknowledge it? Are you willing to say "I missed it by that much!"?

When I was first introduced to the phrase “strategic planning” in the early 1990’s I recall asking myself if it meant that the act of planning itself was strategic.

I tend to do that with phrases that I feel contain contradictions – like business analyst for example – business analysis is an activity that many of us do on a daily basis and sometimes multiple times a day. So why is it seen as role? But I digress.

When I visualize strategic planning I see the thick binder containing all manner of grand visions and statements as the end result. Each year's annual strategic plan joins the strategic plans from years past; on a shelf that no one dares to look at for fear of having to open one of them and actually read it.

Strategy is a concept that emerged in military planning over many millennia and was essentially made up of setting some objectives, gathering intelligence, and using that intelligence to make informed choices about likely courses of action.  Of course as was famously attributed to Dwight D. Eisenhower the approach was limited but useful,

In preparing for battle I have always found that plans are useless,

but planning is indispensable

Strategic planning  in corporate settings is based on the premise that we can use the past to predict the future. But is that realistic?

Defining and delivering on vision and strategy has been a hit and miss proposition for most organizations for many decades. The reason for this is twofold.

First, the world is not like it used to be. Traditional management and its accompanying models relied on the notion that we can use the past to predict the future. This was the era of 3-5 year plans. Change was slow, and at times imperceptible, and the problems were mostly discrete.

Organizations are now operating in a world of volatility, uncertainty, complexity and ambiguity (VUCA). Additionally, customers expect businesses to be more aware of and responsive to their needs.

Secondly, organizations now face holistic messes rather than discrete problems.

Traditional hierarchies are intrinsically ineffective at enabling the speed of decision-making required to lead at the pace of change. We don’t know what we don’t know and we have to stop the pretense that we do.

Rod Collins, in his forward to our book Agile Value Delivery: Beyond the Numbers said:

“Handling these holistic messes has more to do with having the ability to rapidly adapt to ever-changing customer expectations than with minimizing variances in a fixed plan.”

Handling holistic messes requires whole-of-organization approaches. These approaches encompass iterative strategic direction setting, execution, validation, and adaptability. It requires a mindset that embraces emergent thinking. The window of opportunity to deliver Value into business operations has gotten shorter; the window of stability following Value delivery is immediately followed by the next set of challenges that have to be solved.

Strategic iteration (or iterating strategy execution) recognizes that we cannot use the past to predict the future. Increasingly, many are starting to recognize that we need to adjust how we view strategy:

• From being predictive and deterministic to running a continuous experiment and adjusting what we do next based on what we observe about what we just did (that is use an OODA approach)
• From endless data collection and analysis to looking for and at patterns and developing our ability to both recognize the familiar ones as well as uncovering new patterns
• From the top down wisdom-of-the-leader model to having a networked perspective that includes both internal and external players

That is, we need to move from the perspective of doing strategic planning as an annual exercise to doing strategic iteration as a continuous activity that involves everyone, and then focus our attentions and efforts on what we are actually observing as opposed to what we hoped might happen.

A high school  guidance counselor once told me what he would say to his students at the end of a session where he had to have a conversation about problematic behaviors “awareness is an awful thing “ – once you have been made aware of something you never become unaware of it again.

We no longer live in a world of slow and imperceptible change when strategic planning as a corporate exercise was incubated and when most people felt the problems we faced were mostly discrete. We now live in a world of rampant change and holistic messes. There, you are now aware.

So what do you think? Time to ditch strategic planning for strategic iteration?

(First published on LinkedIn)

Within agile teams, generalizing specialists are valued over the specialists that permeate traditional teams - e.g. on agile teams everyone can do analysis or design on any given day - these are not activities segregated to a given person with the title of Analyst or Designer.

This lack of segregation acknowledges that competencies are not roles. But how did we come to view them as roles?

When I graduated form university  in 1978 in Computer Science and  started my first job as a programmer, we did everything – requirements, analysis, design, development, testing, and deployment.We were generalizing specialists with a bunch of different competencies. Most projects were a team of 3-5 people (or less) so the size of what we could do was often fairly small.

In the 1980’s and the 1990’s we started to move away from that model and became specialists as each of these competencies became roles and then these roles became organizational groups within IT. In the late 1980s and early 1990’s we started to add project management to that list of specialist roles.

As we became more specialized the size of projects we did (or thought we could do) grew exponentially. And so did the size of our failures as was evidenced by the various studies looking at this issue starting in the mid-1990’s.

An off-shoot of this model was that we added a lot of documents, reporting, and controls to our project and software development processes – it all became very heavy.

The Agile Manifesto in 2001 started to change all that from a software development perspective as it tried to stem the bleeding we had created with these monolithic projects and the systems they were to create by recognizing that software development was most successful when we did only what was really important, we keep things simple, and we recognized that we couldn`t know everything up front.

In many ways, Agile takes us back to our roots. On any given day on any given project, any competency can be brought to bear on the work at hand by anyone on the team. No one looks at the other person and says "well that's not your role!"

When we are born we are canvas for learning. As we grow we learn all sorts of things in all sorts of contexts; that is, we develop all sorts of competencies - some through formal education, some which seem inherent in us that we develop on our own through our  interests an hobbies, and some we learn through work. All of the competencies that we develop through whatever means are available to each of us in every context we find ourselves in - including in our work lives.

As illustrated  in the graphic at the start of this article, the people we hire show up with all kinds of  competencies - why would we want to pigeon-hole them into roles and restrict their value to us? Why would we not want all their competencies to be utilized to our collective benefit? Isn't that why we hired them in the first place?