From Scrum to Kanban
This month marks one year from the time we switched from Scrum to Kanban. I think this is a good time for us to review the impact of this change.
I have experienced two working environments that practiced Scrum and they were quite different. That's why it may be useful if we start with sharing of our Scrum practice.
Our iteration is 2 weeks long. I am quite satisfied with the duration as one week is a bit too short to develop any meaningful story and 1 month is a bit too long to plan or to do retrospective.
Our iteration starts with the first Monday morning retrospective. On the same day, there is iteration planning in the afternoon. For the rest of the iteration, we code as much we want.
Our product owner requests for us to do two rounds of demos. Soft demo is on the last Wednesday of iteration, where we can show the newly developed features on development machine or Stage environment. On the last day of iteration, we suppose to do final demo on UAT environment in order to get the stories accepted.
Agile emphasizes adapting to change, but we still do T+2 planning (two iterations ahead). With this practice, we know quite well what is going to be delivered or to be worked on for at least one month ahead. If there is urgent work, the iteration will be re-planned and some stories will be pushed back to next iteration.
Our daily life starts with a morning alarm. Some ancient coders in the past set the rule of using alarm for office starting hour. Anyone come to office after the alarm ring will have the honor to donate 1 dollar to the team fund. This fund can be used to host retrospective outdoor or to buy coffee. To be honest, I like this idea, even it effectively cut 22 dollars to my monthly income.
15 minutes later, we have another alarm for the daily stand-up. This short period is supposed to be used to read email and catch up with what happened overnight. Our team base is in Asia but is actively working with project stakeholders in Europe and the US. That is why we need this short email checking session to have a meaningful stand-up.
It is not really Scrum practice, but like most of other corporate environments, we need to fill up time-sheet at the end of the day. Using time-sheet, we keep track of the time spent versus the estimated effort and use that to calculate velocity.
As specified by Scrum , we have a development team and product owners. In our company, product owners are called Capability Manager. At the moment, our management is discussing whether they should split Capability Manager into two roles, one focused on technical aspect of product and the other solely focused on business aspect.
We do not have Scrum masters, instead, we have Release Managers. This role is a bit confusing because it does not appear in any practice. In our environment, Release Managers work more like the traditional Project Manager. Not all the projects will have a Release Manager but for some bigger scale projects, Release Managers can be quite useful and quite busy as well. Most of our products are SAAS applications, and some successful products can have more than 100 customers worldwide. Capability Managers can focus on product features and let the Release Manager deal with story planning, customer deadline and minor customization.
There is also one more discussion on whether the Release Manager job requires technical background as they need to do iteration planning and some stories are technically related.
We use mixture of Excel spreadsheet, Jira and Rally in our daily life.
Jira is the leftover tool of the past, before we moved to Rally. Now, we only use Jira to track support tickets and defects.
Rally is the online platform for Agile practice with built-in support for iteration, story, defect, release, and backlog.
Even with these tools, we cannot avoid using the old day spreadsheet to keep track of team resources (team resource pipeline) and do resource planning (resource matrix) as well.
Due to resource scarcity, we still have a multi-tasks team that deals with a few projects and a few product owners at the same time. Periodically, the release managers need to sit together and bargain for their resource next few iterations.
As one of my friends always says, Scrum is more about spirit rather than practices. I can't agree more with this. Applying Scrum is more about doing things with Scrum mindset rather than strictly following written practices. Personally, I feel we are applying Scrum quite well.
At first, in the team standup, we try our best to avoid making it look like a progress report but information sharing and collaborating session. Once in a while, the standup lasts more than the default 15 minutes because developers spend time elaborating ideas and discussing things on the spot. Release Managers or Product Owners do not join our daily standup.
Our retrospective is a closed door activity, which only involves team member. Both Release Manager and Product Owner will not join us unless we call them in to ask for information. Each team member takes turn to be the facilitator. The format of retrospective is not fixed. It is up to the facilitator's imagination to decide what will we do for the retrospective. The rest just sit down, relax and wait to see what will happen next.
The planning session includes tasking and a Poker Style estimation game. It is up to the team to re-estimate (we estimate one time when the story is still in backlog), verify the assumption and later arrange and commit the story to fit team resources for this iteration nicely. Sometimes, we have a mini debate if there is big gap between team member estimations.
Why we moved to Kanban
You may wonder if our Scrum worked so well, why we moved to Kanban. Well, it was not our team decision. Kaban was initiated at UK headquarters and spread to other regions. However, working with Scrum is not all perfect, let me share with you some of problems that we are facing.
Resource Utilization at the end of iteration
This problem may not be very severe in our office but it is a big concern in other regions. Due to technical difficulties, sometimes, estimation is very far from spent effort. This leaves a big gap at the end of iteration. It may be good if the gap is big enough to schedule another story but most of the time, it is not. This creates the low productivity issue that management wants to fix. They hope removing iteration will remove this virtual gap and let the developers focus on delivering work.
The pressure from iteration commitment
By committing to the planned stories in the iteration, we are under the pressure to deliver them. The stories were estimated with 2 weeks duration for development but we normally needed to deliver them faster to match the soft demo on Wednesday and final demo on Friday.
To make thing worse, our Web Service team is in other region and we needed to raise the deployment ticket one day in advance to get things done. If the deployment ticket failed, we needed one more day to redeploy. The consequence was whether we develop too fast to meet the deadline or we follow the estimation, then miss the commitment.
Another concern is the pressure to estimate and commit to something developers don't know so well and still be punished for missing the commitment. This creates the defensive mindset where developers will try to include a safety buffer on any estimation they make.
Then, our Kanban
Life is not so much different since we moved to Kanban. For the good, we have the budget to buy a big screen. For the bad, we do not do iteration planning any more. However, we still keep our retrospective on the first Monday morning.
Now, we open the Kanban board in Rally to track our development progress.
We create our Kanban board with 7 columns, which reflect our working process
- None (equals to backlog)
- Peer Review (only after Stage deployment)
- Deploy to UAT
- Acceptance (story is signed off by Product Owner)
- Deploy to LIVE
The product owner creates stories in backlog, which will be pulled to Tasking column by the Release Manager. After that, it is the development team's responsibility to move this story to Deploy to UAT column. After that, it is product owner's responsibility to verify and accept it. If there is any feedback, the story will be put back into the Building column. Otherwise, it is signed off and ready to be deploy to Production. It is up to the Release Managers when they want to deploy the accepted feature to Live environment.
As Kanban practice, we want to limit multitasking and set the threshold of the capacity for each column. As we do pairing, with 8 developers in our team, the threshold for each column is supposed to be no more than 4. However, this is easier to say than do as stories are often blocked by external factors and we need to work on something else.
There is no iteration planning anymore. Rather, we do planning whenever there is a new story in Tasking column. The story is both tasked and estimated by one pair rather than collecting inputs from the whole team.
What is a bit unnatural is due to our multi-tasking nature, one pair does not follow one story from Tasking until Deploy to UAT. To deal with this, we often need to come back to the pair that did tasking to ask for an explanation.
We still need to estimate but there is no fixed time for demo. In the regular meeting between team and Release Manager, the most asked question is "Do you have anything to demo today?" and the most popular answer is "No".
When aborting Scrum, we also aborted Story Point Estimation. We still count the spent effort versus estimated effort but it's only for reference. From last year, we moved back to estimation by pair day.
So, how do we feel after one year practising Kanban?
I think it is a mixed feeling. On the good side, there are less thing to worry about, fewer commitments to keep, and a better focus on development. Plus, we have the big screen to look at it every morning.
However, things are not all rosy. I do not know whether we do Kanban the wrong way or if it is just the nature of Kanban, developers do not follow one story from beginning until the end. One guy may task the story this way following his skills set and someone else will end up delivering the work.
Moreover, I feel Kanban treating every developer equal, which is not so true. If there is one story available in Building Column and you are free, you must take the story, no matter you have the skill or not. It hampers the productivity of the team. However, it also can be positively viewed as Kanban fostering skills and knowledge sharing among developers.
Moving to Kanban also causes developers to spend more time on story development. There is no pressure to cut corners to deliver but there is also a tendency to over-deliver goods to have features which are not included in the Acceptance Criterias.
At least for us, for Release Managers seem to be not so happy with the transition. Lack of iteration only makes their planning more ambiguous and difficult.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)