Scrum vs. Kanban vs. Shape Up
A quick overview of the two most famous methodologies out there, and one that’s emerging…
Kanban vs. Scrum:
Kanban
Kanban is the most popular Lean framework. This approach works best for teams that have a continuous flow of incoming requests with different priorities. In the Kanban approach, each request or a work item is represented by a Kanban card (aka ticket/issue) that flows from one stage of the workflow to another until it is complete
Source: https://authoraditiagarwal.com/2019/03/30/scrum-kanban/
If you work for a team that deals with a continuous flow of incoming requests (such as Production Incidents, Service Upgrades across teams, etc.) it’s best to use Kanban.
Tip 1: I would advise spending time thinking of your kanban board columns, exit criteria, WIP limits, and potentially swimlanes or other ways to visualize prioritization. Kanban doesn’t mean ‘dump everything in the funnel and off we go’. You can still organize and prepare the tickets (aka stories/cards)to provide visibility and status to where you are at any point in time.
Tip 2: In most cases, a single ticket requires the collaboration of multiple team members, and if you don’t spend time creating subtasks to the ticket/story, you will see the story in a kanban board column for a couple of days (or dare to say a week) without seeing a continuous flow. In my experience, when you have such situations it’s best to either slice the story further or decompose the story into subtasks, then you can see the tasks flowing and have a better perspective on where the risks or blocks might be.
Tip 3: Consider creating spikes either as sub-tasks or as individual tickets. this could improve the cycle time flow over time.
If you don’t have a cross-functional team, have too many external dependencies, or have too many unknowns, then that’s another indicator to perhaps adopt Kanban as it provides a more flexible flow of what & when to move a ticket to a work in progress stage.
You can read more on Kanban here:
Scrum
Scrum is an iterative and incremental Agile process framework to build complex products of the highest possible value. In Scrum, the team always works on the highest priority items first. The work is performed in short, time-boxed iterations or sprints. Each sprint begins when the team commits to complete prioritized user-stories based on their available capacity in the sprint. An iteration ends when the team has delivered a potentially shippable product increment of the product. Therefore, the scrum development team delivers business value to users at the end of each sprint
Source: https://authoraditiagarwal.com/2019/03/30/scrum-kanban/
This is where I feel like most of the frustration occurs: Do we try 2 weeks sprint. vs. 3 weeks sprint. vs. 6 weeks sprint (read Shape Up). The decision should be up to the team, but often I experienced leadership or management fear that more than 2 weeks sprint will lead to teams following a hybrid or water-agile approach, and they prefer to control that by forcing a 2 weeks mindset. ahh.. yes, we are agile.. we do 2 weeks sprints!
I think the biggest mistake is to focus too much on the output and not the outcome.
When it works, you can have a team that meets every sprint goal, delivers value to end-users incrementally, validates, improves, and work towards a Product Goal (bigger than a sprint goal)
When it doesn’t work, you get a lot of carryover stories (i.e. unsatisfying sprints), no sense of what the team can accomplish (i.e. no predictability), no early feedback through continuous delivery to end-users, endless backlogs, and low team motivation and lack of kudos.
How often have we been close to succeeding but we stop right before it happens?
Tip 1: If you are new to this, the best is to experiment and use retrospectives to see what’s working, what’s not, and LISTEN to the team. Team: Don’t be afraid to change methodologies if they don’t fit you! after all, agile is about failing fast, adjusting, and succeeding together!
Tip 2: When things start to wrong (e.g. unsatisfied sprints), you can also use fishbone exercises to find solutions to problems, or add certain ideas to your continuous improvement backlog, so you don’t forget about some key points discussed.
You can read more on Scrum and what changed in 2020 here:
Shape Up:
I like the Review Notes article from John Cutler. I have no experience in adopting Shape Up (yet), but I can see how this could become powerful if some of the questions John outlines are addressed.
When I read the Shape Up book, my quick notes for further analysis were:
What I like:
- It targets the problem of lack of uses cases/ understanding of expectations before committing to work. This is done during the ‘shaping’ phase of ShapeUp.
2. The idea of ‘appetite’ to define the amount of time we want to spend on a ‘Product Goal’ and confirm what’s truly important, could be very useful to avoid unachieved goals.
3. The pitch template is a good one with enough information to use during the betting table period.
4. The breadboarding technique is good because often we get caught in doing ‘the perfect mockup’, and that reduces the freedom we should give to teams to provide a solution we haven’t thought of.
5. It supports Product Managers and the Engineering teams because there is more emphasis on doing what makes sense and owning the elements of a solution from the get-go.
6. It reduces the meeting time scrum demands on the teams
Tip 1: whether it’s 6 weeks or different, I think that’s up to the team to decide. If you are part of an ART team that follows SAFe framework and does PI planning events (10 weeks of five 2 weeks sprints, where 4 sprints are planned work and the last sprint is left for innovation/training). I would split the 10 weeks into 6 weeks of work (i.e. 3 sprints), 2 weeks (i.e. 1 sprint) of cool-down, and 2 weeks (i.e. 1 sprint) dedicated to the betting table concept.
Tip 2: I would suggest you keep some daily standups, and set up some Goals/Milestones to aim within those ‘6’ weeks. and that if during those ‘6’ weeks you are not getting anywhere, you call for a little retrospective to understand where things are. (i.e. not suggesting you add ALL the meetings of the world (nobody wants that), but keep an open mind for what tools and alternatives you have). This allows you to have more visibility to what’s going on and not lose 6 weeks if you see you are going nowhere. Thus, avoiding the biggest fear of why people chose no more than 2–3 weeks sprints when choosing Scrum.
7. The idea of ‘cooling-down’. It embraces good team collaboration and accountability at all levels.
What I don’t like (or understand yet):
- It assumes you have a good cross-functional team where everyone can step up. This is ideal but the learning curve can push people away from trying this technique.
- Not sure I like the idea of not having backlogs. This might work for small companies, but not if you have multiple ARTs doing strategic initiatives that support multiple geographies, etc. I think for large-scale companies/teams, you need to have a program backlog based on the strategic vision for the year, allowing leadership and program teams to confirm visions, roadmaps, and priorities across geographies/sectors.
- The idea that people in the Shaping phase are different than the people doing the work is not something I would promote. In the end, you want the ‘doers’ to know what/why/how to build, and if they are not part of the shaping phase, they will never grow an engineering mindset. I can be wrong in the shaping phase understanding but I believe a better approach could be setting a rotation where shapers become builders, and previous builders become shapers of the next cycle.. so that way you form rotational cycles where everyone learns, and you avoid having to depend on 1 or 2 key people who are either hard to reach, or on vacation, or left you with a void of some sort. You might want to read the “dual-track agile” concept, as it’s similar to this:
Conclusion
When organizations embraced the Agile methodology was primarily because they wanted to enable innovation and flexibility to pivot quickly.
Perhaps in today’s world, we focus too much on Roles vs. Accountability, Output vs. Outcome, Velocity charts vs. Product Goals/Sprint Goals, Attending meetings vs. Having focus time.
I think we lost sight of why we liked Agile at first, and I would suggest we go back to basics and keep things simple. So no matter what methodology you end up choosing, make sure at the end of the day it allows you to have celebrations with your team.
