Over a million developers have joined DZone.

Single Point of Failure - Don't Expect the Best Solution from One Person

DZone's Guide to

Single Point of Failure - Don't Expect the Best Solution from One Person

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

Why it is bad to have a single point of failure in a product and what to do about it.

Every day we solve problems. Some people solve many problems, some few. Most likely in your project there is a person, who solves most of the problems. Sometimes it’s a Business Analyst, sometimes it’s a Designer, most often it’s a Product Owner. He knows the market, the domain, the customers, the competitors, the features. He knows how things should work and pushes his solutions hard. Usually the team can’t resist and just accepts this situation. Is it good? Can we find better ways? Well, we’ll have to have quite a lengthy journey to find out.

Setting the Stage

Imagine, you have a new feature in the backlog. At this point we have several potential scenarios with a different level of harm:

  1. Leave everything up to the developer.
  2. Discuss this user story just before the implementation, come up with a solution and do no specs. Make all the decisions on the fly.
  3. Discuss this user story just before the implementation, come up with a solution and do the specs.
  4. Assign user story to a Product Owner, let him come up with a solution and have him do the specs.
  5. Have UX phase, brainstorm a solution and create the specs just on time, before the development starts.

You can see that some of the scenarios are good, some are bad, and a few of them are just horrible.

To create a perfect solution, we should answer the three simple questions: When? Who? How? Well, the most important question is Why? We’ll assume it’s already been answered.


Each story has its own life-cycle. It is born, it lives and then dies. There are three important moments in the life of a feature:

  1. Someone has a good idea, and a feature is created in the  backlog.
  2. Development starts.
  3. User story is released to production.

When is it a good time to have the complete solution? Obviously, not right after the story is created, as things change, and it may happen that this user story is no longer required. It may just be deleted from the backlog in the future. Somewhere in the middle when we have more data? Maybe, but still not perfect. The perfect match is when we have the solution right before the development is about to start.

Feature Life Cycle

In this case the solution is fresh and shiny. Everyone in charge does remember why things should work exactly the way described in the specs. It is certain that the user story will actually be implemented, so the solution and the time spent on it will not be thrown away.

If a feature looks very simple, the UX phase can start about one week before the implementation. If a feature is complex, several months may be a good timeframe.


Many teams rely on the Product Owner, Business Analyst, etc. and expect solutions and specs from them. A team doesn’t care about the solution, but does care about completeness of the specification. Sometimes this works, in most cases — not.

Some teams rely on communication and do not create specs at all. They brainstorm a solution on the fly and then jump to coding. Sometimes this works, in most cases… well, you got it.

Some clever teams rely on the group of people that consists of developers, testers, designers and product owners who brainstorm the solution, find the best one, iterate and delegate writing specs to the product owner. And these teams rock.

Why the first two cases are bad?

The Hero

Yes, Product Owner is responsible for the product. Yes, he knows a lot. Yes, he can solve problems. And, yes, you expect too much of him. It is quite unusual to expect the best solution from a single person. It is always better to have a small group of people with various skills, various background, various focuses to find a great solution.

Product Owner can brainstorm everything alone and write all the specifications. He can haul the product alone. As a result, he would be a single point of failure… while there are many other buses in the streets.

Run, Lola Run!

The communication would be one-way, without much collaboration, and in such environment Product Owner would tend to ignore the opinions of other team members, since they do not participate in problem solving. If you don’t participate, why the freaking hell should I care about your opinion?

Knowledge sharing would be zero. Product Owner is a domain expert, he knows a lot. But the team gets zilch from his experience. There are no discussions, no collaboration, no two-way communication flows.

I used to be such a person. It was not good for the company.

Product Owner’s Rule #1: Don’t do everything alone

The Rush

Got a real problem? Get together, brainstorm it quickly, get shit done and kick it out of the door. Sounds good? Hell, no. The good thing is that you don’t waste time and rush straight ahead. The bad thing is that the solution would be great rarely, good sometimes, and in most cases just average.

In the rush mode you tend to cut corners, take the first acceptable solution and go for it. There are situations when it is good. In any emergency case this is a viable strategy, but in the long run it will not work. Rush mode is very dangerous. You may be even proud of it and call it “agile”, but it is not.

