Lean concepts for the operations management - part 1

Right now we have managed to go agile with all our projects. When it comes to agile, we are quite keen on SCRUM as disciplines scrum brings to the project teams as well as to the customers help a lot in our offshore project context. In our organization, some teams pushing it to the extreme while others take the process bit relaxed..We believe that if something works right that’s the way to do it!

Ok.. This is the story… 3 weeks back, while having a discussion with my CEO over lunch.. we came up this idea of getting our management in to agile.. It started with a simple conversation … “Let’s think loud….Why can’t we have a backlog for our management and work as a management team across our departments to be more solution focused...” :-)

Great idea …but hell ..it will be really challenging to do that.. There are challenges when implementing such concepts with the management in an organization.. how far we can use the transparency..can we have all management tasks on the wall…? how about layers within the management ? (Of course we don’t have huge hierarchy), is it only the management concepts of lean we need to add up..? …lot to think about….. I will discuss them later..

One thing I love working at Exilesoft (may be most SME level software companies) is that, no matter who that is, if anyone got any good ideas we can execute them in no time..( One of the recent examples is our recent job advertisement campaign which was quite successful. Few engineers came up with this new idea for a recruitment campaign and we changed our standard recruitment campaign over night. it worked!)

Ok..Coming back to the story.. We need our management to go agile.. But how do we do that.. ? Its challenging than implementing agile in a software development team.

First we had to convince ourselves why we need our management to go lean.. Of-course there were quite good reasons;

• 1. We have a challenge.. Our CEO spend time in Sri Lanka and Norway.. so most the time its challenging to have that transparency of the management activities while he is in Norway. Simple rule.. Status reports doesn’t work.. we all know that…
  
  
• 2. Some of the team members in the management team also travel frequently, so again how do we have that same transparency of work just like when we were collocated?
  
  
• 3. There are certain tasks in the HR dept, IT dept, which are always dragging due to other commitments (Which are not marked as “Critical” )such as Employee handbook, some New backup process etc. which needs to be finished at some point , instead more tasks are adding in to the list and sometimes we lose track of time of these long term tasks.
  
  
• 4. Management needs to be cross functional too to deliver the best and help each other.
  
  
• 5. Maximize the time utilization, if someone has got some time he or she should be able to pick a task or help another to get a task going..
  
  
• 6. We are a start-up.., so I don’t have to tell you the challenge.. we need to deliver more with less.

Ok we had enough reasons to go lean..go agile.. But then..Which agile would it be ..?

Next:

Lean concepts for the operations management - part 2 – Why not scrum..?

Lean concepts for the operations management - part 3 – Looking at KANBAN..

Lean concepts for the operations management - part 4 – How did we implement it ?

This is a great opportunity for you to Join our agile teams !

The agile bird !

Its always a great experience to share knowledge with others. Today we had a mini workshop for some of the colleagues of Informatics and few of our new Exilesoft colleagues together to learn agile.

Total time box – 2 hours for the training. (4PM to 6 PM) In that, I had to spend first one hour to take them though the agile concepts and introduction to Scrum. I tried to cover up some of the practical issues too such as planning a huge backlog, vertical designing or so which they are already into.

So we were left with 1 more hour, which I wanted them to go through an exercise to learn and feel agile concepts better by themselves.

So, yesterday night I prepared this small backlog for them…

As a	I need	So that	Weight	Priority
Marketing Manager	a bird with 2 wings	I can sell the toy to kids
VP Marketing	The bird to carry the logo	We can brand it as our own toy
Sales person	The bird to have red color feathers	It will be more appealing to young girls
Marketing manager	The bird to have blue eyes	The bird will be more appealing to the kids
Production manager	The documentation on how to make the bird	I can train more people to produce birds like this
Marketing manager	The bird to have 2 legs	The bird will be able to stand
Marketing manager	The bird to be bundled with a cage	We can add more value in the market
Brand manager	A catchy name to the bird	The bird will be popular among the kids
Angry kid	Soak the bird in water	The bird will be destroyed easily

The product vision: to produce a toy bird to the market, this can compete with other toy birds in the market.

Product backlog

