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.

Do you like plain Vanilla SCRUM or Flavored :) ??

This cartoon by Mike Vidoz made me write this post. ( Im a fan of his SCRUM toons :)-But I wish if he has new cartoons coming up more often ;-) ) And if you want to know which SCRUM I like, I like strawberry toping SCRUM. :) yummieee..

Plain Vanilla SCRUM is the SCRUM we all learned.. Simple, Nice, appetizing.. and I loved it more than anything I have ever learned about project management due to its simplicity and the way of getting away from Micro Management and Command and control management which sucks in my words. I think that’s why most skilled people got really attracted to SCRUM.
However when we put it in to practice, we learned a lot. SCRUM as it is … Is it enough? No I don’t think so. Mainly because SCRUM is only a PM framework , still even with some missing pieces , It address the fact that how teams should work in order to deliver results more effectively by cutting many unwanted stuff on the way. But when you do it in practice, you need to think about agile project initiation, Risk handing (SCRUM reduces project risks to a greater degree..but it’s hard to believe that SCRUM itself reduces all the risks involved in a project), transparency to higher management who is responsible at last to the customer and specially about addressing the engineering principles needed to be taken from XP or from any other agile method.
Recently I saw a good blog post written by Jesse Frewel in his blog about complains on initial version of SCRUM and the modifications which have happened. I see may people in the industry add many features to SCRUM after they start practicing it for a while.

I read another awesome article by Martin Fowler and he wrote about “Semantic Diffusion” happening to agile, He has a bliki and not a wiki .. You can find it here.. http://martinfowler.com/bliki/SemanticDiffusion.html Its worth reading.. !

Only thing what you got to be careful is, no matter whatever the customization you do or add new things to SCRUM framework , you got to understand that the key is not losing the agile concepts. If your new flavors added to Plain Vanilla SCRUM kills the agile concepts, then it will not deliver the expected value of practicing SCRUM. So be careful when you add things over it .. Make sure it gives you the right flavor :)

Help me : Bugs per 1000 line of code .. Agile dev aproach vs Traditional development aproach ??

I have come across some papers for same projects done based on traditional approach and Agile approach, which proves that Agile approaches have delivered significant better results. Some are from Starlabs SCRUM papers.

Im in the process of customising an Agile framework and curious about following.

Have you come across in any comparisons that the bugs per lines of code based on traditional software development vs agile development especially when test focused and test driven approaches are used. ?
Yeah I understand the complexity of the comparison based on iterative deliveries, but what Im looking at is the accumulated picture over the iterative deliveries throughout the project compared to the test results of the same project which is done with traditional approaches.
What I need to know is whether there is a significant difference in test results as we see many points that it should be..
Appreciate your help on this ..!

PS. thank you so much Buddhima sending me this
http://video.google.com/videoplay?docid=-3054974855576235846&hl=en#

Its great. Thats About google techtalks - Agile testing.. I enjoy that so much..!

Offshore Project management - Interview with Dave Prior

Click to play

Do we blame SCRUM for that too :).?

Scrum Is a project Management Framework. That’s why it doesn’t talk about any technical disciplines or engineering principles. Look at other widely used methodologies for project management such as PMBOK, PRINCE2 or even KANBAN; they don’t talk about any engineering principles either,
But Ive not heard anyone blaming PMBOK because it doesn’t talk about technical practice in software. May be its so clear that PMBOK is meant to use for project management across industries.
But how about scrum then?. I think compared to PMBOK and some other PM methodologies; SCRUM is very less prescriptive and highly adaptive. Due to this simplicity there were so much of confusion in the industry from day one about SCRUM especially from the people who misunderstood RUP as a Project Management process and people who used XP over time with its own technical guidelines.
Just like PMBOK doesn’t tell you not to do automate testing or not to do Pair programming, or domain model design, SCRUM doesn’t stop you doing any of these things. Especially if you are in iterative shippable product increments, using automated testing makes the whole testing tasks more effective.
So it’s quite clear that you need to adapt to your engineering best practices when you use scrum just like when you use PMBOK. But the difference here is that if your engineering principles which you try to adopt to, kill the agile values, you will be having a label of SCRUM but you will never get the real value of SCRUM.
So its important to adopt with simply, “doing everything every time” by revisiting your high level design diagrams etc at every sprint planning. Especially when it comes to larger number of small teams working on same product, you really need to get your act together on how you adopt with proper engineering principles and ownership of them but still doing it “Agile”.
Another mostly misunderstood area is documentation. It’s because Scrum says to be focused on software delivery. If we develop software, our delivery is software, not any other artifacts. Those artifacts should help building software but not a focused delivery under normal circumstances.
But if you have read Mike Cohn’s user stories applied book (really good book), you can find the answer to your problem. If the CEO thinks you need to provide such documentation to protect your IP value of the product, then you can add the main user as the CEO and write the complete user story on what sort of documentation he wants and what is the expectation out of it . so you have tasks in your sprint related to the documentation user story.. Its all about doing what is wanted and not wasting..
The bottom line is that no method is god given or no method is evil. So its all about using your experience and common sence to make something which works in your context.

Risk Management – where it fits in Scrum?