— OK, the quick add feature. Who’s got any ideas?
— Well, let’s just put up the Add Task link . You click it and see the input field with the Name label and Save button. You add one task and see the input field again, so you can add many tasks quickly.
— Great! Let’s do that right away.

Maybe this is somewhat stretched, but in reality I saw very similar situations (and did very similar things myself!).

Product Owner’s Rule #2: No rush

The Team

I bet you expect a viable solution now. Here is the algorithm:

  1. Brainstorm every feature in a small group of 4-7 people. Invite developers, invite testers, invite designers, invite product specialists. Invite everyone who has diverse skills and can contribute to a discussion.
  2. Think. Talk. Draw sketches. Learn some techniques like Design Studio. Do use them. Draw sketches.
  3. Build trust. Support honesty. Ban sarcasm. People should trust one another, or you will have a bunch of gamblers instead of a team. Don’t be afraid to criticize bad ideas. The people who can’t stand some reasonable criticism should leave.
  4. Repeat. Several times for each feature. Mix people. Invite new people.
  5. Eventually, several teams will emerge, the teams that can solve problems without you.
  6. Find people that can lead features and be responsible for the solutions. Let them lead UX sessions and play the Feature Owner role.
  7. Create beautiful specifications (this is where I really suck).

It took me 7 years to come up with this solution. It works.

UX Phase

Product Owner’s Rule #3: Spread the knowledge, use diversity, delegate


The “how” question is very broad. How to form teams? How to find solutions? How to evaluate them? How to document solutions? I’m going to just scratch the surface here.

Creative processes are hard to structure and hard to estimate. In general you don’t know when you’ll have a great solution. It may take several days or several years.

Each Feature Team has its own UX phase. Some people like to think alone, have decent preparations and then share ideas. Some people like to brainstorm things ad-hoc. Some like to sketch a lot. Some like to create paper prototypes. In general, it does not matter which practices and tools people use. The must have rules are:

  1. Diversity. Team should consist of diverse people.
  2. Iterations. First solution is not always the best. Neither second, nor third.
  3. Feedback. Team should share potential solutions with other people and with customers if possible (and listen to their feedback).

UX Phase Rules

There are many practices and tools you can try. I’ll just list some of them here:

  • DesignStudio. In a nutshell, you have a group of people. These people can split into teams or work alone. They have limited time to sketch the solution and then present the solution to everyone. Solutions are criticized. Then you iterate based on the feedback and sketch again. We’ve been using this approach with good results. Yes, it is time consuming. However, time is not important when you want to spread the knowledge. So use Design Studio in the early stages of people involvement into the solution phase.

  • Sketches. The ultimate tool to brainstorm, explain, evaluate and present ideas. The main advice I can give is: hide your “OMG I can’t draw!” fear and sketch a lot. You will get better eventually. Sketch + speech is so powerful, so fast, so cool. You can iterate really quickly, try a dozen approaches and skip bad solutions.

  • Critique. Do it. Express your opinion openly and politely. Don’t hesitate to upset someone. You solve problems here. Bad solutions should be thrown away. If you’re afraid to say something critical about your boss’ solution — it’s a bad sign. Fuck the common brainstorming rule about ideas and critique separation. This is only needed if you don’t trust each other. Trust gives you freedom of speech. Use it appropriately.

  • Diversity. It really works. There are many proofs and observations on how diverse teams outperform experts and solid “think-alike” teams. Try it.

  • Paper prototypes. Not as fast as sketches, but still good. With paper prototypes you can evaluate flows and find bottlenecks. It’s easy to grab them and ask some teammates to try something. You can even shoot a video and share it with people.

  • Dynamic Prototypes. HTML+Javascript works best for such prototypes in most cases IMHO. However, there are many other tools that do provide decent solutions. We’ve had a somewhat mixed experience with live prototypes. In some cases they did work, and we got valuable feedback; in most cases we spent too much time on them and feedback was not so useful. Prototypes work great to prove some limited ideas about a solution, but they don’t work as full-blown usability tests.

  • Usability Tests. We do them on a real application now. About 10 tests give a ton of feedback.

Product Owner’s Rule #4: Learn and try new things

The output of the UX phase is quite simple: feature specification. How to create beautiful specifications? We’ll talk about that in the next article with an intriguing title “Visual Specifications”.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}