You may notice few points in the product backlog user stories. There are some functional requirements which is a must to deliver and some nice to have features too. With the angry child user story, I wanted them to get the idea of having user stories from hacker’s perspective to come up with security related user stories too to the product backlog. Documentation user story was brought in to the picture, so that team will understand if the documentation is needed by stakeholders to treat it as a user story and deliver it.

We had 8 members, so we split the team to two. My colleagues Shamira Dias and Manujaya Kuruppu volunteered to play the product owner role for the 2 teams. Thanks to them they did a great job of taking teams through the product backlog and helping them to learn estimation techniques.

Shamira and Manujaya prioritized the stories to their teams after having a discussion with them. They prioritized the highest market value items first. Both the teams played planning poker to estimate the user stories with their product owners which helped them to get the real idea about relative estimation using story points.

After that.. They decided 2 releases for the backlog. First release within 15 min and other release within 20 min. which is the final release of the bird. Product owners mentioned to their teams what they need for the release one.

Here they are busy making this bird… Team A

Team B - Making the bird


When they did the final release, Navin came as the customer and he had to make a hard decision about buying one bird. He bought Duckybird J because it could fly perfectly and he was fascinated about his flying skills.

Here is the Mountain bird by team B at the final release :-)

Here is the Ducky bird by team A at the final release :-)

After that we did a retrospective with the teams...( we had no time to do a retro after the release 1 which could have been the perfect scenario.)

The findings

• 1. In release 1, team A failed to do the product release on time even with minimal required features. So they saw how their competition came to the market.
• 2. Team B prioritized the red feather story for the release 1 , so they had no time to deliver a stable product which is a bird who could stand.
• 3. Team B delivered extra (Gold plating??)_ nice decoration on bird which was not included as a user story in the backlog and they totally forgot about the flying feature of the bird which made them to loose their opportunity in the market against the competition
• 4. Team B – the whole team spent time on doing documentation and didn’t deliver the cage and the fence. – there scrum master was too involved in building and forgot to get his team guided towards signing in to various tasks to improve the utilization of time. which can happen in real development projects.
• 5. Testers of both teams didn’t add much value to the team from testing perspective.
• 6. They learn the difference of a scrum master from the Project Manager
• 7. They learned how the team culture works in agile organizations.

Rewards

After that , I rewarded the scrum master of team A as his product owner managed to make a sale based on what his team produced.. The team accepted that they didn’t feel very happy about it as they felt he was rewarded at their cost and instead the management could have rewarded the whole team because the whole team worked hard to release a nice toy bird to the market.

Thanks to all who participated the training.. it was a great experience to share knowledge with a team from another company. I'm sure my colleagues also enjoyed it a lot.

Update: you can see the PB user story about flying is missing.. This is how the PB was at the initial stage.. which I wanted the teams to learn that PB is not perfect at once.. there are so many hidden things which will come out when PO refines it again and when the team ask the question. Team knows that many birds fly and this is a question I expected them to ask with their domain knowledge. Thank you @michelesliger for notifying this to me. This is an addition I did when posting it.

Agile2010 - Part 4 - Why you suck at offshoring even with agile

Needless to say that this is the biggest challenge I faced so far in my career life.. To speak at agile 2010 conference for the 1^st time.

Everything sounded challenging form the day 1, first to be one of the few selected speakers out of closer to 1000 proposals, 2^nd it was in US, 3^rd, it was a pair presentation which I have never used to do before, 4^th I knew and heard that Agile conference is really a challenging place to be in as people who come there coming for a real purpose, they are tough, in thrust of knowledge and very interactive in sessions… It all proved true to me from the day 1 at the conference.

So with all these.. Dave and myself prepared the presentation ( all virtual ;-) ).., Which was an interesting story.. We will discuss this on Monday (6^th Sep) during the retrospective we are going to do.

On Thursday 2^nd morning session under “Distributed and large scale agile stage” was ours.. It was again challenging to decide how to dress for the presentation.. (Sounds more feminine? )
The challenge was that in agile conference most the presenters wore T shirts , shorts and Jeans..They looked very causal.. .. I knew Dave would do the same.. But still I’m not used to this. So I thought of wearing my usual pair of Grey jeans and a Black office shirt.. (Sigh.. I wish if I had some pictures or recording of the presentation… After the presentation only we realized that we couldn’t request for a single picture.. which was terrible.. and I’m sorry for that…)

