You are here: Home Blogs What will KANBAN bring in to offshore projects?
Wednesday, 28 July 2010 15:13

What will KANBAN bring in to offshore projects?

Written by 
Rate this item
(0 votes)

offshore-outsource-project-managementDuring last couple of years we have been talking a lot about agile as a whole and specifically about SCRUM, how that help in offshore project environment to remove most the challenges introduced by the traditional waterfall environment.

While we were talking a lot about agile project concepts, engineering also has evolved a lot to support these concepts such as improved continuous integration and automated test process which eliminate most the problems of multiple team work integration and iterative releases, Cruise control’s webpage which really help to get one good picture about all what’s happening in multiple sites, New tools such as TFS, VS2010, and some open source tools are also in high demand nowadays.

So obviously, We are on right track... agile is a way to go in off shoring.. the fact may hurt some of our offshore waterfall folks, but that’s how it is..  one can argue that most the agile methods are good in collocated teams due to its concepts such as white board discussions, frequent meetups, open culture, high degree of transparency etc. .
After working with large offshore teams in India,  Martin Fowler said “working offshore agile feel the pain much more than those using plan-driven approaches. But it's still less pain than the plan-driven methods themselves!”  He said it best !

Agile is full of arguments J You know that if you are a member of yahoo “Scrum development” group ;-). The latest chaos in agile world is KANBAN. J  If I explain simply, Kanban is a very lean approach to software project development. In SCRUM, we said we cut the waste. In Kanban we cut them big time. we see some agilists moving rapidly in to Kanban, but some are little doubtful about the benefit it can bring in.  Jeff Patton said in his blog  “I’m seeing agile people behave as strangely about Kanban as traditional process folks behaved about Agile.”  Having said that, lets look at what Kanban will bring to us who are in offshore project context. I will discuss few highlighting points.

  1. Scrum is all about time alerts – Kanban is all about event alerts.

In offshore/ distributed team context , the biggest challenge we have is to eliminate the isolation, get team members work closely with the remote teams, still have the onshore team commitment to meet up with the remote teams frequently even when they are distributed. SCRUM comes  handy in this as it brings disciplines such as specific sprint planning meeting at the beginning of each sprint, daily scrum meeting (even via remote communication facilities) in every 24 hours, and retrospective after every sprint. So almost all are committed to participate these events.
But Kanban has a more of a loosen up approach to it.  Simply there is no time box approach, no sprint planning. They fix a limit for WIP stories. Kanban uses push and pull theory, when the WIP items becomes lesser they pull from the backlog and fill the stack.


kanban folks argue..why having daily meetings,..? just raise your hand when you feel you are not in sync with your team.. lets meet up..  Why do you have to meet up daily and talk about what you have done yesterday what you will do today like a prayer. ..?


But we know in offshore context, this is not going to work out.. it will lead  team mates to think.. ok. I’m having this issue. But I may ask it later. Who knows whether my onshore mate is busy right now. Maybe he is at another meeting. This guy will pass hours, days…. And there is lots of unspoken issues stack up with the offshore guy to ask the onshore guy when the time is right.


From onshore perspective. Again we are inviting the same old problem. Let’s just send him an email... or this guy keeps waiting without asking questions…At last all these tiny issues will become a big issue for the project.
About the retrospective, now we know that we need to have a retrospective by end of 10 day sprint or so. But with Kanban, its again an event based thing. If you see that you had a serious issue when testing, call the team and have a retrospective, why you need to wait till end of 10 days to have it... Hmmm... However most Kanban practioners accept that this doesn’t work so well even with collocated teams... So they are also moving towards having daily meetings to talk about the bottlenecks and what they do today based on the Kanban board. Not based on the sprint plan.

  1. Comparatively larger user stories.

When it comes to offshore – onshore engagements, requirement understanding is more challenging.. smaller user stories make the requirements more clearer and easier to elaborate upfront. But in the same time, the larger stories also has its own benefits such as easier designing, planning and to keep the product backlog in shape. But I would advise the teams to go for smaller user stories simply because that eliminates many risks in requirements especially with the challenges in distant communication.

  1. Do not estimate – or at least pretend you don’tJ.

How will it work? Yes it can work in the perfect world. You are going to run 100m., you have no idea how long you will take to run.. But you will run as fast as you can. In scrum what happens is that... You run for 10 min and see how long you could run with your maximum speed. It’s a time box. Don’t be surprised...Working without estimations happens in the real world. I see one of our current projects at Exilesoft working in this model with close work relationship with its onshore team from Norway. It works very well with the trust they have built with our team sitting in Sri Lanka for over an year now.  But this needs very capable resources, so much trust on remote teams and lots of commitment from the customer to work with its distributed teams. Without that, this will result major issues and pain in business.

 

  1. Burn down charts – do we really need them?

Kanban practitioners argue about the velocity used in many other agile methods such as scrum. Velocity measured based on story point’s burn down rates and sprint deliveries can lead to some conflicting ideas among the stakeholders as well as within the members of the same team. So they say.. Concentrate on cycle time of a story. That’s what matters.

How do they do that... It’s simple. It’s about noting down the entry time of the Story X, and done time of the Story X. this difference will show you the waiting and the production time of a story in the queue. What needs to be done is to reduce this cycle time as the team improves with the technology and skills by removing the bottlenecks.

What I see with burn-down charts is that burn-down charts with some meaningful annotations has a real good advantage in remote team environments to communicate the progress of the current work sprint as well as overall as a product how we go with the development.

Overall I see Kanban will work well with some of the current maintenance projects we have. Working on a unplanned backlog, limiting WIP number, monitoring cycle time and less focus on estimation will work well with these projects.

However, I see that Kanban together with some scrum disciplines will also be a good combination. Its all about trying out these methods in offshore environment and seen the benefits, drawbacks and improving your offshore - agile practices.

I’m not saying that agile is the magic pill which will flush out all problems in offshore software development. That’s what Dave and I are going to discuss at Agile 2010 on 12th August (large scale and distributed agile.)
Our topic is simple and straight “Why you suck at off-shoring even with agile “  see you guys there and lets have an interesting discussion.

 

Read 8178 times Last modified on Wednesday, 28 July 2010 15:32
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 420 guests and no members online

Got something to say?