Image from Woobro Design

Contributors: Cliff Berg, Philippa Fewel

Agile works very differently in different organizations. The same is true of DevOps. The dilemma then is how to compare and contrast? How to learn what will work best for your situation?

In this blog series, each post will consider a different organization persona – that is, we will describe an organization, and apply Agile 2 ideas to that situation.

An important thing to realize is that Agile 2 ideas are not new! People use them all the time! – have been using them! The same is true of the ideas in the Agile Manifesto – those ideas were not new. In fact, everything described in this blog series is based on actual experience – experience using these ideas before they were collected under the banner of “Agile 2”.

Where to start though?! A big, established organization in a conservative industry is the hardest case for Agile. Let’s not start there; let’s start with the simplest case: a small single product startup with one product team. Baby steps!

Starting Up the Startup

Startups have a-lot of energy. The age profile also tends to be relatively young: there are no “old timers”, because the startup itself is young. They also have no legacy – they are a clean sheet of paper.

Agile is often equated with startup culture, which is ironic because Agile was created by a bunch of old timers! – and today they are really old! But what matters is the ideas, not people’s ages.

The primary challenges in a startup tend to be as follows. The organization’s strategies need to address all of these things:

• Validating the market need, product vision, and competition.
• Creating the right culture in the budding startup organization.
• Establishing patterns for how issues are identified, discussed, resolved, and decisions acted upon.
• Managing costs, so that profitability can be achieved while cash flow is managed.
• Managing risk, so that the product can be sure to work, work well, and not create costly problems.
• Finding skills.Making customers aware of the product.

A startup has founders – usually a team of a few people. These founders will have obtained the financing needed, and it is their responsibility to devise strategies and put things in motion. One of the things that they need to put in motion is product development.

Organizing Product Design and Development

The most common approach used by the Agile community would be for the founders to set up a Scrum team, and then stand back. Most likely one of the founders will be made “head of development”, and that person would appoint a Scrum Master for the team.

One problem with the typical Scrum approach is that the very important activity of product design is not addressed. Also unaddressed is how early versions of the product will be market tested. This gap is not well addressed by Agile approaches that are commonly used, although some individuals in the Agile community have tried to address this, such as Roman Pichler, Jeff Gothelf, and Dan North.

Principle: Obtain feedback from the market and stakeholders continuously.

Principle: The only proof of value is a business outcome.

Principle: Product design must be integrated with product implementation.

The Agile community has come to embrace “Lean startup” methods, which include defining small “minimum viable product” variants to try with real customers, and then using feedback to inform what to abandon and what to build next. Agile 2 embraces that idea, and encourages one to obtain feedback from users continuously, and to also put the most weight on actual business outcomes: just because a team has produced working code (a “MVP”) does not mean that anyone wants to use it! (a “MMP”)

The founders are in the stage of organization design. Perhaps a better approach would be to design the organization thoughtfully, by considering things like,

1. How the products should be defined and market tested.
2. How the products should be built.
3. How cash flow will be managed through those activities.
4. How sales will be generated – through publicity, marketing, distribution partners, and so on.

However it is set up, one of the founders will likely be asked to organize numbers 1 and 2 above: that is, the product definition and delivery system.

This is where many startups make a mistake: the founders divide up the work. Each person then focuses entirely on their area – their “silo”. Also, design and development are often two separate silos. Division is necessary, but creating silos leads to dysfunction.

When Elon Musk founded SpaceX, he knew nothing about rockets, except that he wanted to build one. He hired Tom Mueller, an experienced rocket engineer at TRW. Musk put Mueller in charge of rocket development, but he also said, Teach me. Musk conducted the duties of a CEO, but he also paid attention to how their product – their make-or-break product – was being built. He wanted to understand every design decision, because he knew that every decision impacted the razor thin tradeoffs that would make the difference between success and failure.

Principle: Technical agility and business agility are inseparable: one cannot understand one without also understanding the other.

Principle: Business leaders must understand how products and services are built and delivered.

Principle: Technology delivery leadership and teams need to understand the business.

