Myths and Misconceptions about Design in Scrum

Today, it is difficult to surprise someone with flexible methodologies: 15 years have passed since the adoption of the Agile manifesto, and even earlier the world learned about Scrum. This is commonplace for many software companies and it seems that there is nothing to add here.

But with all the popularity of Scrum in my work and at various seminars and conferences, I sometimes come across a lack of understanding of its basic principles. And more and more often in the comments on Habré I see negative reviews: someone does not manage to agree with customers on the transition to an iterative development, someone can not adapt the team. Probably the most popular review about Scrum, which can be found is: “We spend half an hour on meetings with zero benefit, and then we work as before, only a headache with demo, retro and planning was added.”

We started to implement Scrum since 2011. Our project is not simple: 6 teams (scrum of scrum), more than 40 participants and features for years of work. Naturally, at first, not everything was smooth with us, after the first setbacks we seriously thought of returning to the usual waterfall model, but in the end we were able to adapt the Scrum for ourselves. As a result, we have built a stable and predictable development process, without fakapu and with high quality. All this time I have been and remain the team leader of one of the teams and practically not a single problem that we encountered did not pass by me.

It is possible to talk for a long time about the reasons for the failure of Scrum in individual companies, but today I want to draw your attention to one of the important parts of the development - design. Further reasoning will be based on personal experience, all characters are fictional, and coincidences are random. So, let's begin.
')

Myth 1. I am a programmer, I do not want to design

And then perhaps many have recognized themselves. A simple experiment: ask yourself and colleagues who want to "design." According to my observations, 70-80% will say no. And why?

First you need to figure out what is “design”? I had a couple of years to work on projects "under the order" with a clean waterfall process and a great love of specifications and thick volumes of design solutions. And you know, then I would also say that I do not want to design. Two months alone, generating hundreds of pages of documentation is sad and not at all like all programmers like to write code.

But let's talk about “designing in Scrum”. The design goals are few: reduce development risks, give the product owner, the stakeholder / customer and the team an understanding of what the team will do and as a result increase the value of the product. The result is a realistic “how will” model, taking into account constraints, resources and competencies. In the general case, tons of comprehensive documentation are not needed, it is enough to understand what needs to be done and detailed work decomposition.

You can not design at all, in the end there is a bug driven development. If you pour water into the sieve and quickly plug it in with the bottom of your finger, you get the feeling that water does not flow out. Similarly, the quality of many software products is ensured.

But to think about how you will do the task from the backlog is also a design. Sprint planning is also a design. And in the team iterative work there are excellent methods of how to achieve the desired and not torment the developers with “design”:

• If you work in unfamiliar and complex subject areas - take the analyst in a team, make friends with it - it does not bite. He can work out descriptions of the roles of users and cases of their work (but not the requirements, please, not the requirements), review the competitors, study the legislation and the subject area as a whole.
  And while he is in the team throughout the sprint, which means he can help the team and advice in the development. And it will take the headache off developers, because the work of an analyst is something that programmers themselves do not like to do when designing.
  
  
• Do not write extra documentation - write code. Over the past couple of years I have developed a clear rule: for any more or less complex project you need to make a prototype. It seems that it will not give anything, but in fact, when it is implemented, various little things constantly pop up that we would not have noticed without a prototype. To show the customer working prototypes instead of pieces of paper is a plus to the trust of your evaluation of the project and to you personally. And most importantly: the whole team can develop prototypes!
  
  
• Design quickly. Tightening projects badly affects the achievement of the goals of the sprint and the morale of the developers. It is better to “lean” the whole team, complete the design and go to the implementation.

In general, “I am a programmer, not a designer,” this is not an excuse, Scrum is first and foremost a team, and in the team there will be something for everyone to do when designing.

Myth 2. "Sage in a glass tower"

This expression was not invented by me, but it seems to me that it accurately reflects another myth about design - you can find a super designer who will take on all the design decisions, make on time and with the right quality and everything will be in chocolate. He has all the competencies, knowledge and all the responsibility on it.

For example, in this context, the guys from the designers' guild use the term “analyst-designer”. I personally worked with a man who had previously performed such a role and, probably, in other circumstances, he himself would have become such a "sage in a glass tower." In general, this is a fairly common approach.

Why is this not working?

It actually works, but there are a few drawbacks:

• Obvious things like lack of interchangeability and dependence on the mood, health and loyalty of one person do not need to be painted, this is understandable.
  
  
• “Sage” is very easy to go to communicate with the team in an exclusively team style. He descends the requirements "from the tower", and the rest implement them. Here it is necessary to explain why I do not like the "requirements". A user story tells us what users need and why, and the requirements only tell us what seemed to be an important "sage." In addition, you will have to spend a lot of time to bring the ideas of the "sage" to the team, so that all participants understand what they want from them.
  
  
• Due to the fact that the "sage" designs one he does it for a very long time. Even not so: ooo-o-very long. During one sprint it turns out to be impossible to finish the feature entirely, as a result there appear “design sprints”, then “implementation sprints” and “support sprints”. Not very similar to Scrum, right?
  
  
• Separately, I highlight the fact that such design does not develop a team at all. Meanwhile, it is the team, its work and development that are important in Scrum.

