They are now scrumban
For a while, there existed a scrum team working on a cloud-based software product. This team worked on the APIs and backend changes for the application. The team usually had a release every month. For a new program on the same product, the team was asked to work on its interactive front end, APIs and go in a continuous delivery model. The team decided to continue its two-week sprint as before and to use more automation tests to enable continuous integration and continuous delivery.
Here the team is into a few worries.
- Having more skills on APIs helps; however most team members needed time to scale up on the user interface development.
- Moving to CI/CD requires automation skills.
- Having to support existing APIs need to be accounted for.
- Being a new program, domain knowledge to be gained.
To overcome some of the issues, the team has decided to attend training on some of the areas that need expertise and to get help from some of the other teams doing similar work.
Team has started its sprint with very few stories for the sprint, with the goal of learning the ways to tackle the challenges. With few stories and more learnings first few sprints had gone well. However the team is not able to hit its earlier velocity, and very little story points contributed to increment, compared to their previous.
Now, this is something the development team, product owner, scrum master, and the organization is worried about. The scrum master has tried to find a solution for this with the team, during retrospectives. Challenges seem to be around too many changes the team has to adapt to and the continuous delivery model. Training and the current sprints are helping and will improve the team over a few more sprints. However team members are more worried about hitting impediments while their stories are in progress, and at the same time has to go with continuous integration processes.
Scrum master now has something in mind to get it better – like the lean, need-based, pull system which is Kanban. He didn’t want to completely move this team to kanban. So he thinks to have the better sides of scrum plus the better sides of kanban. So he gets his thoughts towards Scrumban.
Now team discusses it and they have more skepticism to have another change on top of all the existing ones. Then the ScrumMaster ensures them a smooth move; as the model is eliminating waste process, boosts continuous delivery and helps more team collaboration. Here is what happened to the team’s working model then.
Visual board
. The team now has visual kanban board with enough swimlanes defined. This helps everyone understand where the team stands, what is in progress, what is to be automated, what is in automation, what is getting delivered.
No sprint
. Sprint concept is removed. You work the kanban way. So the timelines and spillovers are not a worry.
Limit work in progress(WIP)
. Put a limit to a number of items in progress. This sounds cool because you don’t need to take everything for a sprint(as no sprint here), but just enough for the team to work on. Now if the something gets blocked, its team’s responsibility to clear the impediment; otherwise they cannot pull another item to work on, as the maximum work in progress is limited. For eg: if a story on ‘test automation in progress’ lane is blocked and the maximum WIP is reached, the team must work to get that unblocked, only then others in the team can pull ‘dev completed’ stories to automation.
This is something team liked a lot. Now the responsibility is more collective.
No estimation, No story assignment
. During sprint planning, the emphasis is on finding the priority of stories and getting the questions answers. Highest priority items in the ‘ready’ column get pulled to development in progress to start. Plannings are now shorter and more effective to the context.
The story is now not assigned to anyone. Whenever a team member has capacity and max WIP is not reached in the stage, pull the story of the highest priority.
One more thing to be taken as an advantage is the ability to bring the support items (maybe some quick fixes on old APIs here), can get added and taken based on priority.
Continuous delivery
. Unlike in their monthly release mode, items completed are now ready to be integrated and delivered continuously. This makes the product owner and the org management happy.
Reviews and Retrospectives
. These two ceremonies are taken from the scrum and get followed the same way as in scrum. This promises to keep the inspect and adapt principles.
Scrumban is not the ultimate magic; however, this team enjoyed the blend of Scrum and Kanban, with its own challenges. So when your team is in the need that suits, move scrumban.