Few good signs : Room was getting full.. which was cool.. I would not make up myself to present in an empty room..

Bad things.. this huge projector stand covered some of the audience..and top of that Dave had to use one fixed mike while I was using the wireless mike. So he had to stand still while I was all over. One attendee mentioned that my voice was low for few times … I think the way I fixed the mike to my shirt.... it was moving a bit…

Not too sure good or bad thing :) Dave started his tweeting via iphone.. Which made me creepy :-) Uh.. Commooonnn You are tweeting while we are in the presentation.. Give me a break.. But he was so cool... He just wanted to tweet..

Getting ready to present "Why You Suck At Offshoring- Even with Agile" with @Thush at #Agile2010 would be a good reminder to other attendees

After disappointing you all about recording and pictures I have one good news to you... We are doing a video conference on retro as Dave is in US and Im in Sri Lanka., So possibly we will record it for you. Stay tuned for that ;-)

Here for you .. Some of the interesting slides which helped us to get the audience interactions effortlessly..

We discussed the important points anyone should consider in an agile offshore project initiation, and the areas where you can go wrong easily... loads of examples here...



Dave brought up some real cool examples of working with Asian team while he is working in USA.. the point here was.. "We both have layers" as Shrek said to Donkey..




This was an interesting debate.. how you should position your contracts in offshore market without killing the idea of being agile.. what will do and not do..


The important one ;-)

Agile 2010 -Part 3

Here we go about my 2nd day there. and bit of day 3 too..

In the morning I wanted to attend to some of the agile game sessions..
If you ask me why I attended to gaming sessions in such conference, I would say its due to 2 reasons..

1. We have many new recruits joining Exilesoft project organization frequently. They are coming from various project development/management environments. Getting them to agile thinking is fun but I must admit that its always challenging..Because we always have a limited time to get things going with new colleagues. So its time to learn some interesting games which helps us to get the people up to speed of agile thinking by adding more fun in to it.

2. At this time Ive realized how badly Jetlagged I am.. so it was becoming impossible for me to sit in a lecture room session.

In the whole conference I managed to attend to 2 gaming sessions. However there were too many games in this conference and made me realized how much games are integrated with agile training. One game session I attended was conducted by Michael Sahota and Gino Marckx.
Their game was about teaching strategies which will help to understand the backlog and prioritizing it.
The understanding of “must have” , “what can be negotiated” and how to fulfill stakeholder satisfaction was demonstrated by them.

The other gaming session I attended to was done by Michele Sliger at Innovation Games

In her session, each group had to volunteer to take care of a kennel during a holiday. She gave the same product backlog to each group. User stories were all about cleaning dogs, cats, brushing them, updating the database, cleaning equipments, feeding, walking dogs etc. It was a time box. We had to calculate the number of hours we have in hand to do the maximum must do ones. When we look at the backlog we understood that it was way too much hours needed. So we had to prioritize and each of us had to sign in to what we had to do during the day.

The most interesting part was the retrospective she conducted by asking everyone’s experience.. I couldn’t believe it...Some of the ladies in the class have taken this game way too serious.. they were very emotional about not having enough time to walk the dogs.. :D Some didn’t like Cats so they have refused to do the jobs related to cats.. :D I like that enthusiasm ;-)

Key“take home point” to me was that.., we need to have more games at office to get the concepts going.. That will add lots of energy to the teams.. But sure Dog Kennel is not something we see often in Sri Lanka.. ( Oops.. I hope those ladies will not read my blog.., Otherwise I will be in trouble. ) So I need to do some games wich they can relate more with their experience.. we are already planning to do one session in October.. which I will share with you for sure.
2nd day evening… .. what did I do.. Hmmm… Oh ok.. Dave arrived on Tuesday.. so we met with some friends..and we enjoyed Casino night by Rally and Reception by Version One. After that some of us had an awesome time playing dice but not cheating…




