Seven Pitfalls with Agile or Scrum Methods

Seven Pitfalls with Agile or Scrum Methods

2017 01 01 head

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?

2017 01 01 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

2017 01 01 Essence 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. Show your different solutions to the problem.

In other words we want Bang for the Buck

You shall fill all time-boxed meetings

2017 01 01 Meeting The agile manifesto states

Individuals and interactions over processes and tools

Customer collaboration over contract negotiation.

Agile Manifesto

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.

Compute your ROI.

You shall have a cross functional team

2017 01 01 A 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.

Are you doing peer activities in your company?

As a rule of thumb a good T-shape person Is master in one technical area, Has a delegate, a challenger and an apprentice, Care about the domain of his users.

You shall allow changes anytime

2017 01 01 Change Ahead 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?

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.

2017 01 01 Indian Village 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.

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

2017 01 01 Meeting 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 product.

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

2017 01 01 Rope 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.

You shall worship Scrum as the PROCESS

2017 01 01 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.

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 product cannot be stated in one standard rule set. We are talking about agile quality assurance, lean approaches and best practices.

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.