Today Musk is still CEO, and Gwynne Shotwell is their President and COO, and they have lead engineers for their various products and research efforts, but Musk himself is now an expert in all of those, because he knows that decisions need to be holistic, and he wants to be able to understand every issue. He does not wear blinders or say, That’s someone else’s area – I don’t need to know about that. He knows that there is a difference between delegation and ignorance. When an issue rises to his level, he wants to be able to understand every dimension of the issue.

Getting back to numbers 1 and 2 above; we do not want to prescribe how one should organize these activities, but one possible approach is to create two teams: a product definition team and a product development team, and closely link them using a “dual track” approach. In that approach, the product definition team is responsible for understanding the target market and defining possible product concepts.The development team builds those and helps to deliver them for test marketing.

Principle: Product design must be integrated with product implementation.

However, these two teams do not work independently: they collaborate by sharing members, and by meeting on a frequent basis. It is also expected that product ideas can come from the development team: the flow of product ideas is bidirectional.

Let’s first consider the development team. A Scrum team will be expected to “self organize” and establish a workflow. The team’s Scrum Master facilitates discussions and retrospectives, and interfaces with leadership – the organization’s founders.

There are several problems with this approach. One is that telling the team to use Scrum is telling them how to work.

Principle: Fit an Agile framework to your work, your culture, and your circumstances.

Instead of prescribing a “framework” for the team to follow, it would be better to conduct a Socratic inquiry and ask them what will work for them, for now – they can change things as they need to. Have them devise their own workflow, considering ideas from Scrum, Kanban, Behavior-Driven Development, and other methods or frameworks that they have encountered. If they are leaning toward what seems like a suboptimal approach, ask questions to make them think about the downsides of that approach. Propose “What other approaches could you consider?” questions. If those do not lead in a good direction, then ask “What if you did this?” questions, but make it clear that those are just questions. Do not tell them how they should work – let them decide.

But who conducts the above Socratic inquiry?

Self Organization Is an Aspiration – not an Absolute

Agile espouses the idea of a self organizing team. That idea is very powerful but misunderstood. For self organization to work, there usually needs to be leadership who coach and train the team to operate autonomously. In other words, leadership is needed to enable a team to be leaderless.

Even so, teams often want a team lead. They want someone who is an organizer, and who runs interference with those outside the team, so that the team can focus on its work. They also usually want someone to make decisions about the myriad things that the team does not have much interest in. Being leaderless and having to deal with all that as a team is very demanding!

So the architect of the design and development functions – the founder who has agreed to get design and development organized – needs to decide what team model to use: let the teams entirely self organize, or designate some leaders and see how it works out. Judgment is required, because a team will likely not know how to make that decision, unless they are very experienced. Continuously assessing the teams’ abilities is a key function of leadership.

Principle: Self organization and autonomy are aspirations, and should be given according to capability.

The “Mission Command” leadership model has military origins, but it is actually a very progressive model. The distinguishing aspect of the model is individual empowerment: allow those in the field to make their own decisions about how to accomplish the mission goal.

In the Mission Command model, a leader assesses the ability of a team to operate independently, and then delegates to them the level of autonomy that the leader believes that the team can handle. The long term goal is to make teams as autonomous as possible, by giving them training and experience and whatever is needed to make them more autonomous, but teams rarely start out with the ability to be autonomous. According to the article, A command philosophy for the information age: The continuing relevance of mission command,

“Mission Command requires a certain minimum standard of training. There is no point in giving subordinates freedom of operation when they simply do not know what to.”

In any untrained team without a leader, a leader will usually emerge. The problem is, a leader who emerges is not necessarily a good one: it can be someone who is merely more assertive than the others, or more popular. What you want is a leader whose motivation is to help others – what John Doerr calls a “missionary” rather than a “mercenary”.

Such a person often does not “look like” a leader: they might be soft spoken, and a good listener. They are a natural helper and an organizer. If you identify such a person, you might ask them if they are willing to be the team lead.

What kind of leadership is intended though? Leadership has many dimensions. In fact, a team usually has several leads of different kinds, and each person is also their own lead. A development team usually needs thought leaders and decision arbiters pertaining to at least three dimensions: (1) technical design; (2) the technical development process, which for today’s software products is often informed by methods of “continuous delivery”; and (3) the overall team workflow and its interaction with other teams – particularly the product design team.

