Main Barrier To Iterative Development: Lack Of Imagination

Organizations new to Agile often think their work cannot possibly be broken down into smaller increments of value. In this article, I want to explore a way to get over these objections:  a way that appeals to emotion as much as logic, a way that incorporates some gentle peer pressure via a comparison to the stodgy construction industry, a way that reaches the conclusion that any difficulty in breaking the work down isn't intrinsic to the work but is instead a failure of imagination.

Indeed, when I first engage with an organization for the purpose of discussing how the Agile mindset could help them deliver more value, I almost always hear the same refrain.  Suggestions that the work be broken down in smaller increments of value are usually met with something along the lines of:  "Agile sounds great, and I'm sure these other teams you've worked with got a lot out of it.  But you see, we're different because of reason XYZ, and we couldn't possibly break our work down in smaller chunks.  That simply wouldn't work here."

I've heard this from leaders in advertising, analytics, customer support, design, IT, marketing, software, and/or you-name-it. When I'm skillful enough to overcome the early skepticism and secure space for a little education and experimentation, the organization usually learns that breaking big batches is not only possible but actually fairly straightforward and highly desirable.

This raises two immediate questions:  Why is there such early resistance to breaking down batches?  Also, why do these people think their context is so special that what works for others can't work for them?

I'll tell you right now that I don't have firm answers to those questions.  However, I do have suspicions.  I suspect that many people still view the application of Agile techniques as something new and unproven, which only applies in some very narrow business contexts.  And that is a myth we can quickly dispel.

On my first trip to Barcelona, Spain, I took the time to visit the breathtaking Sagrada Familia basilica pictured below, designed by famed architect Antoni Gaudi.  There is a lot to know about the long history of this magnificent building, but for our purpose, I want to focus on the funding mechanism for the lengthy construction that started in 1866 and that isn't scheduled for completion until 2026.  That is not a typo.  It has been under construction for well over 100 years!

Fig. 1. The Sagrada Familia basilica, “Architecture”; Sagrada Familia;

Foundation Construction Board of the Sagrada Família, 2015.  Web. 

11 Dec. 2015

On the one hand, there was a grand vision for the Sagrada Familia.  On the other hand, from the very beginning the project was to be funded by visitors.  With an expected construction that would span generations, it wasn’t possible to wait until the building was finished to welcome paying visitors.  Thus an incremental approach was used.  For example:

“In 1892 the foundations for the so-called Nativity facade were started. This facade was built first because, as Gaudí himself put it, ‘If, instead of building this decorated, richly ornamented facade, we had started with the hard, bare and skeletal Passion facade, people would have rejected it’” (“History of the Temple”).

Other examples of the Agile mindset at work abound.  In 1910, a model of this Nativity facade was displayed at the Grand Palais in Paris in an exhibition.  I am convinced this was done to keep the stakeholders focused on the value of the building rather than its cost.  Moreover, in 1952, several events of the 35th International Eucharistic Congress took place in the Sagrada Familia, further monetizing the building.  1955 marked the first public fund-raising drive, which allowed society to participate in the construction and to feel more involved.  And “in 1961 a museum was opened in the crypt to provide visitors with information about the history and technical, artistic and symbolic aspects of the temple” (“History of the Temple”).

Thus, the history of the construction of the Sagrada Familia provides us with a concrete (pun intended) example of the concept of delivering value early, and that clearly dates as far back as the late 19th century.  Moreover, of all places, this occurs in the large-scale construction industry.  If people dealing with concrete, granite, and sandstone could figure out how to break the work down in increments of value, I must politely suggest that people dealing mostly with digital work, whether algorithm, document, graphic design, music, software, or video, can do so, also.  Wouldn’t you agree?




Works Cited
“Architecture.”  Sagrada Familia.  Foundation Construction Board of the Sagrada Família, 2015.  Web.  11 Dec. 2015.

“History of the Temple.”  Sagrada Familia.  Foundation Construction Board of the Sagrada Família, 2015.  Web.  11 Dec. 2015.

Similarities Between Lean and Agile

It is said that the difference between theory and practice is greater in practice than in theory. Although I believe this is true of a lot of things, one area that eludes this old saying is the practice of Lean and Agile.

Practicality