When it comes to 3rd day.. I really felt the pressure of our presentation to be done on Thursday.. and most the time I spent thinking of it and getting some points organised..talking with Dave about it... which I will explain in my next post.. Afterall this is my very first time at an Agile conference.. which made me little nervous.. but all the awsome people around me were so supportive to keep me going without getting exited..

Agile 2010 - Part 2

Selecting which session to go after lunch was much more challenging... Many known industry experts such as Martin Fowler, Mike Cohn, Johanna Rothman, Alistair Cockburn, Robot Martin and many others had parallel sessions from 1.30 PM to 5 PM.
You can view the schedule here

Ok .. I selected to go to Agile Estimating & Planning: From Basics to Brain Stumpers by Mike Cohn because agile estimation and planning is never a “Done” topic and still challenging.
Now let me dig my memory a bit…
I can remember that I enjoyed the session a lot.. Audience involvement was so much that I thought he will run out of time to finish his presentation ( I expected it to be.. Because all of us who are in to agile estimation have our own share of confusion :) )
Many practical problems were discussed in the session.. Some stuff I remember even after 2 weeks are as follows;

- Talking about working with larger backlogs and estimating them upfront…
One of the ideas I picked at the session was that if the product is large, don’t go in to the entire user story capturing at once. First identify themes, epics and come up with a budget for the project. Not estimation. Because unless you are the “god of estimation” you will never come up with a right figure for any software project at this time.
Working with fixed price contracts was also discussed up to an extent, but not in detailed level.. still signing the contract with a budget of Min to Max would be a very good idea if you can get your customer understanding the same reality about software development as you are.
Once I noticed Mike was surprised that one attendee was mentioning about his huge backlog where they have realized user stories to be implemented for over a quarter of the year

- Estimation is not a commitment
I agree with his example to prove that estimation is not a commitment. You need to estimate. and you need to commit.. but its 2 different things and you don’t commit to the estimate. Still if you explain this to your manager or customer.. I want to know how long you have to find the next job……:-).. Anyway this is a lengthy explanation to do on how it works.. you can find some good explanation here.

- Estimating stories without hours
He went in to detail with the audience about estimating user stories only with story points without getting in to hours. Then he explained how to arrive at calendar estimation based on the average team velocity calculation.
There he got the question which anyone could foresee coming… How do you do this with new teams or new team members in a team.,. His answer was that in a situation like this you need few practice sprints to arrive in such facts.
I see a problem in this when we don’t have the same team continuing projects for a longer time.



In the evening we had the Ice breaking party again a network session provided by the conference. There I got involved over a discussion with some of the CSTS from Argentina, USA, Canada and Belgium. They had some discussions about how they think about agile alliance and their practical issues.

Agile 2010 – Part 1

Im Just thinking back 2 weeks, to refresh my memory in order to write something about Agile 2010. The longest waiting post in my blog so far:-) As I said before.. Lots of memories and lot to write about..Top of that, all my colleagues accuse me for being so silent about the whole experience.:-). So I will try to summarize my thoughts in very short form here. Im sorry that I have no much pictures to share.. But if you need any pictures.., here is the link for you

And I see few pics here too

Conference was very well organized I think. Organizing 15+ Stages is no simple task. I like the casual environment they created, very good networking with all the people around the world ( Mostly USA ;-) ) and almost every person I met there was passionate, knowledgeable, so friendly and so down to earth.. Needless to say that Ive made lots of new friends who are willing to share their ideas about agile software development and challenge each other’s thinking.

Starting from the beginning.. It was quite a long long long flight to me as I traveled all the way from Sri Lanka.. ( Am I the only Sri Lankan who was in the conference?? I think so…) I reached Orlando by Saturday midnight..dead tired.. But still got up early on Sunday morning… looked outside…Here my Beautiful view from the room at Disney Dolphin resort… Sure I was back in my full energy in no delays..


Thanks to my friend Caryl, I spent the day with her and her mom by going around and doing some shopping in Orlando on Sunday..I was so late to arrive back in the hotel. so I missed the “Dinner with a Stranger” event organized to facilitate networking among attendees. But it was an unbelievable experience to meet many people in real world whom I have been interacting online for a long time.

