Tuesday, July 27, 2010

What will KANBAN bring in to your offshore projects?

During last couple of years we have been talking a lot about agile as a whole and specifically about SCRUM, and 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 opensource 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 for collocated teams due to its concepts such as white board discussions, frequent meetups , open culture, 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......:-)You know that if you are a member of yahoo "Scrumdevelopment" group ;-). The latest arguments in agile world are mostly based on KANBAN.
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 conscious 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 all of us who are in the offshore project context. I will discuss few points here.

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 meetings (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 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 workout.. it will lead team mates to think.. ok .. Im having this issue.. but I may ask it later.. who knows whether my onshore mate is busy right now.. may be he is at another meeting.. this guy will pass hours, days…. And there are 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.. lets just send him an email..or this guy keeps waiting without asking questions…At last all these tiny issues will become a big issue to the project.
About the retrospective, now we know 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 practitioners 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 in front of the Kanban story display. Not based on the sprint plan.

2. 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.

3. Do not estimate – or at least pretend you don't estimate :-)

How will it work? Yes it can work in the perfect world. you are going to run 100 m., 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. Dont raise your eyes.. Projects without estimations happen in real world too. I have an example with one of our current projects at Exilesoft. The team work with this model with a very close work relationship with its onshore team in 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.

4. 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 points 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.. its simple. Its 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. It provides high degree of transparency.

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 and XP 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.

No.. Im not saying that agile is the magic pill which will flush out all the problems in offshore software development. That's what Dave and I are going to discuss at Agile 2o1o 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.


Pawel Brodzinski on 5:49 AM said...

I think about Kanban and Scrum being two flavors of the same approach. What more these two are often mixed. Actually no one forbids us to use practice or technique which isn't explicitly stated in the method we use.

I agree that Kanban in distributed team is more difficult, but well, every method is. Co-location brings significant advantages for the team and since Kanban bases much on informal interactions off-shoring can't be without effect. But still I'd lie if I stated Kanban is no good for distributed teams.

Two more things I caught reading the article (even though I could discuss Kanban extensively):

1. Size of stories. Actually I've heard about different approaches from teams which made transition from Scrum to Kanban. Some of them made their stories larger, some of them smaller. I'd say there is no rule. In our case we use MMFs a bit bigger than we used to when we wrote detailed used stories. But then we rarely developed single story at once (usually a few at the same time) and now we do.

2. Charts/visuals. One of great charts which helps to point issues in process is Cumulative Flow Diagram. It points not only how you act in short-term (like burndown chart for sprint) but how team performs in the long run. Also a few conclusions regarding product management can be drawn.

If you want to read more about Kanban I wrote a series of posts about Kanban in our team, called Kanban Story.

Thushara said...

Hi Pawel, Thank you for the comments. Ive seen some of your presentations at ICPM and quite nice.
I agree… any method or process we use, it brings challenges from distributed and specially the offshore environment. Same time, Practicing Scrum for some time in this context, what I find is the good time box discipline of scrum makes offshoring less difficult due to the commitment it demands from both the ends. I like Kanban as a concept, and one of my teams already doing it now for over an year (Atleast some version I would say), but to most our other projects in onsite-offsite engagements, its absolutely too agile. There may be no specific rule in Kanban for not to shrink the stories, but when I compare most the Kanban story boards, the stories they write are big compared to the elaborated stories we write in Scrum Product backlogs. I agree.. its all up to you to use it based on what you want.. Agile is not a process.. its just some guidelines.. with different thinking.. We can make our own process which fits in to offshore context.

Eirik Fjellaksel said...

Good argument from outsource projects angle. But you have missed the most important approach of KANBAN. That’s the RELEASE. You can do a release when you are done.. “Done” means ready for deployment. No more waiting till the iteration finishes.

Thushara said...

Hi Eirik,
Thanks.. Did I miss it.. Yah.. Now I see that.
Releasing when a user story is done is really good when you have feature stories and if we can release each feature when its done. Or critical bug fixes. But most the offshore projects what I have worked with, the offshore teams do not get access to the live production environment and deployment happens in a test environment. There is a manager onsite, who is doing the acceptance test and then deploy them in the production environment. Due to their time commitments, urgent fixes needed irrespective of the time zones we are in, they prefer to plan releases and be ready with it in advance for any deployment. In the scenario having high level iteration release plans work well.

Adipa on 5:30 AM said...

I have my personal experience in KANBAN. Even though it's much better than waterfall, lack of time boxing can cause conflicts with deadlines. However I believe it’s the best way to follow when the requirement definition is not solid and it changes mid sprint.

Jerry Durant on 6:04 AM said...

Whether it's packaged as KANBAN or simply sound agile engineering the points take are well. The challenge for most companies is transitioning from traditional methods to lean engineering (whether Scrum, Crystal, or KANBAN). In terms of Agile Outsourced Engineering the challenge isn't in the processes on the engineering end it's keeping a healthy communication/activity conduit. This requires pre-preparation, oversight and utilization. We were one of the first organizations to engineer a training/process service specifically for agile outsourced/offshore engineering.

J. Durant - IIOM (www.Int-IOM.org)

Vinodhini Srikrishnarajah said...

In the current project I am working in we neither have planning meetings, nor do we time box them. Even though with our current customer it works well, it might not be the case in some other projects. In one of the projects in the past, at the end of the planning meeting the question the product owner had was 'when can I see the system?' This indicates that some people have the time boxed thinking, which in turn makes us follow a time boxed approach.

Further, even though in my current project we do not have sprint planning (its more towards Kanban) we do practice daily standup meetings with our client. We might never come across a process or methodology we can practice without any modification according our needs. One of the reasons for the agile software development techniques to become more famous is their flexibility to customize the way the team feels fit.

Thinking about the size of the user stories we write, having them at smaller level or on the other hand having at higher level, have benefits of its own. By keeping the Epics in the product backlog at a higher level even after breaking them in to smaller user stories, without replacing them with the identified user stories would help. Some tools like IceScrum (http://forum.icescrum.org/) allows us to do this.
It is wonderful that now we have tool such as TFS which enables us to have more integration and automated builds using tools such as TFS. It handles the traceability matrix itself. TFS will also eliminate some of the bottlenecks we are having in combining the development and testing cycles in our projects.


PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com