The theoretical differences between Lean and Agile are the frequent subject of heated debates, even though their practical implementations often solve many of the same problems. I think those differences aren't nearly as pronounced as they are often thought to be, and that far too much energy is expended on their account. I suggest we focus instead on getting to the business outcomes we all crave by cherry-picking the best arguments and techniques from each. Let me elaborate:

Origins

Of all the differences I hear about, the most prevalent seems to be that Lean seeks to reduce variability in the work so that the system can be optimized, whereas Agile accepts that variability as inevitable and attempts to adapt for it. This description is not without merit from a historical standpoint. Lean was first popular in traditional large scale manufacturing environments, and Agile sprouted in software development where each unit of work is unique.  Though this analysis may be historically accurate, it is also far too shallow for us to conclude that Lean and Agile are fundamentally different.

Practices

The similarities strike me as far more numerous. Both Lean and Agile seek to deliver value to the customer through building the right thing. Both promote a culture of continuous improvement: Lean has kaizen, and Agile has the retrospective. Furthermore, Lean has poka-yoke to mistake-proof problem areas, and Agile similarly promotes the management of technical debt. Both focus on reducing delays. Lean most frequently uses the value stream map as the main tool, while Agile methods often use short iterations for much of the same purpose. Both emphasize the importance of quality. Lean has quality standards, and Agile frequently has a "definition of done." Both promote resolving blocking issues quickly through all-hands-on-deck approaches. Lean has its andon cord, and Agile often has an impediment identification and removal process. Both promote a reduction of Work In Progress (WIP) for the purpose of accelerating flow. Lean emphasizes single-piece flow; Agile urges people to swarm on a common work increments. The list goes on and on.

Values

The parallels between Lean and Agile are actually not surprising. Indeed, a quick examination of the fundamentals reveals similar values. If one compares the principles that underpin the well-known Agile manifesto with the expression of Lean found in the Shingo Model, one notices a common philosophy.

I think the Shingo Model cornerstones of respect and humility are just a highly condensed expression of the Agile manifesto. What I mean by this is simply that the Agile values (and principles) can be traced back to respect, humility or both. For example, humility is implied in the desire to replace planning with a discovery approach. To arrive at that desire, we must first humbly admit the limits of our knowledge and prediction abilities. Similarly, respect is implied in the belief that people are intrinsically motivated, trustworthy and able of self-organization.

Put another way, Shingo’s respect and humility are to Agile what the Maxwell equation is to the inner workings of electric car propulsion systems. All the information is there, but it has to be unpacked.

Fig. 1. "Maxwell-Faraday equation"

Bottom Line

In summary, I believe Lean and Agile are rooted in many of the same principles and values. The challenge of articulating the differences is probably best left to the academics. The doers should focus on taking action instead, because while the differences may be smaller in practice than in theory, practice still makes perfect. I’d love to hear from you if you think this is an oversimplification that obscures some important practical differences.

Works cited

"Maxwell-Faraday equation", Maxwell's equations, Wikimedia, 24 Nov. 2015. Web. 1 Dec. 2015.

Are Google’s OKRs Compatible With Agile?

This month, I present a collaboration with executive consultant and Agile master coach Mario Moreira. 

Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. Take a look at this Rick Klau presentation on "How Google sets goals: OKRs" to refresh your memory. After examining the characteristics of OKRs, and with a few open questions, Mario and I are of the opinion that for the most part, they can be used in support of the Agile mindset. 

Read the full article on Mario's blog

How To Run Customers Demonstrations

Even with the understanding that customer feedback is critical, organizations are often gun-shy about seeking it on non-production-ready products or services. The concerns they have about exposing the insides of the sausage factory frequently revolve around: appearing to lack confidence, committing ourselves to a long list of customer requirements, leaning on employees with varying communication skills, opening the door to unbounded customer support requests, impacting sales as customers wait for upcoming offerings, and generally jeopardizing the relationship with participating customers. Can those risks be mitigated? Yes, they can, by managing the demonstration. Below are some examples of what this means to me.

Let Go Of Defensiveness

First, on the fear of appearing hesitant and harming the customer relationship: In innovation, the reality is that we don't always know what customers want, so we are in fact a bit uncertain. Would customers penalize us for admitting it? That hasn't been my experience. Customers are frequently treated fairly badly by the companies they do business with. Most customers are thus thrilled to be sincerely asked for their input and positively elated when that input makes it into the product/service.