Leadership is therefore not confined to one person. In fact, each person needs some leadership coaching. Everyone should be aware of the preferred leadership models of the organization.

Principle: A team often needs more than one leader, each of a different kind.

In addition to leadership on technical issues, there needs to be someone who can speak for the team, and advocate for it. That person needs some decision-making authority: otherwise, they will be handicapped in their role. However, to be effective, they need to use their decision authority very sparingly. Their primary mode of operation with the team should be Socratic inquiry: How are we dealing with these issues? What do you think of that? Have you considered this?

The person who speaks for the team is the team lead who the founders will come to rely on. They need to trust that that person is truthful and transparent. That person is usually referred to as the “team lead”, even though they are not the only leader within the team. The team lead is both an inward facing leader and an outward facing leader: they interact frequently – daily – with their team, but they also interact a great deal with management.

Individual Coaching and Mentorship Are Essential

The Agile community emphasizes coaching teams. That is extremely important, but the community has forgotten about the individual. Individuals need coaching too.

To prepare someone to be a lead – any kind of lead – coach them on the kind of leadership you are looking for. Explain that a leader is not someone who tells others what to do all the time. You want leadership that puts the team first, and that is focused on helping the team to be its best. Convey that you expect them to stay aware of everyone’s situation – how they are doing, what they are doing, how they are doing it, and what challenges they might have. Yes, the “how” is important too – all issues are important. Leads should not live in knowledge silos.

Explain that it is not a lead’s job to decide everything: that questions and gentle suggestions are the preferred mode.

Principle: Good leaders are open.

But also explain that sometimes they will have to make a decision; and that when they do, they must take responsibility for it, no matter how it turns out. Explain that transparency, honesty, and integrity are essential.

The founder should build a mentorship and coaching relationship with each lead, being careful not to bypass the team lead by directly influencing others on their team. Agile focuses very much on teams, but the Agile 2 principle “Individuals matter just as the team matters” reminds us that individuals are just as important.

Principle: Individuals matter just as the team matters

The team lead needs to become someone who you can rely on for leadership of their team, because you cannot do it all, and you do not want to become a leadership bottleneck as the company grows. Turn the team lead into a leader who knows how to grow additional leaders among the team: leaders who are inquisitive, who are good listeners, who let others make decisions within their range and who put others first.

Principle: Professional development of individuals is essential

Something that often gets lost in Agile teams is the extremely important element of individual relationships. Team members need to have relationships of trust with each other; but the team lead also needs to have a trust relationship with each member of the team. This requires one-on-one interaction. As Johanna Rothman says on page 31 of her excellent book Practical Ways to Lead and Serve (Manage) Others,

“As a manager, you need one-on-ones to build and reinforce a trusting relationship. You use the one-on-one to reinforce what people are doing well. You offer time for practice and discussion for how the other person might offer feedback or coaching to his or her peers. You might offer feedback and coaching to the person directly, depending on the context.”

Also explain to any lead that they will be expected to initiate discussions about things that seem to be overlooked, and help to get those things resolved: that while the team is expected to pay attention to all issues, they have limited capacity to be able to focus on their work and also think end-to-end, and so someone needs to be always watching for things that are being overlooked. This applies to each dimension of the product: product design, technical design, technical delivery process design, and overall workflow, and any others that are important for the product: each important dimension needs leadership.

There is an important nuance here: a lead does not want to be the only one watching for problems: if you create that impression, then no one else will feel a sense of responsibility for noticing issues; but at the same time, someone needs to be focused on the big picture and how things fit together. Making things all fit is enormously hard, and if no one is focused specifically on that, really bad things can happen – like “game over” things.

There Is No Magic Answer

Considering these ideas, a founder might decide to set up a product design team team, consisting of a few people: perhaps a marketing guru, a UX designer, and product manager who has experience with and relates to your target user community. Suppose that the founder also creates a development team and designates one or more leads for that team.

