Agile is More Than Scrum
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 hade 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 chose 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 conceptcollect case studiesfind 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 presentationThey can continue research and collecting materials needed for their presentationWhere 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:
A. Product roadmaps need coordination
If 5 teams works on 1 product, organizations need a coordination mechanism. This can self-evolve, can be planned by management or we can follow a scaling framework (e.g. LeSS, Safe, Nexus). In our experiment, the teams self selected product owners. Some product owners asked the area product owner what he had in mind. Some product owners just made a plan with their own team without checking the overall plan. After 5 minutes, Pepe called an all-product owner meeting and the plan was there within 2 minutes. After that, everyone was clear and we managed to make an integrated story.
B. 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 1 goal. I see this phenomenon also in the lego simulations I do during my scrum trainings. If one team finishes its commitment, they’ll consider their work ‘done’. But 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 lego’ or ‘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, focus on value, self organization, etc. It is about a different way of organizing work. To help people change the way they work, we have different frameworks and methods.
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 (e.g. 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 the team 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, Toyota. Lean startup has been created by Eric Ries in Silicon Valley some 6–7 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 is a pletoria of engineering practices (devops, contiuous delivery, XP, pair programming). XP fits very well within agile, as engineers are motivated to develop features based on customer value (and even 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. And pair programming is encouraged, as 2 brains can solve problems faster and better than 1 brain.
Check out our meetup gallery here.