Listening Is Not Agreeing

Second, is hosting a demonstration akin to committing to implementing every suggestion? If left unmanaged, it might be, but this is where customer preparation comes in. Expectations must be set that although feedback will be noted, it will be compiled across a number of customers and considered through the lens of the organization's strategy. Thus, there is a promise to listen, but not necessarily to agree. In my experience, most customers are OK with that.

No Proxies

Third, should the organization's doers be the ones presenting, or should that be left to slick sales/marketing types? I believe the right of first refusal should go to the doers. Most doers rarely (if ever) see, talk to, or hear from customers. Therefore, most will relish the opportunity. The impact of this activity on the doers's level of understanding of the overall business context and empathy for customer needs is almost magical. No doubt the presentations will be a little rougher, more raw, and less polished, but is that such a bad thing? Probably not! I would bet that many customers are a little tired of being managed, influenced, and sold to by public relations-types. Therefore, the rough edges are likely to impart an air of authenticity to the proceedings. That said, however, it probably does make sense for the Product Owner to open and close the proceedings.

On the above point, there is another side benefit to having less polished demos. Research has shown that people are generally reluctant to provide negative feedback if they think one has put a lot of effort into the thing being reviewed. Therefore, too much polish is probably harmful to the quality and quantity of feedback.

Image by John Cook via Flickr

Transparency

Fourth, might sales be delayed by unveiling future versions of the product? Sure, yet demonstrations are held with only a sample of customers, not the entire customer population. Thus, this potential impact on sales should be quantified and the cost/benefit of the feedback evaluated. Don Reinersten provides guidance on valuing information. I never advocate doing anything out of inertia; deliberate decisions are much better.

In summary, can all risks be taken out of customer demonstrations? No. Does the value of the feedback received exceed the potential cost of the risks? If the demonstration is properly managed, I think the answer is an emphatic "yes." Customer demonstrations don't have to be thought of as minefields of risks. They are events that can be prepared for the greatest benefit of all participants. As with most other processes, a clever organization will get better at it with practice. In the comments section below, I invite you to share your tricks to get the most out of customer demonstrations.

P.S.

A former colleague insists that no demonstration should conclude without the Product Owner asking, "Would you buy this today?" as a way to better assess the value that the customer perceives in the product. I think this is a great practice when the value cannot be marked-to-market through an actual exchange of money. The question will likely garner a lot of Nays, but the eventual Yays will more than make up for it all.

Works cited

John Cook, "Fresh Sausage Class", Flickr, 11 Mar. 2015. Web, 15 Oct. 2015.

Confused Managers Need Guidance in Agile Environment

The confusion around the role of the manager in an Agile environment seems to reach its peak just as teams start to exhibit real signs of self-organization. When managers see that they are no longer the driving force behind the work management, some conclude that they are no longer needed at all, and this can lead to rash behavior. Although completely understandable, I believe this erroneous conclusion is the sign of an over-reaction that needs to be addressed by the change agent. Until the world is completely teal and corporations "flat", great managers will continue to play a key role in many large organizations.

In a self-organizing world, managers should no longer oversee every aspect of the work.  Instead they should attend to the environment. Where the Product Owner focuses on the product, the manager focuses on high performing teams. Managers are to teams what gardeners are to plants.

Gardening by Stephanie Wauters from the Noun Project

We would all have a good chuckle if we saw a gardener asking the tomato plant for a commitment on when its fruits will be ready, telling the cucumber where to stretch its vines, challenging the cabbage and broccoli to get rid of pests on their own, weighing and comparing the squash against objectives determined at the beginning of the growing season, and grandstanding in the middle of the pumpkin patch on the lofty harvest aspirations of the landlords. We would laugh, because we know that none of those behaviors will lead to results. However, in most corporations today, this is exactly what managers do.

I don't believe this is what we want from managers anywhere, but it is especially damaging in organizations that are trying to embrace the discovery mindset. Managers, like good gardeners, must be responsible for the environmental conditions and trust that their people will maximize their own potential.

To push the gardening analogy a bit further, here’s one way to illustrate the point:

