Seven Pitfalls with Agile or Scrum Methods

The post describes a presentation I gave at a company internal technical day.  It reflects situations we have seen in a lot of agile projects over the last years.
I assume that the Scrum approach is well introduced in your company. You are already proficient with Scrum, eXtreme Programming, Clean Code, Code Refactoring, how to write stories and story maps, and techniques such as TDD, ATDD.
You are using Scrum well and can laugh about all these posts about Scrum-But(t). Still misunderstandings about Scrum abound.
We will present common pitfalls seen in teams already applying Scrum; meaning teams using Scrum as an empirical process, holding the meetings as described in the Scrum guide, and producing all expected artefacts. We want to increase your awareness and reflect how you can become better Scrum experts. We exhort you to eliminate these misunderstandings in your projects.

What is Scrum?

The Scrum approach is clear, well documented and shall be done by the book. The Scrum framework is straight forward. The possibilities inside are unlimited. It is like chess, the game has a simple set of rules, the variants how to play a game are limitless.

This article is not about "Scrum But" impediments describing common errors how meetings are held, artefacts created or roles lived. We are talking about misunderstandings once you have reached this first level of mastership.

Before talking about misunderstandings we should remember the most important facet of Scrum. Scrum is all about ROI. Scrum was defined because the founders were convinced you can develop more effectively better products with higher value.

The essence of Scrum is ROI

All decisions in Scrum should be based on Return of Investment ROI. Each time you doubt how you should do an activity, ask your team what is the ROI of your proposition?
Stakeholders want ROI. Each time you request budget from your stakeholders you should always remember "you want stakeholders' money, convince them".
1) Show your different solutions to the problem. As a stakeholder I want to see at least three approaches,
2) Show your ROI estimation for each approach,
3) Present you preferred solution and explain why it is the best solution.
In other words we want "Bang for the Buck"

→ You shall fill all time-boxed meetings

The agile manifesto states
- Individuals and interactions over processes and tools,
- Customer collaboration over contract negotiation.

Perhaps too often we interpret these sentences as

- Respect people, have nice interactions and avoid any hard discussions,
- Collaborate with the customer, never disagree and avoid harsh truths.
Swiss people are well educated. They always empty their glasses in the restaurant and have trouble leaving some wine in the glass. They also do not like conflict.

We often forget the Pareto rule, 80% of all solutions are found in 20% of the time. Is it worth the time to find a slightly better solution for the remaining 20% of the problems? In Scrum terminology "it is also the 20% less important"

Tips "ROI: Meeting costs versus solved issues"

Meetings cost money. A meeting with 8 persons and of a duration of 30 minutes costs in Switzerland around 600 Swiss Francs or 500 Euro. The tips are

• Avoid meetings. Prefer a team gathering or a pair session. Instead of calling for a meeting use instant messaging and collaborative tools.
  This advice is very efficient in bigger or older companies. Such companies tend to develop a meeting culture, people do not work anymore, they just sit in meetings,
• For each meeting you should have an agenda, a moderator, a protocol of the meeting, and as a result a list of decisions and a list of tasks - who must do what until when -. Interesting enough all Scrum meetings have a clear agenda, a moderator and a documented result. Do the same for additional meetings,
• Remember two ground rules
• Once you have reached the goals of the meeting, stop the meeting,
• A team decision is about 20% better than an qualified individual decision. Compute your ROI.

→ You shall have a cross functional team

Scrum teams try to be fully cross-functional and invest a lot of effort to reach this goal. They probably do it because it is written in all Scrum tutorials.

Every person should be able to take a task from the Scrum board and implement it.  It is like a soccer team where each team member can play all roles.

 Tips: "ROI: Learning costs versus cost of errors" 

You need T-shaped team members. This concept was described in the mythical man-month book by Fredericks Brook Junior and later by Grady Booch before most of you were born. A T person is a master in one technical area - this is the leg of the T - and knows about a lot of domains - this is the roof of the T -. In fact Square-shaped team members would be better but are very hard to find.

To increase ROI the specialist of the team should perform the tasks it is best suited for. But a good team also do risk management to insure that another person can do the job if the main specialist is not available. See risk management theory how the cost of a risk is evaluated to calculate the ROI of training additional team members. 

The simplest way to distribute knowledge is the four-eyes principles exemplified through pair programming and peer checkin. Are you doing peer activities in your company?

As a rule of thumb a good T-shape person

1. Is master in one technical area,
2. Has a delegate, a challenger and an apprentice,
3. Care about the domain of his users.

→ You shall allow changes anytime

Scrum is about agility. Therefore you have the right to change anything at any time, isn't it? 

Your stakeholders need the changes now. They cannot wait until the end of the Sprint, a mere ten working days or two weeks of elapsed time.

But Scrum also states we have a vision, features, a minimum viable product and a potentially shippable product. How often can you change these key concepts? 

What is the balance between agility and chaos?

