Scrum: wherefrom and wherefore?

Well, fish like the bottom deeper and businesses - cheaper, if to paraphrase the saying. And in the hi-tech world, one of the ways to make development more predictable, and, therefore, stop wasting money on extra hours for teams and compensation for customers, was the implementation of lean methodologies or Agile.

The approach has caught on, and now, on average, every second job opening for a Product or Project Manager features Agile knowledge and experience as a must-be requirement. Developers will also hear a question about their Agile background during the phone or face-to-face interview, though it may not be stated in the description and is just nice-to-have skills.

If you are applying for your first job or prior had only Waterfall experience, it can be useful for you to dive deeper into its philosophy and get familiar with Agile manifesto. Fortunately, it’s a real page-turner.

Agile Methodologies

Why development is lean? Because the concept of “End-to-end scope and specific result in N years” is at loggerheads with some business models. Sometimes it’s feasible to quickly launch something small, check whether there is money over there, and only after that proceed. The vision can change every month, therefore it is logical to wave-off requirement documents and replace them with Agile, which literally means “flexible”.

Below we will consider the details, but for the first encounter, to compare three main methods of development that have taken root in the local hi-tech industry let’s frame a table.

Kanban and Kanban boards

Despite a number of task trackers with the interactive motion of objects, Kanban is usually associated with a board and columns. Though, in general, it is a remedy for a specialist interacting with dozens of wishlists.

This methodology clearly limits the number of in-progress tasks, usually, up to 3 (you can agree on another number). It means that no matter how hard they push you from the outside, the team will handle only three workflow items at a time, and the fourth will added to the flow only in case one of the first three is done.

By “done” we mean the Definition of Done (DoD), that is, the “final” according to the team’s criteria. For example, on production or integrated for the customer use.

It’s ok to work on the project using even a corkboard or a tracker. The second option is not so cute, but more convenient as offers anytime access to tasks description.

Theoretical considerations and Kanban application are well-portrayed in the book “Kanban. An alternative way to Agile” by David Anderson.

And Scrum is…

Jeff Sutherland is considered to be the father of the methodology. And in its original formulation Scrum is defined as a system of maximum adaptation to external and internal factors.

Scrum according to J.Sutherland is a framework that is optimal for the teams of seven people (plus or minus two). Therefore, it might be difficult for a sole developer to adapt to a new model at a new job: not only do they need to get used to working with colleagues, but so much of the time will also be devoted to organizational issues. On the plus side, there is a scrum master to help overcome the difficulties.

The main concern of the scrum master is to lead the team to continuous improvement and search the answer to the question “How can we do even better what we are already doing well?”.

Another role in the Scrum team is the product owner (PO). He/she is responsible for coordinating the project (what we do), maintaining documentation (how we do) and prioritizing tasks (when we do). This eliminates the need for the developer to be a target for customers and get distracted by numerous discussions and editing technical specifications. In addition, the best practices require a detailed study of the task and preparation of the design before the dev team begins to plan. This significantly reduces debates and delays in the execution process.

If you have some time and enjoy reading success stories, spend a couple of days reading Sutherland’s “Scrum” or his book in co-authorship with Ken Schwaber.

Scrumban and other hybrid approaches

Teams that managed to try on both Scrum and Kanban, but felt that both methodologies fit too tightly, sooner or later come to something in-between. For example, some drop a burn-down table (the speed with which the team tackles tasks) or a deep-laid backlog.

Rather often the easiness of Kanban is combined with regular sync meetings and (slightly less frequently) with sprints to be able to plan the project delivery and/or the announcement of new functionality.

But if worst comes to worst, It will mean that chaos prevails in development, just named by a foreign trendy term.

How to implement Agile in development

This subsection can be also titled: “What awaits you if the processes begin to set up after you get a job?”.

Usually, of all the artefacts, daily meetings/ stand-ups/daily syncs stick the quickest. Sometimes they are introduced gradually, starting from 1-2 times a week, and then they become regular as the team gets used to and/or grows.

This subsection can be also titled: “What awaits you if the processes begin to set up after you get a job?”.

Agile coach

With an Agile coach, everything is more or less clear: a person comes from outside and trains the team. Then, within several weeks helps to “implant” a new framework.

Pros: team members are still talking to each other

Cons: you need to spend time looking for a specialist in methodology, rather than in selling air. It may turn out to be more expensive than implementing it yourself (but this is an assumption).

DIY

The project manager may appear in a situation where the implementation of the methodology is fully entrusted to them. Preliminary certification usually comes in handy in this case. If not, then search requests like “scrum habrahabr” and reading about the experience of others comes to the rescue.

Pros: it is cheaper than hiring a third-party consultant; the manager implements the processes in-between the main tasks; the manager is familiar with the team.

Cons: tense atmosphere (“well, just yesterday was one of the lads”), rejection (“let’s get back to the same old”), disappointment (someone else’s experience is not always positive).

Nuances: the manager is also a human and has to internalise practical knowledge. Therefore, the implementation will be done in a familiar manner.

Hand down

This way of implementation usually falls out with the key Agile value which says, “People and interactions are above processes and tools.”

Pros: usually there are no delays in the process because there’s still work to do.

Cons: all aspects are regulated by the approach “it was decided so”, which is pretty much demotivating for the team; best practices fall apart as soon as the managers leave.

Whichever method your company chooses and whatever tools you use, the main task of lean methodologies is to make the customer happier and the team - less frazzled with reworks. This is why experience with Scrum is valued: it means that the future employee has established the planning and coordination of their activities with colleagues. In an era of distributed cultural teams, mentalities and languages can be different. Thanks to methodologies, this expansion is much less interfering with routine tasks.