Gardener	Manager
Fertilizes the ground for maximum growth	Trains the people on technical and people skills
Protects the plants from strong winds	Shields the people from needless distractions and enables a culture of focus on the work
Tills the soil and removes rocks	Provides the best tools and devises a plan to manage technical debt
Meters the amount of sunlight reaching the plants	Interprets the organization’s strategy and gives people a clear sense of "true North"
Prunes the plants to maximize the output of the garden	Mentors and coaches people so that they either realize their potential or find a role that is a better fit
Plucks weeds as they appear	Removes impediments on behalf of the teams
Installs trellises to steer plan growth	Expands the teams’ bounded authority as they become more skilled at self-managing
Waters regularly	Fosters a culture of continuous improvement

I don’t know about you – and please feel free to give me your thoughts in the comments section – but that still feels like a lot of work to me. However, it’s a work of a different nature for sure; it’s more leadership than management. As such, not everybody will immediately excel at it. Nevertheless, I think the investment of energy in better leadership is well worth it. Also, isn’t it a lot more fun and ultimately impactful? Therefore, I think managers should view an Agile transformation with optimism.

Works cited

Gardening, Stephanie Wauters, Noun Project, Web. 1 Sep. 2015.

Where to Start a Transformation?

So you've decided to go ahead with a transformation. How should you go about it? Where should you start? And whom should you start with? Does it matter? I suggest that it does indeed matter, and a lot.

For me anyway, one method has worked so much more successfully than the others that in my mind it is a “no-brainer.” That method is to cultivate fully the most fertile plot first. I call this the depth-first approach. Let me explain that. One of the first decisions that need to be made is whether the transformation will be attempted by moving everyone in lockstep, or whether there will be some form of staggered rollout and whom to start it with.

False Choice

Forgetting for a second the irony of using a big batch approach to lead a Lean or Agile transformation, we find that even the lockstep method ultimately devolves in a gradated approach. I've never seen a sizable group of people in which everyone is subject to identical constraints or internalizes new concepts at the same rate. Thus, even when the big batch method is attempted, you end up with pockets where certain concepts are applied ahead of others. Therefore, in no time at all some individuals and teams require a different kind of coaching. Whatever economies of scale are hoped for with the big batch approach, they quickly evaporate due to the now differentiated demand for coaching. Since coaching and mentoring capacity is usually limited, the change agents have to prioritize the opportunities for assistance.

The Who

Perhaps you pick the toughest critics and attempt to convert them first, figuring that if you can move them, you can move anybody in your organization. Or perhaps you are better off aligning with like-minded people and equipping them to evangelize on your behalf so that you can magnify your influence.

Pnautilus / Wikipedia

The Where

Space-wise, you could identify some of the organization's biggest problems and attempt to solve those with the Agile mindset. If you crack one of those nuts, the likelihood that the others can be cracked too increases. On the other hand, maybe you should be wary of what is likely to be a tougher slug and instead pick a space where success is both more likely and less distant.

Mind Your Credibility

If you work in an organization that looks anything like the ones I've worked in, you know that people are more swayed by results they can see than unverifiable tall tales of riches. I try to never forget that as the change agent, I'm also perceived as the salesman. Increasingly tangible evidence of success may be required to move the transformation through the typical phases of adoption. This is where native stories are so important, and why I set out to create and record them as soon as possible.

Selecting the Right Investment

Every bit of transformational success is akin to making a payment to the bank. With that payment usually comes a deadline extension and an increase in credit score. Over time, as a portfolio of native successes is built, there are fewer resistors. Success begets success.  That's why I choose to cultivate deeply the most fertile organizational plot I can find.

I'd sincerely love to hear from those who have experienced success with the breadth-first approach. I'm curious to know what conditions had to be true to make it work.

Maximizing the Contribution of Contractors and Consultants

When an organization lacks a required skill set, contractors or consultants are often hired temporarily. This temporary staff augmentation is generally difficult to pull off successfully due to the imperfect context sharing, potentially divergent incentives, the uneven power distribution of the client-supplier relationship, and cultural impedance mismatch among others factors. Nowhere is the effect of these factors more evident than when the hiring organization operates with the Agile mindset. Under those circumstances, I've had most success when I remembered to do three things: heed legal advice, use higher-level contracts, and treat them like employees.

