Back to Blog

Good Agile to the Bad SCRUM

Date: June 18, 2020 Reading time: 7 min

Author

David Bonet

I don't want to feel proud only of what I accomplished, but of how I accomplished it. The end doesn't justify the means. That and being happy with my family.

90% of web development in companies and startups is done trying to use some sort of SCRUM. Still, in my experience, not so many company are Agile. The problem here is that SCRUM is an Agile framework, and if you aren’t agile your SCRUM is going to be a source of conflicts and frictions. As reference before we start, lets read Wikipedia’s definition of Agile and SCRUM.

Agile software development comprises various approaches to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers/end users.

Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields and is slowly starting to be explored for other complex work, research and advanced technologies.

As you can see, SCRUM is an Agile based framework.

Example of a non Agile SCRUM

Lets imagine a five people team: One product manager and four developers. This team is given the task to build and administration panel in order to improve the operations department efficiency. Up to here, all god. The team starts researching and proposed an administration interface like this one:

proposal

The projet gets approved and the team starts working on it. As they are working using SCRUM the first thing they do is to split the work in tickets. More or less like this:

design zones

From there they estimate the complexity using points, T-Shirt sizes or something similar and they reach a conclusion similar to:

complexity split

Once the complexity estimation is done they assume that each vertical segment is a developer and one Sprint. THerefore, they assign A and B to one person, E to 3 people, C and D to other 2, etc. This process may change from company to company, but it always ends in something similar.

After the first Sprint the conflicts start. The task E is delayed, C and D need to be changed as the operations department think that it can be improved with some “small changes”, etc.

In the third Sprint, the task E, H and I are not progressing and it looks that the team is not able to fulfill their own commitment. Additionally, business and the operation department don’t stop changing and adding requirements. Their suggestions aren’t bad, but they don’t help when the team is already under stress.

Finally, after another 4 springs the team has everything ready and working. At this point business, operations department and the development team developer some communication frictions with each other. Still, the work is done. Of course, there is a version 2 waiting now that operations team is using the tool and found how to improve it.

The problem

Beyond 50% of the development the team is permanently under stress. New frictions appear every day between development team and business and operations department. And doesn’t matter what is the project always, always, takes longer than originally estimated.

This happens because the “SCRUM” that the team is applying is a Waterfall without the Waterfall’s initial planification.

Perspective change

Lets be honest. Brutally honest. ¿Are you ready? Nor you, nor me know the future and less know all the internal nuances of the operations department. And unless you expended last year working in the operations department, your idea of what they are doing is very inaccurate.

Still, business expect you to know all what operations needs, the product manager tries to show that they know (even better than them!) what operations department needs and everyone live in this fantasy where the project is easy and doing it is just about being serious and “Just do it” TM.

Let see what the team really know (more or less) for each ticket they were developing.

real tickets knowledge

For the simple parts you can be more or less confident that the proposed solution is close enough to what is really need. For the complex parts (parts with many non-intuitive divisible sub parts) the story is very different. We can be sire there will be requirements changes.

All the planification and development will need to be redone once the project is released.

Reintroducing Agile

Lets go back to the start, when the team was planning the need for the control panel. Instead of planning for the final version, lets plan for the MVP of that. The real minimal version. That will be, from the previous image, the white part (non-market) columns part.

Once there, don’t plan anything else. Simply release the project. Let the operations department try it and tell you what they need next. We are speaking of something like this:

minimal viable product

Iterate several times. Let the developers understand the problem too. Let them know how their creation is being used. Give the product manager time to learn the real needs from the operations department. And, most important, let the product manager experiment.

Iterating doesn’t only allow you to not throw work away, but it allow the product manager to experiment and discover the needs of the product’s users. This increases the potential product quality due the product manager acquired knowledge during the experimentation in each iteration.

The first iteration would be, more or less, like this:a:

first iteration

Finally being something like this. Each color is a project iteration.

development stages

Of course, during the first iteration you don’t know what the rest of iterations are going to look like. It is something that will be discovered during the process.

If you develop iteratively you won’t only create better quality solutions, but you will reduce lost time, team frictions, stress and team demotivation too.

I hope this helps you to improve your work day and project success and that i helps clarifying ho to work iteratively.

Lean y Data Driven Management

This topic is related with Lean Management and Data Driven Management. We will speak in other posts about them, but for now we can say that they core concepts of all this methodologies and frameworks are Iterations, Experimentation and data based decisions. That and a ton of humbleness.

TL;DR

In short, make sure your SCRUM is really Agile. Iterate soon and don’t assume things that you cannot verify experimentally. With each iteration you will discover new things that will guide you to a quality product.

About Couragium

In Couragium we work using Agile and Lean. Our developments are iterative and our decisions are based in experimental data. In our experience that is the way to bring closer the product to an always changing market at the same time that keeping a high quality standard. If Agile is what you look for, don’t doubt in asking for an appointment.

Myths

  • Myth: But if I iterate the development will take much more time!

    Response: Doesn’t need to. In an ideal world where truly the proposed solutions is really what it needed, yes. In the real world where the proposed solution is what we imagine that is needed, no. Doing the whole project in one iteration will only end in replacing finished and polished parts of your product after release.

  • Myth: Between iterations the developers won’t have anything to do.

    Response: Reality is not so squared. If you are developing 4 features, you can have several unsynchronized releases. When a team finish an iteration they can start with another iteration from other feature or help other teams.

  • Myth: Business/My boss will never accept a non fully defined project.

    Response: If you company expects from you to know everything from everyones work, well, maybe you need to have some real taks with you boss. If there is no way to make them see that you aren’t omnipotent, maybe is worth it to evaluate what is the trust you receive in your workplace and if you want to accept that.

  • Myth: But in my company we wouldn’t be ever able to work like this.

    Response: Maybe, but except in military industry or exceptionally hight level agreements between companies, I don’t thing that is the case. From embedded systems to web pages going through phone and PC applications can be build iteratively.

  • Myth: If the requirements aren’t signed in a contract they will always ask for more features and changes.

    Response: If the user ask for improvements that means that there are still user-product frictions. That is a business opportunity. Don’t take complains and requirements changes literally. If you are an internal employee and what you are told has no priority, then continue with your other tasks and don’t do what they told you. If you are a freelance and use Agile the contract cannot be fully closed in terms of time and remuneration. If the customer doesn’t accept open contract then propose a phase based contract where you work with objectives set in each phase, but not before (for each phase you have a full cycle: consultancy, payment, requirement definition, development, repeat)

alternative products

It will always be surprising the final result if you iterate until discover what are the real user need.