From vague user stories to differences in personal styles, learning how to deal with ambiguity is important for tech leaders.
My first Manager in Testing was the famous author, Cem Kaner. He taught me many things that still impact my work decades later. One quote from him that has always stuck with me is: “Software projects unfold. You understand more over time.” They are difficult to schedule, plan, and estimate. And along with that, “test plans are evolutionary.” Remember, estimates are just good guesses. They are not facts. Accountability with estimates is a major part of the ambiguity in software projects. Estimates, even using a method, are hopefully educated guesses; but, most often, they’re simply just best guesses.
Today, better than historically problematic requirements, we use user stories. Even user stories are intended to emerge and become more defined over time.
All this sounds like chaos and can be a recipe for disaster. Sometimes it is. On a practical day-to-day level, everyone on the team (you, manager included) wrestles with:
- When will this project be done?
- I don’t know, how long will it take you to do that?
- I am guessing a time. I don’t know.
- Is that going to give you enough time?
The question is not is there ambiguity in software development, but rather, how do you manage through it while keeping your staff happy, productive, and collaborative?
What’s the Pattern?
I want to begin this discussion on managing ambiguity while referring to some of my favorite references when it comes to leading and managing technical workers.
Instead of reinventing the wheel, I wanted to build on some great thinking that’s already present in this area:
Paul Glen, Leading Geeks:
What is Ambiguity?
Geek leaders themselves need a high tolerance for ambiguity and an ability to be productive in the absence of clarity. They need to maintain composure and help others to do so in situations clouded by confusion. The ability to help an entire group make sense of its environment and activities lies at the very core of a leader’s role.
Margaret Rouse in WhatIs.com on VUCA
VUCA is an acronym that stands for volatility, uncertainty, complexity, and ambiguity, a combination of qualities that, taken together, characterize(s) the nature of some difficult conditions and situations.
- Volatility is the quality of being subject to frequent, rapid, and significant change.
- Uncertainty is a component of that situation, in which events and outcomes are unpredictable.
- Complexity involves a multiplicity of issues and factors, some of which may be intricately interconnected.
- Ambiguity is manifested in a lack of clarity and the difficulty of understanding exactly what the situation is.
Andy Grove in ‘High Output Management’ calls this the CUA model – Complexity, Uncertainty, and Ambiguity.
What Are Some Examples of Ambiguity?
Software development has a strong reputation for being unpredictable on many fronts. Shifting platforms, changing customers, disruptive competitors, dynamic tools, and processes are the easy and expected ambiguities. The unexpected and particularly difficult ambiguities include dependencies and cross impacts from other teams, shifting schedules and scope, and vague or incomplete requirements/user stories. We are all familiar with ambiguous tasks. This is where people usually start with ambiguity and uncertainty.
Requirements and User Stories
Requirements and user stories are very often a source of ambiguity. The nature of user stories is that they emerge. By far, the number one issue most software development teams face is incomplete, insufficient, or simply just bad user stories.
This leads to:
- Sizing and estimation problems leading to blown estimates.
- Heroics to get the product out. Agile and scrum are definitely not reliant on the heroics that traditional development was famous for, so if you are regularly doing this, there is a problem.
- Building the wrong thing or not what customers need due to vague user stories.
These are only some of the bigger user story issues. There are more.
CI/CD has a different dynamic in the ambiguity and complexity discussion. Since the nature of Continuous Delivery (CD) moves to production are so much smaller, isolated, and much tighter controlled, the types and scope of ambiguity and complexity are narrower.
The focus of this article is not how ambiguous software development is. If you have any experience at all in software development, you already know this. I want the focus to be here is how managers lead through the ambiguity.
What Are The Management Issues? How Do You Manage Through Ambiguity?
John Halamka: Facing down VUCA and doing the right thing references Bob Johansen, former CEO of the Institute of the Future.
Johansen’s take on VUCA is that it will only get worse, but, he says, its presence creates both risk and opportunity, and strong leaders are able to redefine the acronym by turning:
- Volatility into vision
- Uncertainty into understanding
- Complexity into clarity
- Ambiguity into agility
To me, the issues you need to manage through are:
- Productivity–keeping people working
- Morale (from enthusiasm to frustration)
- Churn, wasted effort, wasted time
- Keeping teams engaged, communicating, and creative with so much uncertainty can be difficult.
Ambiguity at the People Level: People have differing levels of tolerance for ambiguity
Paul Glen has a great description of a very common type of ambiguity management dilemma that all tech managers face, as seen in Addressing Ambiguity in Your IT Team: A Meeting of the Minds (Opinion written for Computer World).
The things they (a pair of colleagues on a technical team) say about each other, with intense emotion, sound like this:
- Joe is useless. He can’t get anything done unless every single question is answered down to the minutest detail. He seems immobilized unless all his questions are answered to his satisfaction.
- Jane is useless. Everything she produces is so vaguely defined, it’s unusable. She draws a few boxes and arrows on a diagram and thinks that’s a fully specified system that can be estimated and built
While it is difficult to bridge these differing orientations, teams can benefit substantially when these styles are blended. It becomes easier when people with high ambiguity tolerance recognize that there is a real difference between a drive for clarity and rigidity. Your low-tolerance colleagues want answers, but that doesn’t mean that they demand that answers not change as things progress and teams learn.
People with low ambiguity tolerance recognize that those with high tolerance are not necessarily sloppy thinkers, but good at subdividing problems into manageable chunks.
Some are big, open-ended questions:
- What is the purpose of our organization and what role should technology play in supporting that purpose?
- Who are our competitors, and what product features will give us an advantage in the marketplace?
Others are narrower but still fundamental to our work:
- How should our department be organized?
- What business objectives are driving our technical project?
- What methodology should we use given the nature of the project, technical tools, stakeholders, and team members?
- Who will play what role on the team?
And some are specific yet essential:
- What columns will be in each table?
- How will one process communicate with another?
- What data will be logged, where will it be stored, and in what format?
And for many, the most distressing ambiguity of all is not knowing what the relevant questions are that need to be asked and answered.
Solutions
How do we approach these issues in order to keep the team engaged, productive, and still have a good attitude?
Transparency and communication. The team needs full communication, even over-communication on ambiguous topics. Be clear on what you know, what will probably change, and what you don’t know.
Bring up the topics that your project experience tells you are volatile, uncertain, complex, or ambiguous.
Talk with the team about their ambiguous nature and put it out in the open.
A culture of open communication and trust are important here. Individuals need to talk about problem areas and frustrations along with possible solutions and creative ideas. This may all lead to: innovation, process, or product.
Find out both who has answers and who will be making decisions. Product owners? Architects? Marketing?
Make sure the team has the right skill set here. Knowledge on the platform, system architecture as needed, knowledge of customers. Also, train on the soft skills to collaborate, communicate, figure things out, and courage to experiment.
Part of free and open communication is not blaming or finger-pointing. This is very important if you want to nurture an environment of innovation, taking chances, or courage (an XP value). When the ambiguity and uncertainty of results and reality hits, sometimes there is finger-pointing and blame—and this doesn’t help anyone. It kills trust. It kills teamwork. It can also have a long-lasting, negative impact on collaboration for the team. Managing through ambiguity and uncertainty is an area where seemingly touchy-feely values, culture statements, and soft skills will directly impact the team’s productivity, happiness, success, or failure.
Add to your vision statement team ideals on open communication, trust, no finger-pointing, transparency, accepting evolving requirements and user stories, changing customers, and changing platforms and devices. This is the dynamic nature of product and software development.
Managing Staff: Know Your Staff’s Ambiguity Tolerance
Whether we are talking about Paul Hersey and Ken Blanchard’s Situational Leadership or simply the nature of our work, we need a lot of data points about each team member. Knowing the various technical skills on technical platforms, customer knowledge—all the aspects that we deal with on a daily basis in knowing our employees is critical. Use your judgment to match people together and to match staff to tasks based on level, understanding or ambiguity of the task, and that staff member’s tolerance of ambiguity.
An issue we won’t resolve here is accountability and measurement problems due to ambiguity. For some companies more than others, measurements at the project and sometimes at the individual level are important. Roles and responsibilities are held accountable. But the nature of software development projects is different than measuring, for example, HR, infrastructure, financial projects. Measurement and accountability in high ambiguity projects is possible, but different. Remember, Geek work is difficult to measure.
Summary
The nature of software development is complex and ambiguous. Hopefully, everyone in this field knows that already. If not, work with your team on understanding this. Set a priority for yourself for transparency, openness, and even over communication in the VUCA areas. If you have worked in software development for long, you may take most of this ambiguity for granted. Some of your staff may be quite unnerved by it. Some of this could be cultural, most of this unease with uncertainty and complexity is personality, and staff will need coaching through it.
Your goal is to arm yourself with as much information as you can so that when you are in these situations you can adapt and change your leadership style to certain situations. Know who will be providing clarity and making decisions. Avoid finger-pointing and the blame-game since it is the nature of the work we do. Assign tasks well and understand your team.