Don't Go It Alone

First, a disclaimer: I am not a lawyer; implement the opinions below at your own risk. Whether a worker is legally deemed an employee as opposed to a contractor can have important consequences on an organization. A worker's status may impose constraints on the management style - I use "management" in the broadest possible sense - you can use with the person. Based on the evolving legal landscape, the distinction is evidently not easy to make. So on this front, please get legal advice and heed it.

Michela Tannoia / Noun Project

Bound By Contract

Second, I have observed that how the contract is written will influence the type of collaboration I can expect. Contracts that are higher-level or about the work method (i.e. meta contracts) seem to enable a level of flexibility critical to Agile collaboration.

If a contract is very detailed about the problem to be solved, the artifacts to deliver, and the timeline and milestones to achieve, then the other party legally bound to do exactly that. This can be problematic in the face of dynamic business conditions. For example, if new validated learning dictates that the whole project should pivot, the choice is then to let the contractor plow in the now invalidated direction or renegotiate the contract. Both are unappealing choices. This is why I prefer to write Statement of Work (SoW) that are less specific about the work, but more explicit about the method. A high-level description of the problem area the people will work on feels sufficient. I prefer to put my energy on getting an agreement how the work will be attacked. This can be a flavor of Lean, Agile, etc. Ideally, this agreement is reached with both the decision makers and the people that will actually get the work done. Yes, this removes a layer of legal protection. And yes, it relies a lot more on trust. But that's a bet with odds that I, as a leader, can influence.

Execution

Third, with the paperwork out of the way, it’s time to turn to the doers. Whenever possible, I try to forget which organization the people working on my project come from. People are people. If the established motivating principles of self-organization, face-to-face collaboration, and empowerment are important to employee-type humans, then they also apply to contractor-type humans. Unless there are legal or operational constraints this not only means full integration with employee teams and squads, required access to strategic and tactical information, and participation in appropriate meetings and social gatherings, but also colocation, feedback, conversations and personal interaction with managers.

So by limiting the objectification of workers, trust is often increased and the organization can be a more productive and enjoyable place to work for everyone. Consequently, companies the organization contracts with finds the business collaborative and easy to work with. This motivates them to send their best people.

Collaboration And Results Over CYA

The best statements of work are often flexible and adaptable to changing needs, even with the legal implications or limitations this often imposes. Traditional contracts far too frequently create inefficiency and unproductivity. A supplier who insists on traditional, hyper-detailed work output contracts that limits collaboration may be one to avoid. I will certainly continue to be discriminating. I encourage you to be too.

How To Influence Stakeholders Of A Transformation

I think we can all agree that in order to get an organization to internalize the Lean/Agile/Discovery mindset, a lot of stakeholders must be influenced. Moreover, the pesky thing about stakeholders is that they are all different. They believe in different things, adopt different values, have different experiences, and are subject to different pressures. A single message is thus unlikely to resonate equally well with all of them, or at least, that is my experience. Therefore, I find it useful to think of different ways to reframe my message. I now try to meet them where they are by casting the various benefits of a transformation (link to Why Bother article) in a different light based on the person's concerns, or at least likely concerns if I can’t ascertain for sure. Here are some examples that have worked for me:

Lorenzo Stella / Noun Project

Line Managers

Line managers are typically responsible for demonstrably getting things done through their team. In traditional organizations, these managers have to report the team's progress to superiors. It should thus be no surprise that their immediate reaction to a coach's request to let the team self-organize is met with fear and doubt. Hell, most of the principles that underpin the Agile manifesto can be perceived as heresy. That fear is understandable. I’ve experienced it myself. It can be scary to remain responsible for the outcome while letting go of the traditional controls, however illusionary they might be. I have had success allaying that fear when I was able to establish convincingly that self-organization leads to greater ownership of outcomes, which leads to more creative solutions to problems, which are themselves the precursors of good results.

Executives