Monday was the first day.. It was hard to decide which lecture I should attend to as almost all the lined up parallel lectures sounded interesting. So for the morning session, I selected to go to Mary Poppendieck’s lecture on “Making Change Happen and Making it Stick”

I selected this session due to 2 reasons
1. Of-course she is a well known speaker and that was my idea for a while to see her presenting
2. At Exilesoft we have done the big change.. We have changed the whole project organization to agile. Now its time to learn how we stick with the change.

This is an informative post written by one of the attendees about her lecture. So I think I shouldn’t try to write about the whole lecture here. ( Im not that disciplined person who makes any notes.still I try to listen during the sessions. :-)

Just to summarize my own thoughts about the lecture;

- It was not tiring at all to listen to her for 3 hours - She took lots of real examples from many corporate which really helped to relate her theories in real world
- She stressed the point, for corporate to be more successful for getting the maximum productivity out of employees is by treating employees as volunteers. There she had many examples from Opensource community and how that works. We had a small exercise with each group members discussing about our own experience about an assignment where we worked as volunteers and led volunteers.. however there were some contradicting thoughts among the team members;
o – When people volunteer they have more personal agendas than when they work for a fee and its sometimes more painful to manage – Some examples were taken from some of the team members local PMI chapter work
o - This theory depends on the context and some of the asian cultures where the “Pay” and “title” define your social status will find it difficult to implement
o - Will the corporate management will act with the attitude of “Sharing the pain” with teams who are volunteering and working so hard while management act differently to them.
o - However all agreed that they have contributed to the best when they have volunteered to something in the past.

- She mentioned that there is nothing called a project is technically successful.. If project has no business success, its not a successful project at all. All geeks.. listen well.. This is very true !!!! –
- Further she mentioned the importance of teams making decisions.. she mentioned that there can be mistakes of teams when they make decisions.. but in long term those mistakes are better than the huge problems which can be created by the decisions made by management without knowing exact details as much as teams do.. she said it best !



Oh Boy.. Mid of the day.. I was sooo tired and never been so badly Jet-lagged before..
Lessons learned: if the event is in USA – reach there at least 3 days before.

Sorry for the delay..

Im sure you all wonder why I didn’t write anything about Agile 2010 yet. Ok let me explain.. About Agile 2010..I don’t know where to start and where to end it .. Sometimes I can think of writing a post about each lecture I attended to. Or something only about our session there...But at the same time its going to be lots of writing.. So for now.. let me write something.., I got to write something this week.. Otherwise it will never happen as the next quarter is really getting hectic.
We have 2 “Agile in Offshore” events planned in Stavanger and Oslo in September.. .. then I may miss presenting at PMI SAARC conference.. That’s overlapping with my Oslo visit.. then I will do P2P 2010 Cairo most probably in December.. So that’s more than enough for this year I suppose.. Yeah all these top of our day to day work on business development and projects.. So no need to explain how hectic the life is .. But I enjoy every bit of work we do.

PMICC Magazine - request for articles.

PMI CC wishes to announce that four ‘quarterly magazine’ are to be published from the chapter each year. The first publication, Q3 2010, is expected to be launched during the PM SAARC Conference that is being held in Colombo during September this year.

The scope of the magazine will be the delivery of content rich articles and real-life stories about Project management in all disciplines from the PM community to the PM community in Sri Lanka. While the initial efforts are targeted purely at widening our user base to encompass other industries, the goal is also, to provide PMP’s with opportunities for PDU accumulation and critically evaluating the projects they run and sharing it, if it can be shared, with a wider audience.

PMI CC requests all recommended articles to be submitted to the editor@pmicolombo.org.

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 12^th 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.

Where you mostly go wrong with SCRUM

By seen over few years for teams practicing SCRUM in various projects, I’ve noticed few common mistakes some teams do. I thought to spend few minutes to make a quick post; because they may help you too.

1. Too quick in Product Backlog planning
Seen this problem over and over again. In some of the projects you need few rounds of PB pre planning, be ready with stories, wire frames, UI flows , sometimes even the domain models. But there are many times those Product owners and teams rush in to PB estimates without having what’s needed to have.

2. No common understanding about the meaning of “Story points”
What does the story points really mean to you and your team members? ask each member of your team individually and you will be surprised.

