Can’t help but fall in love with Scrum


Russian Rugby Team during a Scrum (photo by Olga Guryanova)

Can’t help but fall in love with Scrum

Crossover’s engineering team ideates, designs, and develops software. Product owners, UX designers, chief architects, and a fair number of software engineers ensure that WorkSmart is up and running and gets better quarter by quarter.

Software development involves applying different frameworks and methodologies to manage and drive teams to a successful product delivery. Not too long ago, we were still using a Kanban system as our one-and-only project management tool.

The idea behind Kanban is simple: Imagine a board with vertical columns indicating work progress — To Do, In Progress, and Done. Then, imagine hundreds of sticky notes in those three columns. That’s where engineering product features, improvements, and bugs are recorded in detail. Inasmuch as these kinds of visuals help us keep track of projects, Kanban always seemed like an oversimplification when you need to tell your stakeholders about a particular feature that needs to be delivered on a particular date. You need to be able to pinpoint the date of your release — which we didn’t do very well, I have to admit.

Kanban is a great tool to track a team’s ad-hoc work requiring the accomplishment of “the first thing possible,” like a team’s daily operational tasks. The board adds a sense collaboration and transparency. However, if plans need to be made ahead of time, and priorities and deadlines need to be identified, Kanban just isn’t enough.

At the end of this year’s first quarter, we realized that the processes of either developing something new or fixing existing bugs are very unpredictable and chaotic. On top of that, the cost of our engineering team was steadily increasing. Ironically, it could not deliver quality features on time.

Most software engineering teams use Scrum as an effective project management framework. Scrum is the exact opposite of an approach called Waterfall, where software teams plan the whole project many months or even years ahead of the actual execution. Under the Waterfall framework, when changes suddenly occur, the beautiful and very detailed Gantt chart turns into a worthless piece of eye-candy. This results in delays and leaves most customers unhappy.

Scrum, on the other hand, relies heavily on W. Edwards Deming’s Plan-Do-Check-Act cycle. It is based on the question: “Why plan everything ahead if one small change in the environment can tear your plans apart?” It emphasizes incremental delivery of customer value, whether that be a product or a service. Do not try to build a car. Instead, build a rollerboard and improve that rollerboard based on the customer’s feedback, because you can’t be definitively certain that the customer wants a car in the first place.

The Scrum methodology underscores the fact that work is delivered by teams rather than individuals. For this reason, the Scrum Guide emphasizes daily communication and retrospectives to continuously improve on failures and anticipate emerging problems.

There was surely an attempt to utilize Scrum at Crossover years ago, even before I joined the engineering team. Legend has it the attempt failed miserably. But when Agile fails (and Scrum is an Agile framework, by the way), in most cases it is because the team lacks the discipline to keep all the rituals (dailies, retrospectives, and other chores) dynamically going.

To make sure they successfully form healthy and productive teams, companies hire Scrum Masters or Agile coaches. A Scrum Master is probably best described as a combination of a productivity consultant and a psychologist. They work to ensure that there are no systemic issues or barriers that impede the team’s productivity. Typical examples of systemic issues would be a lack of honesty or a breakdown in communication among members of the team.

In Scrum, the bi-weekly development cycle opens with a planning session, where we decide which user stories (pieces of features) will enter the sprint (production cycle). We also decide which ones will be released within the next two weeks. Everyone takes a hands-on role with the tasks to make sure that the whole team understands their complexities.

Later, throughout that same two-week timeframe, the team (product owners and a Scrum Master included) meets daily to discuss successes, failures, and ideas for improvement.

At the end of a sprint, we demonstrate the results to the stakeholders and review the team’s performance with a very useful burndown chart that generates retrospective ideas and experiments to run during the next sprints. This drives continuous improvement and empowers software development teams to ensure that they can effectively deliver the clients’ requirements.

We have reintroduced the Scrum methodology at Crossover and just completed our first sprint. I must admit that everyone is extremely excited with the results. We did not excel in delivery itself, but we uncovered nearly 50 systemic blockers that need to be addressed.

Although slow and time-consuming, I am positive that these changes will help us deliver quality software faster through improved team communication and increased predictability in the entire process. I also encourage everyone to read more about Scrum. This framework will very likely be the best method for getting things done in the years to come in many fields, not necessarily just the software industry.

Source: Medium:Remote Working
Can’t help but fall in love with Scrum

Leave Your Comment