Scrum and Agile: when you should adopt them

There are always two kinds of clients in software development: some buy a product and some pay for a solution. Although this statement sounds sophistry, it conveys a subtle difference between the ways people conceive a development process.

The first group treats development as a common purchase:

“I need a website to promote my brand, how much is it going to cost me?”

The second one considers a project as an evolving organism:

“I need a team to cooperate with in order to turn my ideas into the reality.”

The first prefer signing contracts and plan definitive budgets while the second opt for collaboration.

Why are development process estimations usually off by a factor of 2-3?

This question was on Quora addressed - you may have noticed - in a merely desperate manner. Apparently, it traces back to a miserable development experience encountered by a stakeholder from the first group. The answer by Michael Wolfe turned out to be the classic one. He simply correlated a software development course with hiking on the coast from San Francisco to Los Angeles. Though you can draw a line along the coast on a map, measure it, and divide the distance by walking speed to come up with an approximate timeframe for the overall hike, you’ll never make an allowance for all contingencies and impediments that lurk in your way.

How does Agile help with that?

Agile is a philosophy the stipulation of which is to acknowledge a project to be an evolving organism. In Agile, you can outline the main project points in advance yet you can’t embrace all activities throughout a development life cycle.

And yet this tenet doesn’t exhaust all ideas behind Agile software development. They are described in “Manifesto for Agile Software Development”. In a nutshell, the Agile software development implies handling a project in short iterations, and by the end of each iteration, a development team presents a working chunk of software to gain feedback. Agile welcomes changes in the midst of a project life cycle, which helps to be flexible and align a product both with evolving ideas and the mercurial market. It requires the engagement of strong team individuals and ongoing collaboration with clients.

Well, does Agile resolve the problem with unreliable estimations? Frankly, no. The belief that you can compose an exhaustive documentation in advance, consecutively follow it, and retain agile is a common misconception. Your initial documentation should be “Just barely good enough” to maintain a fragile balance between plans and the reality.

And what is Scrum then?

With that being said, the Agile manifesto is a set of principles and values, rather than a methodology. However, there are several methods that actually offer frameworks to handle Agile. Scrum is one of them. The most popular of those methods are:

• Scrum;
• Lean software development;
• Kanban;
• Extreme programming.

With Agile as a hallmark, they may have significant differences among each other.

How does Scrum work?

Let’s start with roles in Scrum. There are three of them.

A product owner. You guessed it. A person who has the general vision of a product. And besides that, this person composes a product backlog which is a set of major (high-level) project requirements (Product Backlog Items). Eventually, a product owner takes responsibility for the product success.

A scrum master. A team facilitator who manages information exchange and helps to build consensus among team members resolving problems that a team encounters. Don’t confuse that with a project manager. While a project manager is accountable for outcomes, a scrum master maintains the Scrum framework and fosters self-organization. Scrum doesn’t have project managers, which implies the equal responsibility for outcomes among team members.

A team. Self-organizing, versatile, and creative. It consists of developers, QA-technicians, and business analysts. Ideally, it’s 4-5 people. Team members allocate their efforts to tasks among each other. Keep in mind that Scrum doesn’t have team leaders.

One of the must-have requirements of Scrum is a strong experience which ensures a cross-functional nature of a team and eventually leads a project to a swift launch as well as the satisfaction of stakeholders.

As Scrum has the iterative workflow, the major time unit of it is a Sprint. Sprints can be from 2 to 4 weeks long, but for a particular project, the length of sprints doesn’t differ. Though the number of sprints may vary with regard to a project scope.

What are the steps within each Sprint?

Planning. A product owner negotiates with a team which of high-level objectives listed in a product backlog have to be achieved in the current sprint. Then a team composes a sprint backlog which conforms with the high-level objectives and decides tasks assigned to team members. Basically, a product backlog is a Scrum artifact which answers the question: “What?”, whereas a sprint backlog is concerned about “How?” To embrace all these tasks, a sprint planning meeting is organized.