3. Talking vertical, Thinking horizontal
This is very common with people who fall from waterfall to agile. Define a sprint called 0 and do all design upfront?

4. No release plan
Where is your release plan to the customer? Do you do a release after 1 sprint? 2 sprints? How many scrum teams do upfront release planning I wonder…

5. Sprints in different time durations.
If you have 10 days sprints.. go for 10 days sprints.. I cant still understand when I hear teams telling last sprint we had for 10 days.. but this sprint we will do 30 days.. then how do you ever calculate the velocity of your team and predictions for future sprint burn rates? This is why I need a release plan separately.

6. Getting wires mixed up about what testing means in agile teams
Ive seen this situation.. can you ever think of a scrum team where developers stop work and wait till the tester test their software within the sprint..? if you have more testing time, the team should do testing instead waiting.

7. No feedback taken after the customer testing those iterative releases.
You keep on releasing.. But if there is no one in the other end, who will test your iterative working software releases and give you a feedback, then there is no meaning to the iterative releases.. because you are anyway not too sure whether you comply with your customer requirements or still developing your own fantasies.

8. Scrum master role
Google and learn..

9. Misreading the burn -down..
What does burn down really mean to you? Take a good look at it.. again ask the question from all your team members.

10. Not using the Engineering principles to align development with SCRUM
Engineering has evolved a long way to adapt to agile way of developing applications, many test tools, code quality tools, tools which helps continuous integrations and lots of wiki tools are out there. Do you take the real use of them?

PMI Colombo Chapter - May 2010 Event

Agile in Offshore- Oslo gathering (Meet-up)

It was on 20th April (Last week) at Scotsman pub, Oslo. I was so happy to be there. It was not a typical business people discussion.. It was all about meeting other agile practitioners who use agile in Outsource/Offshore context and sharing ideas, challenges in such context as an open space discussion ( Though there was no much space as the room got filled in no time). Hosting this meet-up group was a new experience to all of us at Exilesoft

The event started around 5 pm with more or less 25 participants who really experience agile way of working in their day to day offshore projects. The best of all is that there were onshore members dealing with their offshore teams in Romania, Spain, Russia, Ukraine, India and much other offshoring destinations. We were the only offshore company who was there specially to share our ideas from offshore perspectives with onshore practitioners. I think it helped onshore team members to rethink about the issues in a different angle.

Finn, the host of the group started the event by explaining the objective of “ Agile in Offshore” meet up group, and some insights to Exilesoft. I had to play more or less a facilitator/moderator role to keep the discussions going..To have a kick start, I used a real case study to explain why we moved to agile way of working in offshore projects by leaving heavy processes aside.. When finishing 2 slides.., here comes Pizza. It was kind a treat after a long workday as we all were hungry.. :-)


I started the discussions with few prioritized issues we face in offshore projects when using agile, the very first was the challenges when it comes to project initiation with an onshore customer who is not in to agile. In the same time if the onshore customer is in to agile and not the offshore team, how this conversion happens when you are not too sure that other foreign company, it's culture and management structure is ready for agile ..? I soon opened the discussions to the audience as I couldn’t wait anymore standing in front without grabbing a Pizza for myself.. ;-).

That was a cool debate.. When we felt we have discussed a point to an extend, in agreement we moved to the next point.. Likewise we discussed and debated about many concerns from onshore as well as from offshore perspective such as the challenges in highly integrated scrum models, Scrum master role in integrated teams, Isolated scrum team models, Product owner and use of Proxies , how effective is the use of offshore PO proxies, culture issues , language issues when it comes to casual communication, the extend of actual usage of the collaborative tools in such context etc.

It was very nice that 3 other Exile colleagues Buddhima, Shiran and Adipa who were in Oslo also joined the event, they were good contributors to various practical issues we discussed on engineering , and source controlling in distributed environments.

Ofcourse the event was time boxed. :-) In 2 hours we had to end the event, Still we received lots of comments from some of the participants who waited little longer. It was a great experience and there were many requests to continue this group. Currently there are 61 members there, so that now we put our thoughts together on how to progress with the group with some new ideas for the upcoming events.