Agile, Design Thinking, and the Leadership Gap - Part II

“Leadership is communicating to another person their worth and potential so clearly they are inspired to see it in themselves.” — Stephen R. Covey

 What If

Imagine what would happen if a small, self-organized team was tasked to create a product. Instead of taking directions on what to do from their boss, they sit down with the product owners and try to understand his or her aspirations. Their interest in the product is almost tangential; what they really want to know is what it is supposed to do and why.

Next, instead of developing a plan to build the product with a defined timeline and budget, they start talking to users about the problems they have with their current product or process. They listen for stories that describe the user experience and take away not design ideas but rather feelings, emotions, and frustrations.

Finally, they get down to designing. But even this doesn’t go to plan, at least in a traditional sense. They start coming up with all kinds of crazy ideas, some of which do not make the slightest bit of financial sense. Some of them are outside the bounds of reality. It is like a madhouse of thinking – people are throwing ideas around everywhere and grouping them together almost arbitrarily. A first principles approach to product design takes an idea and beats it to death with constraints, ensuring that a priori perspectives are identified and validated or rejected.

Without even having come to a design decision, the team beings prototyping and taking prototypes to the user base that you wouldn’t show to a third grade teacher. The user community is freaked out but kind of intrigued. They give feedback on what looks interesting and what might end up with issues, and the team takes it back for another design session. The goal here is to refine prototypes that resonate with end users and reject the ones that do not.

Repeat.

Repeat again. And again.

With each repetition, some prototypes are discarded. Other prototypes are shelved, and some prototypes are enhanced. Each set of community feedback hones multiple prototypes, and the prototypes that float to the top are designed with more fidelity. As the prototypes improve, so too does the fidelity; what started out as a badly mangled cartoon has morphed into a wire-frame diagram describing the interactions between a user and website. Or a tool to help an elderly person stand. 

With a prototype in hand, it’s finally time to commercialize it. And now things get even weirder. There’s still no budget or timeline. There’s no manager directing the project. Some of the people on the team have little experience with the technology being developed. There aren’t any cubes or offices anywhere; everyone is sitting across from everyone else and are spending an unseemly amount of time talking to each other or drawing on whiteboards.

When development begins, it’s not based on a project plan. Rather, it’s based on user stories; aggregates of functionality required by the product owner and the users that iteratively build upon a product. These iterations are broken into two week sprints, each characterized by a list of items that need to be completed in order to fulfill the goals of each of the sprints. The most important functionality is developed first, and the least important elements are saved for later sprints. At the end of each sprint, a minimum viable product (MVP) is released to the product owner, which roughly approximates expected functionality. During the sprint review, the product owner gives feedback on what he/she likes and dislikes about the MVP. This feedback is taken into the next sprint’s planning session, and adjustments are made to tweak the product or completely course-correct. Product development is continual, and feedback on the MVP feeds updates and adjustments as the product is fleshed out and functionality becomes accessible to the product owner and the user community.

There are a few things that do not happen during Agile planning and development. Approved corporate fonts and colors are not discussed. Spelling and grammatical errors are overlooked, and formatting of decks and documents are imperfect. Functionality of the product lacks fidelity; links might not work, or the calculations may be incomplete or outside the bounds of required accuracy and precision. To the team, this is irrelevant – what is important is if the path they are going down is the right one, and to identify what changes need to be made in order to make it better. Agile is not about getting it right the first time. It is the antithesis of everything Big 4 – you never give a finished and fully packaged deliverable to your client. It’s all about iteration.

One could argue that design thinking and Agile are not leadership. They are a process model for product ideation, and a follow-on model for product development and commercialization. Yes, that is correct, but it is much more than that. Why do these exceptional tools that describe what the heartbeat of a company should sound like be relegated to product development? Why can’t these principles of self-directed and self-motivated high performing teams using all of their creative abilities to collectively (and correctly) identify and solve a problem be the basis of a new type of leadership?

It can, and it does. I was part of a team helping to architect the next iteration of organizational design to enable Agile for a Fortune 50 company; tens of millions of dollars were spent over a period of years to ensure that we were crafting the right kind of operational structure to enable Agile. Just as important as the organizational design and change management was the cultural mindset: we had to ensure that “good-enough” replaced “good” during the first passes of product development and that failure was something to be expected and embraced. Product development could not achieve the levels of efficiency we needed and the level of creativity we expected unless employees stopped looking at themselves as “do-ers” and instead bought into the idea of being thinkers. Layers of management and controls were stripped away in favor of personal development, autonomy, and a data-centric approach to validating creative ideas. We wanted to create an environment that gave our people freedom of choice, rather than freedom from choice.

Of course, all is not well in Neverland. Those layers of management did not include senior management, naturally. That fundamental disconnect continues to act as a poison pill to our very expensive and complicated experiment; when demands are made upon you from an entity external to your immediate environment, it undercuts the proposition that you are responsible only to your product owner, your client, and your team. High performing teams are not assembled; they are forged in the effort for and achievement of common goals. Agile is a mindset. It is the how and the why of people interacting with other people. The ceremonies and tools and the technologies run a distant second to this very primary value. Anything that gets in the way of this mindset is toxic.

I like to think of Agile as a choice between two different paths to take; a traditional corporate process versus a user-centric and team-enabling one. Both will get you to the same place, but one of those paths is quicker, less expensive, and much more fun to be on. This journey is something I consider every time I step into a new corporate culture, and the answers usually tells me more about the company than any 10-k ever could.

Jamal Khawaja

Follow me on Twitter or Facebook.