The founder then puts on their Socratic hat, and gets all of these individuals in a room. That’s quite a few people, but not so many that it is unmanageable, and the goal is just to define the problem and get these people working together.

The founder tells them,

“I want you to define some versions of our product idea that can be tested and compared. Get a willing beta user population. Get some things out there, and see which features and ideas connect. How should we work? What is our process? And by the way, I only care about what people are actually willing to pay for or use for real: if they say that they like something, I don’t really trust them – not unless they cough up money or actually start using it themselves. And include a couple of the developers when you talk to users! – maybe rotate through our dev team. They should have first hand experience looking through the user’s lens.”

The founder gets nods, and there is some conversation about how to approach this. The founder mainly listens and assesses: is the conversation productive, with calm dialog and rational analysis that progresses toward resolution? Does the direction seem competent and viable? If not, some questions can be asked to perhaps steer things. If that does not work, then perhaps there is a need for some offline conversations and a reassessment of the organization’s abilities.

Principle: Provide leadership who can both empower individuals and teams, and set direction.

If the conversation continues in a good direction, then the founder’s job is done for now: all they have to do is check in with these people on a frequent basis, and continuously assess if they are getting results, or if they are stuck on something. The founder should encourage discussions about issues and make sure that the issues get resolved, but nott tell them how to do their jobs. They should be allowed to be creative.

The teams need to decide how they will do their work. Their leads should use their leadership skills to make that decision process as effective as possible. Toward that end, they should not default to the get-everyone-in-a-room practice that is popular in the Agile community – which the founder did above to kick things off.

Instead, a leader should be sensitive to the fact that people communicate and collaborate differently. For simple issues, sure, get them all in a room; but for complex discussions, let people decide how to share their ideas: broadcast the request for ideas, and some people will share their ideas in a written message, and others will say “Let’s meet!”

Empower people to use what works best for them, and be prepared to provide avenues for all opinions to be considered.

Principle: Foster diversity of communication and diversity of working style.

A leader should also watch for the formation of “in groups”. It is essential that everyone be a participant. If it appears that a few people are meeting and talking all the time, the leader should ask the others if they have ideas, and if so, suggest that they share their ideas in writing. Some people write better than they talk. Make sure that everyone is able to contribute to the degree that they want to, and that their contribution is accepted and included.

This Is an Art – Not a Science

At some point – if you are lucky – the marketing team will report that users are really liking a particular variant of the product. But suppose that someone on the development team says that they think the users like it because they don’t know any better. She says, “They have not seen what would really work for them – we have not created the variant that I suggested, that would kick ass.”

The product manager then says, “None of our competitors does it that way – we would be the only one, and market research has shown that people are not asking for that.”

The developer then says, “Because they have not seen it. As Henry Ford said, if he had asked people what they wanted, they would have said they wanted faster horses.”

Now you have a quandary. The developer might be uniquely visionary. She is aware of touch screen technology that makes a whole new approach possible, but no market research says that people want that. Is she right? Or is the market research right? The only way to know is to build a prototype and test market it. The problem is, as the product manager says,

“Building that will be very expensive. We would have to focus just on that for the next three months, and could not test market anything else.”

Others on the team agree. One of the developers says, “I don’t think that people will use a phone that does not have a keypad – actual buttons.”

Another developer nods: “I wouldn’t. I want a keypad.”

The developer with the idea sighs in frustration, and sits back in her seat.

What do you do?

Agile 2 cannot solve that. There is no magic answer. The issue comes down to the quality of one’s visionaries, and how much you trust them. If you trust them, go with it. If you do not, then use the collective brains of the group, talk the issue through, do the experiments that you can afford, and make your best decision – informed by the outcomes of the experiments.

That process – accessing the brains of your teams to pull their honest ideas and thoughts out of them, and then assessing who to trust, is a key leadership process.

Business is hard: it is a landscape of aggressive competitors, all desperately trying to hold on to every inch of customer territory that they have. That is why most startups fail: a startup must claw some territory away from some established companies and then hold on to it.

That takes vision, leadership, relentless diligence from the founders and from their teams, and luck – without all of those, a startup will not succeed.