Tips: "ROI: New value versus cost of development and associated errors"

First let me state some concepts deeply entrenched in Scrum

• Sprint backlog cannot be changed during a sprint. This is Scrum. Bend it with Kanban - for maintenance activities -,
• Agile approach is about a minimum viable product release as soon as possible. This definition is part of the vision and the initial release planning,
• Release planning is a must in real Scrum projects.

So you have the right to change everything at the end of each sprint but the costs are enormous. Here again we are back to ROI computations. As a rule of thumb to test your decision

Uncle Bob stated in the "Clean Coder" book if you deliver an application with errors the only professional approach is to sign personally a check to the customer for the lost of income.

In other words are you ready to change the user interface two hours before the sprint demonstration will be held?

→ You shall not perform up-front design

Architecture emerge during the coding of the solution. So teams state that

- No architecture is needed before starting coding,
- No enterprise architecture should be defined or look at,
- No non-functional considerations are needed.

Look at the picture. Could you design a village without knowing about the ground, the kind of population, do you need school, do they have flood in the area?

They believe that refactoring will solve all problems. Architects are no more needed, we are all talented hackers.

Tips: "ROI: Architecture work versus write it twice"

You start once you have a vision, an initial plan, and a set of initial decisions. You should not have a complete and detailed plan. Major assumptions should be identified; if they change - see above "You shall allow change any time" - you should reevaluate the architecture.

You should understand the application domain, the technology, known similar examples and calculate the ROI of the variants you propose. Often teams forget about non-functional requirements such as scalability, reliability, multiple sites. These features cannot be added later, you have to write the application twice.

As a rule of thumb

Be honest: our systems are complex but they are no ground breaking work. Similar solutions already exist. I expect a talented team to provide an architecture with some prototyping in less than a sprint.

→ You shall write user stories during coffee breaks

Writing user stories is easy and anyway nobody has time for
- The product owner has better to do. He writes the stories during a coffee break or just before the start of the planning meeting,
- Anyway just read the requirements, it is all written down,
- The developers want to code, they have no time to write some user stories or improve them.

Scrum states the product backlog is the most important document in a Scrum project.

Tips: "ROI: New features with the most value" 

To create a new successful product is a full time job. You cannot define a vision and key features during a coffee break. 

• The product owner must create a vision, an initial release plan, identify the key features and define a minimal shippable product - see above "You shall not perform up-front design" -,
• Either the product owner has a team of requirement engineers to elicit the use cases,
• Or the role of requirement engineering is part of the team,
• The team provide technical feedback and input about potential technologies  for all stories, discuss the non-functional requirements and refine the acceptance criteria,
• As a simple check, the team guaranty together with the product owner that each story is INVEST - Independent, Negotiable, Valuable (ROI), Estimable, Size appropriately, Testable -. If not why?

As a rule of thumb

Writing quality user stories is as tough as writing requirements. It is the same job! 

Be honest: Developers cannot write clean requirements or design a clean user interface 

→ You shall not train engineering practices

You shall not train engineering practices
- The process solves all problems,
- I want to code, I do not have time to become a craftsman,
- Scrum is snake oil. It cures all illnesses and makes you immortal,
For the older ones, do you remember CASE, CMM and ISO-9000. The PROCESS promises that you will deliver high quality software on time, on budget with unqualified and cheap collaborators. Do you really believe in snake oil?
Do you think that a collaborator can win a competition just be respecting a process. He must train every week to achieve and maintain a given level of skills.

Tips: "ROI: Engineering versus bureaucracy"

To build quality solutions you have to have craftsman as team members. A craftsman master his work techniques, is experienced, knows his limits and master his tools.

You must be a craftsman: You are expert in XP, clean code, TDD, ATDD, Mocking, CI, CD, refactoring, etc.

And you must train, train, train. See for example the concept of coding dojo.

→ You shall worship Scrum as the PROCESS

Scrum is a framework. You can use it to manage different things, including complex product development. Scrum is defined in the Scrum Guide and consists of roles, events and meetings, artefacts, and a set of rules binding them together. It is based on empirical process control and bottom-up thinking.
Each sprint to ameliorate some aspects, measure and decide if the change is worth the effort? But Scrum will never give checklists to guarantee success. This job is YOURS.

Scrum is the best approach to fail fast and learn. Therefore you can learn and correct.

Call for Action

Eliminate these misunderstandings in your projects

 Act using ROI 

What is the risk?

The truth is complex, more blurred. The answer for your project cannot be stated in one standard rule set. We are talking about agile quality assurance, lean approaches and best practices.
And a best practice should only be selected through its ROI.

Please look at the Software Craftsmanship Manifesto

• Not only working software, but also well-crafted software,
• Not only responding to change, but also steadily adding value,
• Not only individuals and interactions, but also a community of professionals,
• Not only customer collaboration, but also productive partnerships,
• That is, in pursuit of the items of the left, we have found the items of the right to be indispensable.