Development. A team starts completing items listed in a sprint backlog. Every development day starts with a daily Scrum meeting during which team members report to each other the tasks they’ve completed the previous day, and impediments faced. It helps to assess the progress and align efforts with tasks efficiently assigning them to team members for the next development day.

Release. A sprint must end with a release of a product in a ready-to-ship condition (ideally). Although this is hard to achieve, the idea behind Scrum is to provide incremental releases, adding new features every release as the Scrum development goes. Regardless of whether all tasks committed for a sprint were completed or not, the sprint must end on time.

Sprint review. As a product is in a potentially shippable shape, it’s presented to stakeholders in order to work out possible changes for the next sprints. Also, during a sprint review meeting completed and incompleted tasks are discussed.

Retrospective. And there is another step which is a sprint retrospective meeting. During this meeting, a team discusses the sprint and decides what improvements to the work process have to be made to avoid flaws in the coming sprint.

These are basics of Scrum. As you may have noticed, Scrum measures up to exploring and learning of a product as development continues. And it just tries to be logical about the software building. It encourages flexibility and discourages the belief that you can plan everything beforehand.

Well, can you adopt the Agile software development with the Scrum framework for your project? Definitely, you can. Yet, this bare set of practices has to be implemented with respect to a company culture and a project specifics. That would be overconfident to state that Scrum is a one-size-fits-all solution.

And, by the way, some developers argue that the Agile development is simply nonsense.

OK, what are the major flaws I should be aware of?

Some developers consider Agile nonsense, some insist on numerous arguments that reveal pitfalls of Agile development, some are truly devoted to it, and some use this buzzword as a leverage to sell their services.

Agile welcomes changing requirements, while developers usually don’t. As Agile being a some form of a mindset and developers have to abide by its values, it seems ridiculously naive to believe that everyone claiming to be agile really likes changing requirements. Most programmers hate it.

Scrum challenges developers to maintain a rhythm. One day you’re more productive than another. The same scope of work and number of tasks may be covered by a programmer differently regarding his/her pace for a particular day. And things are fine for traditional workflows. Once you practice Scrum, you’re accountable to a team that may put much pressure on you as your flow state changes. Pressure from your teammates is a great tool to ruin inspiration and morale.

Scrum disregards senior engineers. As you adopt Scrum no matter whether you’re a junior or a senior developer, it forces you to be simply a member of a scrum team. Senior developers might opt for more challenging and complex tasks and avoid repetitive assignments. A cross-functional nature of Scrum pushes engineers to work on tasks of various complexities regardless of their expertise. And it hurts.

Incremental releases mean bugs and raw products. The idea to deliver a product in a shippable form by the end of a sprint seems quite idealistic. However, it works. Sometimes and somehow. Those stakeholders who reckon on receiving a polished and flawless product meet the crude reality. A product that underwent a short development cycle is likely to have bugs and incomplete features that are up for completion in the next sprint. And it’s also challenging to bring a big update within a two week period. Although it’s not unmanageable, but you shouldn’t expect to receive a decent MVP with no bugs in a fortnight.

Being agile, be agile. And that’s the hardest part. The Agile manifesto consists of 4 values, 12 principles, and a mission statement. If you adopt them as a unity, your Agile process might work well within a chosen framework or a custom method you align with to be agile. But once you fail to follow at least one of those, you’re not agile anymore. Attentive reading, immersing into the manifesto, and a critical analysis may unravel the fact that most of the teams claiming to have the Agile software development are wrong.

And this list of flaws doesn’t even pretend to be comprehensive. The spectrum of opinions and complaints is enormous.

Should I really use them and when?

The Agile software development isn’t a silver bullet. Blindly adopting its practices regardless of a company culture and specifics of a product is a reliable way to gain failure. If you have a small or medium size project, an elaborate and exhaustive documentation, your product doesn’t seem to evolve as it being developed, stick with a good old-fashioned waterfall. Practicing waterfall you can make a reserve for risks and eventually succeed.

If you’re ready to collaborate, spend much time on feedback, ongoing improvements, you have an idea and requirements are just barely good enough Agile might be an option to consider.