It looks like you're new here. If you want to get involved, click one of these buttons!
Most people use 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 & Lean startup, XP, Scrum, Agile). The experiment was organized using multiple scrum teams and sprints. We had an area product owner: Pepe. And we had 5 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 1 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.
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 which concepts could fit, how they all fit together and in what priority they should roll out the agile concepts. They’ve selected one person as the leader of this research/presentation phase. He has authority to engage as many people as he needs to get the information.
We self-organized teams of 4-6 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: a presentation about the agile concept the team chose.
The teams went through 3 sprints:
Sprint 0 (15 minutes): setting up
Self-organized team formation. Selection of scrum master & product owner (+ additional roles?). Discussion between product owners and area product owner
Sprint 1 (20 minutes): product design and plan
project charting: 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, role play, sketching, dancing, etc
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)exchange experiences with the concept
Retro: 3 minutes
Sprint 3 (20 minutes): create the presentation
Teams work on their presentation. They can continue research and collecting materials needed for their presentation, where required, product owners have communication with their area product owner
Retro: 3 minutes
Demo: 5-8 minutes per team (depending on the size of the total group & number of teams)
The big challenge in this experiment was how to coordinate the different presentations of all teams into 1 overall presentation. Pepe was running around, sweating, in the first 10 minutes. The 2 things that I observed (applied to real projects) in the process:
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.
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.
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 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 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).
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 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.
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.
Post Published By: Hugo