As a result: the super designer is a working solution, but it is even better that the team designs together with it, it will be faster and better.

Myth 3. Refused paper and feel great.

The issue of documentation in flexible methodologies is often painful. Thick volumes of documentation still nobody reads, and they become obsolete after writing the first line of code. And programmers, seeing this, do not want to write paper "to throw." Perhaps, in general we will refuse documentation?

It would be great, but it would not work out at all.
In the wake of minimizing “exhaustive documentation” ( Agile manifest , paragraph 2), it is easy to decide that we no longer write project documentation. We decide questions orally, the team is still aware of what we are doing, we will explain it to the customer on our fingers.

Live it, unfortunately, looks as if humanity for thousands of years invented and developed writing as a way of fixing knowledge, and in 2016 software developers returned to oral legends. When you discussed something with the customer, did not write down, forgot, and then he asks what you came up with on his question - this is a reason to change two things: the topic of conversation and your approach to documentation.

From personal practice there are several recommendations:

• writing paper for programmers is really hard and boring - find a documenting method that you personally like. Draw mokapy - excellent. Love mayndmapy - approx. Draw on the board - great, let it be your design solution format. The main thing is to agree with everyone that you now have this format. As for the rest, Scrum is not prohibited and turns out to be 95% more interesting than writing large texts.
  
  
• decide who besides the team will be interested in your design decisions. These can be: sales managers, marketers, consultants, working with customers. It is often easier to spend time and write than to retell the same thing over and over again.
  
  
• Keep a list of questions you were asked in the discussions, a demo or just in the hallway. Optionality has nothing to do with flexibility and looks like disrespect for colleagues.

Bottom line: document design decisions deliberately, not spontaneously, and adjust the format for yourself.

Myth 4. Oh well, then on the demo will show

Working in a team it is easy to forget that there are customers, users, because there are enough communications and a feeling of general consensus. On the demo, of course, you need to show a working increment of the product, but during the sprint the team looks self-sufficient.
But here I will ask a simple question: have you ever had such a thing, that after the demo, you all remade it?

If so, then it is quite possible that you do not have enough communications during the sprint. This is also relevant for development, and for designing, regular communication with the product owner or customer is completely necessary.

The customer / stakeholder may have his own vision of the product, the owner of the product is different, you have a third. Ideally, you need to meet in person every day and discuss the results of the design and questions for study. If you show prototypes on these discussions, there will almost certainly be no surprises for you on the demo.

Myth 5. From the world of thread and in production

Let's be honest: almost everything that we do has someone invented before us, most likely, realized and maybe even did it well. The Russian IT market initially develops by copying Western products and ideas. It turns out that in designing there is nothing unique, you can take a selection of competitor solutions, select the best and do it?

Yes and no.

Analysis of ready-made solutions is almost an indispensable part for design, but in order for the product to be as valuable as possible, you need to understand what we are doing, for whom and how. Design should be meaningful and controlled. In this regard, there are lots of ready-made techniques:

• design from characters / roles. Characters / roles are your future users and your task is to reduce their headaches and make their lives just a little bit simpler.
  
  
• use user stories. The value attached to a product is not a set of features, but its ability to cover real situations. I recommend reading User Stories Applied For Agile Software Development. M. Cohn.
  
  
• design the architecture based on user cases. In the end, the product is used by real people and its development will most likely come from their cases. Properly constructed subject model will allow to complement it over time, and not to rewrite it from scratch. And a developer operating with concepts of a real subject domain has a head start on those who operate exclusively with builders, visitors and helpers. Let me explain: patterns are useful for designing abstractions, but they cannot hide the absence of a thoughtful object model. I recommend to read Eric Evans' Domain-Based Design (DDD).
  

As a result: no need to be lazy and be limited to ready-made solutions in the design. Spend time exploring your users and their needs and your product will be beneficial to stand out from the competition.

Briefly about how we work

This is not the best practices, but specifically we have had a positive effect:

• our release cycle consists of 6 sprints of development and in order to competently plan a release we conduct essentially a short “zero” sprint: preliminary research and design. As a result, everyone clearly knows what we will do in the course of the sprints and if we are lagging behind the plan, we always understand what will be the minimum value product (MVP), and what can be thrown out.
  
  
• iteration duration - 12 working days. Ideally, if you research, design and do everything in one sprint, then you will have a fast feedback (testing, acceptance testing, corridor testing, demo) and in the next sprint you need to put a small reserve for refinement. At the same time, we tried longer iterations, when all this was part of one sprint, but in fact, the more often you do a “check” from the PDCA , the less likely you are to do the wrong thing.
  
  
• we use pair design. This means that at least two people from the team participate in the research, generating variants, and prototyping. It is faster and easier than designing alone. Also, they are usually connected to a business analyst and often the rest of the team in terms of prototyping.

Instead of conclusion

Designing in Scrum is not a silver bullet, but only a way of organizing teamwork in an unfamiliar area. It does not give you a guarantee from fakap, and building a working process will cost you time and nerves.

Is it worth it to do at all? Everyone will answer this question myself, I just want to warn you against the mistakes that I made myself. This list is limited to my practice, if you come across other myths - I will be glad if you supplement it in the comments.