Agile Is More Than Scrum

Most people use the terms Agile and Scrum interchangeably. It’s often not even clear what the difference is. So, last week during our Jakarta Scrum meetup (organized at Happy Fresh), we decided to find out. We did a group study on some different Agile concepts: Kanban, Lean and Lean startup, XP, Scrum, and Agile. The experiment was organized using multiple Scrum teams and Sprints. We had an area product owner, Pepe, and we had five teams. Each team self-selected a Product Owner and selected one Agile framework. Each team had to discuss and research the framework and make a presentation. The big challenge for the area Product Owner was to combine all these presentations into one storyline. This overall presentation had to be done for the management of "PT. Stuck in Waterfall."

Here’s a more detailed description of the setup, the chaos that evolved, and the positive result.

The Setup

We were all working for the enterprise PT. Stuck in Waterfall. Top management had requested a presentation on the application of various Agile concepts for their company. They want to start a big Agile transformation, but they want to be well-informed about which concepts could fit, how they all fit together, and in what priority they should be rolled out. They’ve selected one person as the leader of this research and presentation phase. This person has authority to engage as many people as needed to get the information.

We self-organized teams of four to six people. Each team picks an Agile concept (Lean startup, Kanban, Design Sprint, Scrum, etc.).

Our end product was a presentation on how the Agile concepts can be used to transform the company towards more agility. We had an area Product Owner who was responsible for this end product. Each team had a Product Owner responsible for the teams’ product, which was a presentation about the Agile concept the team chose.

The teams went through four Sprints:

1. Sprint 0 (15 minutes): Setting up. This step is characterized by self-organized team formation and the selection of the Scrum Master, Product Owner, and any additional roles. Discussion between Product Owners and the area Product Owner.
2. Sprint 1 (20 minutes): Product design and plan. This step involves project charting, where each team makes a plan of how they’ll create a presentation on their concept. Teams are free to choose any method of presentation: drawing, powerpoint, roleplay, sketching, dancing, etc.
3. Sprint 2 (25 minutes): Research. The Product Owners have a meeting with the area Product Owner to form the overall product plan (timeboxed to 15 minutes). The teams start research and discussions on their concept, collect case studies, find information about the specific concept (visuals, theory, models, etc.), and exchange experiences with the concept. Retro: 3 minutes.
4. Sprint 3 (20 minutes): Create the presentation. Teams work on their presentation and continue research and collecting materials needed for their presentation. Where required, Product Owners communicate with their area Product Owner. Retro: 3 minutes.

Finally, there's the demo, which should take 5-8 minutes per team depending on the size of the total group and number of teams.

Chaos

The big challenge in this experiment was how to coordinate the different presentations of all teams into one presentation. Pepe was running around sweating in the first 10 minutes. These are the two things that I observed (applied to real projects) in the process:

1. Product Roadmaps Need Coordination

With five teams working on one product, organizations need a coordination mechanism. This can self-evolve or can be planned by management, or we can follow a scaling framework (i.e., LeSS, Safe, or Nexus). In our experiment, teams selected Product Owners. Some Product Owners asked the area Product Owner what he or she had in mind. Some Product Owners just made a plan with their own team without checking the overall plan. After five minutes, Pepe called a meeting of all the Product Owners, and they had a plan within two minutes. After that, everyone was clear and we managed to make an integrated story.

2. Teams Don’t Take on Extra Responsibilities Automatically

Some teams finished their presentations before the end of Sprint 2. They then lingered and kept discussing a bit. I suggested to some that they help out some other teams, as we were working towards one goal. I see this phenomenon also in the Lego simulations I do during Scrum training. If one team finishes its commitment, they’ll consider their work done. They forget to realize that they could take on more user stories or they could help out another team. They forget that they’re all working towards the same city of Legos or the same presentation. People need a little encouragement to do this.

The Outcome

I played the CEO of PT. Stuck in Waterfall and listened to the presentation. The goal was to show the management team how the different Agile frameworks could be integrated into the company to replace the Waterfall model. The logic I took from that story is:

Agile

Agile is about the mindset we create within our company. It’s a set of principles that we can use to drive the company towards frequent delivery, focusing on value, self-organization, etc. It's a different way of organizing work. To help people change the way they work, we have different frameworks and methods, which are described below.

Scrum

Scrum is the most popular framework. It helps teams organize using a fixed set of roles, events, and artifacts. It is not a step-by-step "do this and then you’ll succeed" process but a framework that has the minimum guidelines to help people organize work. It’s most often used in software application development, but also spreads outside (i.e., marketing, HR, maintenance).

Kanban

Many teams that have experience with Scrum move to Kanban or combine it with scrum (Scrumban) after some time. The team that presented Kanban shared how we can combine Kanban boards inside Scrum Sprints. The Kanban flow replaces the Scrum board in that case. The team focusses on creating flow and as a team, they make sure they move user stories through the board. This helps teams see that most often, things get stuck at QA and see that the team members can use their knowledge to solve that impediment. Kanban can also be used on the product level. Some teams make a Kanban board for the overall product. The different Scrum teams working on the same product, then use the Kanban board to pull tickets to their Sprints. Within the team, Scrum boards are used.

Lean Startup

Lean and Lean Startup are often considered the same within the tech world. Lean is an old management paradigm originating from Japan with Toyota. Lean startup was created by Eric Ries in Silicon Valley some six or seven years back as an answer to all the failing startups. Our Product Owner explained that Lean Startup can help tech organizations move towards user-driven development. Instead of teams producing the features invented by a Product Owner, the whole team thinks about problems or user challenges. The Product Owners make sure all team members have direct contact with users and stakeholders. They then look at the challenges of users. Instead of the solution being invented by the Product Owner, the teams figure out solutions. This gives more accountability to teams and creates a value-focused development approach. This is in line with the Agile mindset of self-organization and creating value.

XP

On the developer level, there are myriad engineering practices (DevOps, Continuous Delivery, XP, Pair Programming). XP fits very well within Agile, as engineers are motivated to develop features based on customer value (and even to not develop things until it’s clear that they are needed). XP encourages code reviews on a continuous basis in order to improve software quality. Pair Programming is encouraged, as two brains can solve problems faster and better than one brain.

You can check out our meetup gallery here.