Business executives must also support cultural transformation. As an Agile coach and friend of mine is fond of saying, “If the boss isn't talking about it, it's unlikely to be viewed as important.” How do you get someone responsible for the Profit and Loss Statement to support a change that demands relaxing, if not eliminating the traditional controls of schedules, status reports, and feature/content contracts? The key is to make the case for a different path to great financial results. For example, the transformation is in part about developing the skill to differentiate and emphasize the high-value work at the expense of the lower-value one. By putting more of our investment toward our best bets, we tilt the business odds in our favor. And while we perhaps make fewer promises about the future – history tells us that promises based on false certainty are frequently broken anyway – we know that we generally hold a better hand, as in poker, than we did before the transformation.

Sales And Business People

In many circumstances, in order to get the invaluable customer feedback, we will have to seek the assistance of sales or business people. When I have requested access to the customer, I have often been met with the fear that comes from bringing one's customer inside the sausage factory (this article contains tips on overcoming the fears). Those fears, real or imagined, must be weighed against the benefits of information value for the company and increased engagement for customers. I have found that people will agree that the ability to deliver more customer value and increase the loyalty of customers in the process is a win-win proposition.

The Doers

To me, the most important people in a transformation are the people who get the work done. Call them individual contributors, staff, or simply people (though, please, not the dehumanizing  “resources”). In most environments, that's a mix of engineers, technicians, analysts, marketers, accountants, lawyers, writers, designers, and others. Most of them view any proposal for change with a cynicism cultivated by yearly process changes that usually only serve to make their lives more difficult for no apparent benefit. When done honestly, I consider a Lean or Agile transformation different, because it is culturally driven, not process-driven. To dispel the fear of abuse (a strong word, I know) by the next wave of process, I like to talk about the principles of autonomy, self-organization, greater business context, more authentic feedback, teamwork and collaboration, and impediment removal. I never promise that it's all sunshine and rainbows. However, I do genuinely believe that it leads to a better quality of life for all. That usually resonates, and raises the bar for expectations, and I'm fine with that.

Meeting Them Where They Are

To effect a successful Lean or Agile transformation, all you have to do is change product development, marketing, sales, customer support, finance, manufacturing, and Human Resources, but that's about it. Obviously, you are not going to change these functions yourself, so you need to influence stakeholders. To paraphrase Dale Carnegie, there is only one way to get anyone to do anything. You need to make them want to do it. Thus, as change agents, we need to learn how best to position the benefits that go along with a transformation. I suggest that targeted messaging should be one tool we have. Do you have a similar experience?

What Are The Benefits Of Agile?

. . . or Lean, or whatever one may wish to call the discovery mindset? My thoughts on the benefits an organization stands to gain by going through an Agile transformation have evolved over time. I’ve come to believe there are benefits on multiple levels. Awareness of them helps me focus on the prize and become a more effective participant, coach, and leader. Here are some of the benefits I have witnessed first-hand.

nicubunu / Free Stock Photos

Effectiveness

When I first experienced Agile, I was a participant in a Scrum team. My initial reaction was that we were going to be a lot more effective at our job. With better communication, a focus on a common goal, and more frequent validation of our wares, there would be less wasted time and fewer self-inflicted reworks. And so it was.

Money

Over time, the organization got better and faster at cranking out products and services through a more flexible, more collaborative workforce, and I concluded that the transformation was about more money for the corporation. We were operating with a higher level of quality, so better financial results were indeed part of the equation.

Customer Intimacy

After better internalizing the “customer collaboration” aspect of the manifesto, we developed outstanding relationships with customers. We had a stretch of more than a year when we did an end-of-sprint demonstration to one or more customers without exception (See this post for tips on making demonstrations happen). At one such demonstration, a customer asked if she could purchase the product right then, about three months prior to our expected release date, because it met her needs! It then dawned on me: this new mindset is really about delivering customer value. Better financial results are just a trailing consequence.

Fun

Later still, as the rest of the leadership team and I evolved our main management paradigm, I started to piece together a different picture. There was a lot more energy in the office. Employees had taken control of their physical space, work tools, and organization. People from far-flung divisions wanted to join us just for the sheer fun of it. It felt like a much happier place, driven by intrinsic motivation. And since plenty of research suggests that happier employees lead to more successful organizations, I began to think that a perfectly valid reason to pursue such transformation is the pursuit of happiness.

Effectiveness, financial rewards, customer value, and happiness all seem like valid reasons to start down the path of a transformation. In fact, I think they all co-exist to some degree. Have you found something else? What is driving your transformation?