This is about Risk. There are visible and invisible risks in any software project and those risks may appear any time during the project life. PMBOK has a separate knowledge area on risk management. YES it’s that important!
So ..Then why most the SCRUM practitioners are so silent about risk management ( Ok we Agilists think the word “management” is evil ;-) So I will use the word “risk handling”). I think risk handling is one of the most unspoken areas in agile processes.

To me, handling risks of projects and bringing it to visibility of the stakeholders is very important.. Yes..early as much as possible…. If I have 7 Scrum projects happening at this time at Exilesoft, being the Project Director, how do I get this visibility of the risks of all the projects? One challenge of running many scrum projects in my context is that most the time the project knowledge lies within the teams and the POs..But still there can be areas which higher management needs active involvement to avoid various risks and mitigate them. So visibility of this information is still important to the project organization of the company.

I was thinking a way to bring the risks handling in to practice in scrum projects more effectively.. But still not hurting the agile principles and concepts.

I just went back to my pre-Agile age to see how we handled project risks. In the planning stage, we had a risks plan, initially, we used to foresee many risks as much as possible, we had a fairly complicated template defined by the PMO, the project manager mainly listed all the risks (of course it was PMs responsibility) and then he discussed with the team and other stakeholders ( I suppose I did ;-) ) and assigned a figure for the impact and probability. Then we calculated the severity based on the calculation impact * probability. Thereafter we assigned a risk owner to each risk, and the response options, either we are to mitigate it, if mitigate the mitigation plan, Risk deferral, or agreed to transfer risks or accept or avoid.
After doing all these, we were so happy that we had a nice risk plan for the project, sent to all the stakeholders and then some times we forgot about those risks plans when project was too hectic towards deadlines.. or sometimes being PMs we had unique effort on risks controlling and monitoring process. However it was always the Project manager’s baby and if he didn’t foresee the risks of the project, his job was at a risk. :)

Ok.. Now I have a different situation. How do I do this risk handling in Scrum projects? Who takes the responsibility of such risks handling of scrum projects? How do I get this visibility of all the risks happening in my company projects easily?

I don’t want each team scrum masters to create risks plans and get them updated and email to me, to my CEO and other stakeholders every time. Because I know it will never get the attention which it’s needed and there will be lots of “I wish this stuff is deleted” areas in those reports. Further, that will add lots unproductive stuff in to working software focused production which we may not want to have. Top of that how can the scrum master be responsible to foresee all the risks which may happen in the project.. he is just a human being.. shouldn’t there be a collective effort and responsibility ?

So how do we do this better? I thought of this solution.. Im going to tryout and see whether this will really help us. I think so ..

In scrum, we need the ideas of whole team and we need them to think , work together and have the same commitment and ownership. So why not those all getting involved in handling and reporting risks to each other in more visible way? Not only them identifying and reporting the risks, they need to be actively involved in responding to these risks too. Let’s make it an effective process.

Remember the sprint dashboards with sticky notes..That makes your sprint tasks and progress visible to everyone. Even to an outsider who just walks in to your development room.

I thought of giving each team 3 colors of sticky notes sets Red, Amber and Green. Each project team gets a small white board on the wall. Whenever a team member see something as a risk in his project, he needs to write it in either Red ( he thinks that’s serious and need some immediate attention) or Amber ( Not that serious) or any positive risks in Green ( not compulsory) and he paste it on the risk board under the New risks column. They can be technology risks, requirement risks, risks with commitments, or anything…) this risks board will have 4 columns

So I’m sure one problem is already solved.. When I walk in to the development area, I can see the risks notes in all projects and we can see definitely the red ones needed attention. So its important for me to have some discussions with teams about these red notes or amber notes.
How do we use them?
I think each sticky note can have a space in the bottom left corner for the impact and the right corner for the probability. The team can rate the impact and the probability of each sticky note.

In each sprint planning meeting, its needed to take these foreseen risks to discussion with the product owner, prioritize them, if they need any mitigation plans to add them as product backlog items, prioritize them based on severity, taken in to sprints and address them.

Ex: One of the developers (Tom) seen a risk. He thinks using control X may affect the end product performance and users will not agree to use that product feature.
According to Tom, it’s a serious risk so he will not wait for few days to inform this risk to the team, because with time he knows that he may forget this with his other priorities. Therefore, he will write this risk in a Red color sticky note , paste it on the risk board under new risks and he will get going with his committed work.
Next day after the daily scrum the team and the scrum master notice there is a new sticky note on the board, they will rate the sticky note for impact and probability.
In the next sprint planning meeting , they meet the product owner , so ideal time for them to discuss about these newly seen risks with him as he has the total ownership of the product.
Product owner agrees that this is a serious risk and he will have a new backlog item about the performance of the product feature, he prioritize it in highest priority as it may affect the other areas too in the product. So the team will address it in the immediate sprint and implement some caching mechanism to mitigate the performance risk.

This is only one example. Likewise there will be risks which they will have to discuss with the product owner, their own management or even only with the team .
When they are working on certain risks notes they can move them to the in progress column and when mitigated they can move them to the responded column. If the team and the PO decide accept them and not to do anything about that or ignore them completely due to lesser impact, they can move the notes to the 4th column.

In this way I can see lots of benefits which will bring to all of us;

1. Visibility and awareness of project risks seen in all our projects in much simpler way
2. No documentations and complicated templates which will save our time
3. All the team members will share the responsibility of Risk handling process
4. Risks items will be discussed and addressed with no delays and without any missing items.