PROJECTIZED

Lean Coffee.

2011-12-13T18:30:00.008-07:00

I first experienced Lean Coffee at Oredev 2011 in Malmo. I was introduced to Lean coffee by Jim Benson (Author of the famous book – Personal KANBAN). One morning we had Lean Coffee with some awesome bunch of people including Jim, Marcus Hammarberg and Joakim Sunden. My bad I forget many other names. ☺

Thinking back, I wonder what really motivated me to participate this lean coffee session at 7.30 in the morning? I had no obligation to do this.
I can think of 3 reasons;
1. I was curious about it and wanted to learn what lean coffee means.
2. No one pushed me to do so (therefore I couldn’t make the excuse “oh that’s way too early ☺” )
3. People around me inspired me; I knew I could have had a good discussion with some knowledgeable people I met there.

But I didn’t have an agenda sent to me. What are they going to do in this lean coffee meeting? The interesting thing is, because I didn’t have an agenda I couldn’t find the items which I think are boring to me, or I couldn’t find faults with the agenda. :). I couldn’t set my expectations out of this meeting in advance either.. Hmm… Interesting.. definitely I wanted to see what this was all about.

The Technique was very simple. We make a usual KABNAN chart and keep it on the coffee table. As usual this has 3 columns, Stack, WIP, Done. We had loads of sticky notes and coffee too. This was a very causal gathering and the whole set up made everyone feel free and comfortable.

Jim became the facilitator; he asked all of us to write something what we wanted to talk about in a sticky note. We all did so within 2-3 mins. Then we pasted our sticky notes to the stack column on the KANBAN sheet. ( Remember 1 note for 1 topic)

It was the time to vote. He asked each of us to vote 2 notes in the stack. (What we tried to achieve here is the democracy, we got to talk about whats useful to the majority not to a single person. At the same time, by considering the votes we could find the topics, which most the people can talk about freely. We voted for a particular topic because not only we can learn about them, but because we loved to talk about them too.)

Once voted, the facilitator moved the most voted 3 stickies to the WIP column (WIP is limited and the work flow is visible). It was time to start talking about them.

First note: The person who wrote the note described what he meant about it. Then someone else in the group started talking about that and added his idea to the topic, once he finished another person in the group added his 2 cents. Likewise we all talked about the topic we picked,. I saw lots of insights and great ideas adding to the discussion. We didn’t talk cos we had to defend our poker card or because it was mandatory to talk. We talked about the topic and added our thinking because we found the discussion was helpful and inspiring.

One person in the group noted that we have been discussing about the first topic almost for 3o mins. So the facilitator asked whether we want to continue or to stop it or whether we don’t care if its continued or stopped. Most the people signed that they want to stop the topic now and move to next one. So likewise we managed to discuss 2 topics we voted before finishing the lean coffee in order to attend to the conference sessions.

This was very simple, but the level of energy flowing through the meeting amazed me. I was surprised about the amount of information we managed to dig during such a short time about those 2 topics we discussed. I didn’t have agendas or expectations set in advanced, but I felt its time well spent with some knowledgeable passionate people.

I got to know that there are good lean coffee sessions happening among Lean enthusiastic people in Seattle, Sydney and many other cities…

Here you can find about Seattle Lean Coffee sessions:
http://seattle.leancoffee.org/

After Oredev 2011

2011-11-13T08:08:00.009-07:00

Now in Stockholm, 2 AM in the morning, still jetlagged, thanks to hotel wifi and my MacBook I don’t feel lonely to death :)

Last week was so technicolor and surrounded by hundreds of geeks and freaks. Pieces of memories are still buzzing in my head, Oredev is one of the best conferences Ive ever been to. You will understand what Im talking about if you just check twitter for #Oredev

I reached Malmo on Monday, as usual another 20 hours long trip from Sri Lanka.

1^st day was so boring to me, I didn’t know anyone around.. in fact no one was around to see :). I was not in mood to go to Sauna event or to the dinner at night. So as usual I did my favorite task in Scandinavia.. that’s “sleeping for 13 hours”

When I went to have my breakfast on Tuesday morning, I saw some of the speakers there, So I fell in to conversation with @testertested, @arungupta from Oracle and few others. We had a brief discussion about our markets in general.

A short introduction to Malmo was good for any 1^st time visitor. I met few other speakers and the week stared to happen from there.

The speaker dinner was glamorous, wish if I had a camera with me, but I found this video done by @yfrog. see that here. http://yfrog.com/0nlhobz. This beautiful place is a 500 years old building as explained by the Mayor of Malmo. In this video Im next to @ourfounder and covered to some people J

On Wednesday, the conference started officially. I enjoyed the keynote by Alexis Ohanian ( “only your mom visit your website”) the co-founder of reddit. It was an awsome speech by such a young professional with loads of humor, the passion he has in him is unbelievable.

I attended three sessions on Wednesday: the presentations by Jean Tabaka at Rally Software, Patrick Kua at thoughtworks and Potia Tung. I enjoyed pairing exercise by Doc (@athought) a lot.

I was to go to dinner with a group of speakers that day night, but I was bit pressured with my talk to be done on the next day, as well as Peter (from Exilesoft Sweden) had a lot to catch-up with me. So I decided not to go out at night.

During the morning hours on Thursday, I spent time for preparing my talk. After lunch I attended to Jean Tabaka’s another session “Golden circle” where she presented many slides about agile adoption @ Cochlear Australia. She used pictures of @rrottier and his colleague’s speech at agile conference in Australia.

The session before mine was done by Jeff Patton and he discussed many interesting points about todays fake agile practices.

Here comes my turn….. Im in the stage, in front of a room full of audience.. I remembered to breath as I thought that will take my breath away, then I started to have all the fun as I never thought before…

My session was focused on team collaboration in distributed environment; I made it a point to be focused on my experience with Scandinavian context with distributed teams in Sri Lanka. (This is my day to day life at Exilesoft), so I think the audience managed to relate it with their experience better and I managed to be so relaxed in the stage as never before. I structured my presentation based following 5 aspects;

1. Talent distribution is the number one reason to use distributed teams.

2. Arguments about complexities based on geographical zones are subjective to their own experiences.

3. Agile adoption and feature teams in highly integrated environments help to avoid most the traditional issue in the context, but introduce some new challenges.

4. There are good people everywhere, if we have the right way and attitude to work with them, they will work if not they cannot.

5. Faking agile is the worst thing one can do when dealing with distributed teams; it adds loads of confusion to all the parties.

I used a case study to model distributed teams in various ways such as component teams, knowledge teams and feature teams. ( 2 min is given to the audience to think through their solutions too). Then I spoke about few other aspects such as project initiation when using distributed teams, culture aspect, high expectations of commonsense, employee retention issues when the work is not interested and the relationships become sour, Layers of trust and the danger of building trust based on the facts which doesn’t exists (OP: check the code by yourself) and importance of collocation and AAR.

I shouldn’t have stopped talking, but the coordinator signaled me and said that there is only 5 min left. So I had to stop there. J

I like the feedback I got and the questions thrown to me. Im so happy to see one of the tweet about my talk on the twitter canvas by @imagethink.

Thanks to Oredev for donating money to children in Africa behalf of me talking at Oredev. As per most the speakers, this is the best thing you guys did.

Friday Morning lean coffee was really interesting. I think this is something I need to try out with my colleagues at Exilesoft.

I liked the Healthy projects by Jim ( @outfounder : the author of personal KANBAN and many other books) and Dan’s(@tastapod) session about patterns was really interesting, I couldn’t stop laughing throughout his session. I didn’t like the fact I missed his keynote.

I enjoyed the closing keynote by Amber Case about the future of interfaces.

Friday night we had a good dinner and so much fun with some of the speakers. Saying goodbyes were really hard.

My overall takeaway points from the sessions I participated:

1. Its time to think towards user experiences and interactions in new ways, or we will be obsolete with our products.

2. BDD and agile testing: lot more to learn.

3. Rally software organization wide agile adoption, Need to think through how we can relate with it.

4. Future of scrum seems to be blur. Software professionals have started to hate scrum due to organizations adopting to rules of scrum but not the real agile values.. values without scrum has become a pain to most the people. Everyone sounded very enthusiastic about KANBAN as it promotes agile/lean values within itself.

5. Most the Scandinavian IT professionals are very passionate about what they do and they read a lot. This is what we need to encourage within our offshore teams to make them good teammates with each other.

My thoughts on PMI agile ( PMI-ACP )

2011-08-20T12:31:00.014-06:00

When I first heard of PMI agile, I was really skeptical about it. I never thought I would explore it. My initial thought was, how much agile PMI can be?.. I’m sure I’m not alone; there are many others who thought the same, or may be still thinking the same.

When Dave discussed with me about the upcoming ACP+ CSM class we were to teach together in NY, was the first time I got any interest to walk through the PMI agile course content. When I read the content, I was impressed. They have thought of so many aspects to agile engineering and agile in general.

About the Exam:

As usual, Tools and Techniques cover 50% of the exam. These tools and Techniques are divided in to10 different knowledge areas. Rest of the 50% is allocated for the candidate’s knowledge and skills in agile project context, covering 3 levels based on importance.

When I read the content in detail, I can see that it covers lots of stuff, which we should know when we do agile engineering. It talks about many practical aspects including agile modeling, story mapping, estimation techniques and even EVM and ROI calculations in agile context. It’s pretty detail. these materials are available at PMI site.

However, these are my concerns;

1 . In a CSM class, No one can fail the assessment, so the class is not conducted to aim for grades but to learn the concepts. I know almost all CSTs are very keen on transferring basic agile concepts to their students. But looking at the nature of PMI exams, if PMI agile learning hours focuses on teaching tools and techniques to the candidates to score pass marks, then the whole concept of agile will be lost. In that case, how many ACPs will be truly passionate about agile will be a question. In the worst-case scenario, they will be learning to pass the exam but not to practice agile. This has a greater risk in South Asia where there is a highly certification-focused culture.

2. Who is going to conduct these classes? There are only very few CSTs available, so I’m sure PMI will allow PMP trainers to do PMI agile courses ( may be Im wrong, Im not very clear about the eligibility criteria yet), but some of the PMP trainers may haven't really experienced agile or seen the value of agile to teach agile. If they are going to read a book and teach agile without any practical experience that’s going to be a disaster.

3. How rigid the exam questions can be in an agile exam? That’s another aspect to think through when preparing ACP examination questions. Examiners may need to bring up more concepts in to test rather than the theory, which can be learned by reading the course content.

Of course there are prerequisites to take up the ACP exam. This requires sufficient work experience in doing agile projects. I only wish the candidates will follow the protocols instead using workarounds to complete the eligibility criteria.

During last 2 weeks, I met many people who talked about PMI agile. They all had their own opinions about PMI going agile. Following are some of the points I gathered from these small talks:)

Positive points;

1. Many agreed that It’s a good move. PMI is known by every part of the world, but agile alliance is not so big as yet outside USA. Therefore this is a good move to bring agile in to a vast community.

2. Some said that they would never consider doing anything with PMI if not ACP

3. Many agreed that collaborating with PMI, Agile alliance would achieve its vision by changing the way that people work.

4. Some of the PMI folks also mentioned that it’s a good move at the right time. Many large enterprises are moving towards agile, if PMI doesn’t collaborate, it could have been much more difficult for them.

5. I heard some comments from real enterprise project managers that their techies get in to agile and talk more about agile nowadays, so ACP will help them to bridge the gap.

Negative thoughts were;

Some saw ACP as mainly a money making effort by Just introducing another certification while some agile folks thought that ACP may kill the whole concept of agile and there will be a hardcore new agile group to come up soon.

My personal view is, that PMI getting in to agile is a good move., specially when it comes to enterprise level, it will add loads of value, but that all depends how PMI may execute this courses/Exams and its yet to be found-out. I see a good trend towards ACP already; there will be lots of registered candidates for the exams starting from next month onward. I may do the same.
****

However, I really enjoyed doing our CSM/PMI Agile class in NY with Dave and some really cool 19 participants (most are PMPs) from various industries. Co-Training with an experienced CST was an amazing opportunity to improve my training skills. It was an exhausting exercise to cover-up most the stuff in 3 days. But we had lots of learning and fun. (Thanks to them for criticizing my white board skills so badly, every time I go in-front of the white board I remember you guys :) I really enjoy this group's enthusiasm on agile after taking this class, this group even started a new LinkedIn group to discuss matters among peers. I think they got the concept right; agile is all about sharing, learning and adapting.

Graffiti by Geeks

2011-08-19T06:22:00.006-06:00

This is taken from Exilesoft Lunch room. How creative our geeks can be? .. they can scribble when ever they want to..Paint buckets are placed there for them.. I love this office... But I wish none of you will spot my spot on this wall.. :) Do you think this is a good stress relief activity ?

Agile 2011 – Salt Lake City

2011-08-16T18:11:00.004-06:00

Back from agile 2o11, long flight back home and still I cannot sleep. I think I’m seriously jet lagged or tired. So I thought to write a small note on what I’ve experienced.
I like the venue, the hotel Grand America and Little America. It’s an extremely nice place. Salt Lake City was a very nice place to cruise around after the sessions with lots of local bars, restaurants and unforgettable local coffee places.

The conference organizers mentioned that there were 1600 attendees from 48 countries around the world this year. Of course it’s huge. Organizing a conference in this scale could have been really hard work.

Talking about the main part, the sessions:
I honestly think the number of parallel sessions could have been lesser than what we had this year. In most the sessions I noticed that there were very minimal attendees, the rooms were empty. By reducing the sessions, they could maintain the quality of the sessions too. Still I know some may not agree with me, as there are more options and topics, attendees will have a better choice to make.
I enjoyed all most all the sessions I attended, there were quite lots of useful things to learn. Most sessions were very interactive. Looking at some of the sessions, I still feel its better if they try to go deeper in to the subject matters instead discussing the problems what everybody knows about, because the agile users have matured over the years. I felt this in some of the sessions such as performance appraisals and agile coaching. This is something that review committees should discuss next year.
Incremental budgeting was one of the sessions I really expected to turn out well.
As a general comment from attendees, what I heard was that the technical sessions delivered met the expectations of the attendees compared to the sessions of the management track. Still, agile contracts and agile decisions were some of the good ones that I attended in the management track.

My session this year was about KANBAN and use of it in the organizational facilitating functions such as HR department. Its an experience stage presentation, so most the work had to be done before the conference. The paper is published in IEEE and it’s included in the conference CD with loads of other conference papers. Actually there are pretty good papers I spotted in this CD, I need more time to read them.

One of the highlights this year was 10-year anniversary of the signing of the Agile Manifesto "Park Bench" event where most of the original signatories presented in one stage, answering the questions from the attendees. I think that was an inspiring moment to agile enthusiastic.

I enjoyed the round table discussion by agile thought leaders. Once again I got the opportunity to enjoy listening to Dave West, a speaker I admire the most. His true passion, natural style and humor makes him an awesome speaker (that’s my personal view anyway :) ) However thanks to the lady who asked the question about their new research areas, I heard a lot of new stuff which I need to Google and learn more. What excited me the most was to know that use of agile in operational management was one of the new research areas they do (they mentioned some acronym which I cannot remember) My experience report this time was related to that, may be I need to work more on the same paper and practice it for one more year to advance it to the next conference. I don’t know.. Its just a thought..
Out of all 3 key note speeches, I managed to listen to only one which is about psychology: positive thinking.

Conference party was quite a nice experience. I think most the attendees had lots of fun.

I heard there were some really cool sessions in open Jam, one of it has been to present a technique to learn foreign languages without using translations, I wish if I could be in the session, but thankful to my friend who taught me about the technique later. I wish if I could catch up Norwegian language a bit using the same technique.

Using the conference for marketing activities has tremendously increased from last year to this year. Sometimes some of the agile coaches overselling themselves were quite disturbing.

Anyway it was a great conference. This is where I really absorb energy by meeting lots of passionate and enthusiastic people. I really enjoy it. I heard that next year conference chair is Mitch Lacey, Im sure he will do a great job and I look forward to agile 2012 in Texas.

Agile Project Management (CSM / PMI Agile)

2011-06-30T10:48:00.000-06:00

This 3-day intensive workshop provides instructions on the key areas necessary to take on the role of leading or participating in teams utilizing Scrum and Agile. The session will cover the Scrum framework as defined by Scrum Alliance and include a review the material defined by the Project Management Institute’s PMI Agile Certification Examination Content Outline. The material will be presented through lecture, group discussion of case studies, and group exercises. Successful completion of this workshop will satisfy the requirements necessary to apply for Scrum Master Certification as well as the provide attendees with the Agile training hours required for the PMI Agile Certification Exam.

The course will be faciliated by Dave Prior, CST, PMP and Thushara Wijewardena, CSM, PMP

Participants who successfully complete this course will:

Understand the dynamics of the Scrum framework and how to make use of the practices necessary to realize the benefits of an Agile approach
Understand how to begin developing a plan to implement Scrum in their current work environment
Understand the differences between Agile and a traditional “waterfall” approach to leading projects
Understand the basic differences that are necessary in leadership style when managing projects using Scrum as opposed to a traditional approach
Understand the structure PMI has defined for their Agile Certification Exam
Understand key Tools and Techniques defined by PMI for their Agile Certification Exam
Understand the Knowledge and Skills defined by PMI for their Agile Certification Exam
Understand the Domains and Tasks defined by PMI for their Agile Certification Exam
Meet the requirements for Certified Scrum Master
Meet the training requirements for PMI Agile Certification

Lecture in Stockholm

2011-06-02T03:17:00.004-06:00

Just a short update ...

2011-03-06T09:33:00.001-07:00

I realized that its been a while and Ive not posted anything to the blog. Sorry for that, simply I was too tired to think or to write anything new due to many things happened lately.

After Exilesoft acquired Teamwork Technologies in Jan, the biggest challenge we’ve got is to merge 2 project offices with 2 different work cultures, project models and even new markets. Working towards building one agile project model across the new project office is interesting, still very much challenging. There are many aspects to it, such as

1. Change of thinking process

2. Time to build trust between each other in such merger( new colleagues and existing colleagues / with sales offices and new customers)

3. Effort involved in getting our new sales offices to buy in to agile models which were quite different to their existing sales model ( and doing it for the right reason, otherwise it will be really messy)

4. Level of agile maturity needed to be achieved by the staff and across the new organization.

5. Establishing agile Engineering practices across technical teams

......And many other.. More than anything..... the biggest challenge is to prove some clear benefit to techies, to the customers, to the management and to the sales offices of such transition. This will take lots of effort and time. Still I’m sure I will have stuff for a book when that’s achieved :)

I’m happy that we got a really good team working towards such exhausting, but interesting exercise for everyone.

Other than this extremely busy day today office life, there were few things I’ve been doing.. The paper I submitted to agile 2011 is now selected to present. Which is the biggest achievement of the year so far.. Ive got a very experienced “Shepherd” to help me with it (He works for MacAfee and expect to learn a lot from him) . Thanks to the stage producers for that.

I was planning to do PgMP this year .. still I couldn’t spend any quality time on that. So Im not too sure where I stand with it.

Further @mrsungo is working on some exciting stuff which I hope to participate in New York, on my way to Salt Lake city in August. That’s going to be an excellent experience to me.
So .. its all going good..Will post some interesting stuff soon ! :)

Lean concepts for the operations management - part 5 – HR KANBAN Board

2010-11-06T11:43:00.012-06:00

Let’s talk about the HR KANBAN board. I explained the user stories which will go to the stack in my previous post.

We all met on the 1^st day, in front of the HR office glass wall. We divided the wall in to 3 main columns as follows;

Stack

( Where we put whatever comes out as user stories related to our HR

To do

( The most prioritized stories)

WIP

(What we are working on)

Done

(The completed ones)

We made the following format for each of the sticky we use..

Here you can see some of us getting the stack prepared..

We pasted all the prepared user stories in the stack. Now we go to do the following

1.Prioritize them

Prioritization is important, due to 2 things.. There can be very important user stories but still we could wait some time before we act on them. As an example, we have decided to create a new appraisal process for employees which will support agile team concepts in the organization. That’s a very important user story, but still we can have some lead time to start it due to the current process in place for this year. Let’s look at another user story; issuing the new version of “onsite travel guide” to the staff was a very high priority story as we had some upcoming onsite visits planned in some projects. So we managed to prioritize the stories based on the urgency as well as the importance of them.

Here we go prioritizing them...

2. Split them as smaller stories if they are too big to move.

This was a challenge. Can you imagine that.. ? Look at the previous user story I explained.. If we say “we need a new appraisal process which supports agile team concepts” that’s a very big user story..It will be harder to move the user story across the board. So its needed to decompose it in to a smaller level stories at the time of moving to “To Do”

If you look at the tasks under this appraisal user story, you can make few more sticky notes such as;

1. Review the existing appraisal process so that we can have a good idea about how people are appraised currently.

2. Discuss with the staff and find the areas where they like to be changed so that we can get good insights from stakeholders who will be appraised by the process

3. HR manager needs to talk with the Project organization so that she can understand the gap between the current process and the new process requirements.

Likewise.. We faced some big user stories which had to be decomposed.. and some smaller user stories which doesn’t need to be decomposed.

3. To do and WIP

How do we do that? Interesting.. initially we tried to limit the To do to 10 and WIP to 6. Any logic in that? NO.. We wanted to avoid committing to too many things which we cannot deliver but still to have sufficient amount of work and urgent work needed to get going.. But still .. we have not mastered the limiting skills J I will observe this further.. (Inspect and adapt ;-) )

4. Understand that there are tasks which will not be in the KANBAN board

due to 2 reasons;

1. Those tasks are way too small and routine.. so you anyway attend to them

It’s important to understand where we will draw the line for the KANBAN board otherwise you may flood it with all the smaller things you have to do during the day.. the purpose of us is not that.

2. When it comes to HR. In reality, there will be few tasks where visibility of them will be challenging even at management level.

Initially I explained one of the major challenges in our operations is that as its recognized as internal work.Unlike in projects, some of the initiatives never get completed due to other prioritized commitments … or drag too long..I think thats a common problem in any organization. But now.. all these stories are so visible..what we need is to measure the cycle time..

In my next post I will explain the challenges, benefits and other observations we had of our KANBAN board when we were proceeding daily..

Next:

Previous:

Lean concepts for the operations management - part 1 – How did it start?

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 ?

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

2010-11-04T10:38:00.009-06:00

I think now I have come to the first part of the most important chapter of the story… How did we implement it.?
First of all I must mention that .. this whole thing is an experiment we do. (Didn’t you hear someone telling that “agile” is all about experimenting?)

Further, I have few emails asking questions about this whole implementation.. so I will try to be descriptive as much as I can.
I must admit that I usually get little carried away with concepts, especially when I start loving them a lot ;-) So when we were discussing our model, Finn (Our CEO) had to give me few reminders that it’s not about doing KANBAN, it’s about us being more lean and us making more productive management model. Sure! I agree.

Now… few challenges to face.. How do we get the operations management in to this thinking as they were not exposed to agile thinking before..?

To do that, we made a small presentation to the whole management team. We openly discussed about;
1. Our Vision to achieve
2. The importance of organization wide visibility of what we do
3. Why we need the whole management teams to move together, meet for daily standup
4. Focused areas which need improvements
5. Agile thinking which will give us drastic improvements, what our technical teams and customers achieved after being agile
6. How management can help each other across departments and work as one team.
7. Then we were open with the question.. do we go for this..?

The answer was.."idea sounds interesting.. Let’s try out and see.." We may face issues.. so lets start with one department first.. May be our Human Resource dept ....

That was encouraging.. So now what do we need ? We need a backlog.. Yeah I know how to make a product backlog.. But.. a HR backlog. ???. sounds weird.. Still we tried to come up with some sample stories to have a better idea..

Hmm.. Not bad.. the stories were flowing at no time.. Yeah we discuss what is "done" in each story..

Ex: what is done in 3rd user story?

We had a good understanding about our stories to be going to the stack (Backlog). Now we need to keep them prioritized. So We got some stickies, wrote them in the sticky notes, prioritized them and pasted on one wall of the HR area what we called the stack.

The glass wall had to have 4 sections as follows;
Stack | To Do | WIP | Done

I think this post is becoming way too long..:-) So I will continue the rest of it in a new post about the wall !

Next:

Lean concepts for the operations management - part 5 – HR KANBAN Board

Previous:

Lean concepts for the operations management - part 1 – How did it start?

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 3 – Looking at KANBAN

2010-11-03T10:31:00.017-06:00

Ok.. now you know what we need... we definitely need something more flexible..and something which works!.
Looking at KANBAN, we found that it aligns with our thinking in most the areas we are concerned about..

KANBAN allows us to ;

- Be more flexible

- We didn’t fix any sprint, plan days, time boxing or release days.. we wanted to plan everyday, discard plans we made yesterday, make new plans today, deliver all the time, allow most prioritized stories to flow in at any time. Unlike in SCRUM we cannot think of completing all stories what we have committed to do ( remaining story points = 0) in order to start a new set of commitments.

(Diagrams taken from www.versionone.com website)

·Be More lean

- We wanted to be lean.. and more lean.. That’s why we initiated this ..

· Monitor cycle time

- Yes we don’t want to estimate each of our management user story, Simply that doesn't make sense (I explained it in one of my previous posts)..Still we want to see when that’s raised, when its taken in to action, when it was in execution and when it was done, the total time period we spent to get it going.

· Limit the WIP

- I think I explained this before.. Every one of us had too much in our plates.. So some items were not moving out or at least not at the speed they should have been. Now that if we find a way to limit things based on our capacity, at-least we know we are not adding so much in to our workload unless we push some stuff we have already had.

· Have more visibility

- This is really interesting.. As a manager or a senior manager, how do you feel about this much of visibility of your responsibilities and visibility of your deliveries among your peers?
Amazingly that worked well with us.. as far as we all understood the benefit of this visibility of things we got to do across different departments/Sections. But I agree when it comes to areas such as HR, there are user stories which shouldn’t paste on the wall. In this case we have to be selective with what level of visibility is needed with certain stories. I usually don't like tools.. I prefer simple stickies on the walls. But in this case I understand a need of a good tool.

· Purge the backlog

- If there are many less priority stories not delivered over time, their value of delivering them will be reduced or those stories may not be valid anymore. So KANBAN will allow us to purge the backlog in every 3 months or so to clear out those items.

Next:

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

Previous:

Lean concepts for the operations management - part 1 – How did it start?

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

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

2010-10-16T11:17:00.007-06:00

Our first preference was to make a management tasks execution model based on Scrum... But definitely we have the following concerns when it comes to Scrum;

1. Time boxing and sprints doesn’t work

We cannot commit to a specific time box and deliver only the committed tasks. HR department is getting requests all the time, IT dept is getting work all the time.. There is no way they can say … wait for 10 days.. We have to finish the current sprint before we book your air ticket.. So we know time boxing cannot help much when it comes to operations tasks.

2. We need to deliver all the time

Services of operational functions needed all time deliveries.. not any scheduled releases in every 10 days or 3o days

3. Story point estimation doesn’t make much sense

Estimating the story of recruitment of a Software Engineer as point 20 or 2^nd story of addressing a leave issue as point 100 doesn’t make much sense.. relative estimation will be difficult as stories carry functions in different context

4. No finishing and re-starting.

In a sprint we burn all the tasks to 0 and then we commit to a different set of story points in the next sprint.. Simply it’s impossible in operational activities. Activities flow every day every moment..

5. Many teams getting involved in the flow.

We have many teams sometimes working on the same user story.. As an example when the recruitment happens.. we have engineering teams involved, HR, IT and many other ..

So then what should we do.. How about KANBAN..which is more lean…?

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

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

Previous :
Lean concepts for the operations management - part 1 – How did it start?

Lean concepts for the operations management - part 1

2010-10-16T10:55:00.007-06:00

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 !

2010-10-08T05:42:00.001-06:00

The agile bird !

2010-09-09T08:39:00.011-06:00

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

2010-09-03T21:35:00.013-06:00

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

2010-08-29T01:36:00.007-06:00

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

2010-08-28T23:51:00.005-06:00

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

2010-08-28T08:54:00.010-06:00

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

2010-08-18T06:05:00.001-06:00

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.

2010-08-02T08:52:00.001-06:00

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?

2010-07-27T22:11:00.014-06:00

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

2010-07-10T10:23:00.002-06:00

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

2010-05-15T22:56:00.001-06:00

Agile in Offshore- Oslo gathering (Meet-up)

2010-04-25T09:28:00.026-06:00

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 :) ??

2010-03-16T11:27:00.004-06:00

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 ??

2010-03-11T18:10:00.009-07:00

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

2010-03-01T01:21:00.008-07:00

Click to play

Do we blame SCRUM for that too :).?

2010-02-23T09:12:00.002-07:00

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?

2010-02-02T10:45:00.008-07:00

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.

Seasons Greetings from Projectized !!

2009-12-26T05:25:00.005-07:00

I wish a Happy and prosperous 2010 to all my readers and advertising sponsors. Thank you so much for your support during 2009. In 2010, I wish to have more knowledge sharing, Interesting discussions and more than anything else to link up with you more closely... no matter who you are or which part of the world you are from…

Offshore project management and use of Agile. – Part 2 – Tiers of Outsourcing

2009-12-06T11:18:00.006-07:00

The part 1 of this article has already received industry attention than I have expected. I’ve seen it has been referred in some discussions, forums and even in twitter and FB many times. Now it has been published in ICPM where it meant to be.

This is the 2nd article of the series. In this article I’m going to discuss the tiers of outsourcing.

When you initiate an outsourced project as the outsourcee, or when making the decision to outsource a project as the outsourcer it’s very important to understand which tier of outsourcing you are in to. This will give you some intelligence in advance about these extra issues you may face in outsourced projects compared to collocated projects. I can think of many dimensions of outsourcing when I define the tiers..
But following categorization based on geography – distance and time zones simply help me to understand many common positive and negative risks of such projects in each context.

'Outsourcing is outsourcing' either you outsource the project to your next door software company or to a company in the other side of the globe. Because in either case you need to manage external contracts, requirements, risks, security and knowledge transferring. However as I have shown in this diagram, the challenges in outsource project management increases when we move up in the tires mainly due to the communication issues and secondly due to cultural issues which I will be discussing in some of the future articles.

First, lets look at the bottom tier. The main advantage of outsourcing to a company with less travel distance is that it could facilitate more of face to face discussions whenever required. This will cut off a big portion of distant communication risks. The other point is that having same language speaking people working for you may provide you the luxury of using your native language in business discussions. Mostly the business and personal cultures will not have much difference with both the company professionals who work together for the projects and that will result much quicker relationship building among project teams. However this tier of outsourcing mostly delivers only the benefits described in the 1st and 2nd points which I discussed in the 1st part of this article.

Nearsourcing , the 2nd tier of outsourcing is more commonly seen among Western and Eastern Europe countries. Countries such as Poland, the Czech Republic, Slovakia and Hungary are stabilizing as software outsourcing destinations for Western Europe markets. As I see the software businesses attracts near sourcing mainly due to reducing the risks of cultural difficulties, legalization issues for onsite work and contractual/ financial terms. Further they benefit with minimized time zone differences. But if someone think Nearsorcing is the solution to avoid all the critical risk factors of outsourcing, it’s a big myth. Sometimes I see Nearsourcing bring more communication problems to the table.
Imagine a company in Norway outsource a project to a development company in Greece. I don’t see many Norwegions fluent in Greek or Many Greeks speak Norwegion. Neither parties don’t use English as their main business language. So these two teams trying to use English as a common language for communication can deliver more risks in Nearsouring than a Norwegion team communicate with a team in South East Asia where English is the main business language to do day to day work.
Nearsorcing seems very attractive for some of the industries such as manufacturing. If you look at the cost factor, Nearsorcing can bring you cost saving specially when it comes to manufacturing simply due to less transportation costs of goods. Hefty ocean fuel surcharges are involved when transportation happens from China to USA compared to Nearsorcing operation from Mexico to USA.
However based on available options in the global outsourcing market its still an argument to decide how much benefit Nearsorucing can bring in to software business which is totally different from manufacturing especially with relatively high labor costs of software professionals of Eastern Europe countries compared to most the SEA countries.

The third tier is what I’m experiencing right now with our current business at Exilesoft development in Sri Lanka and customers located in Norway. The same experience I have had for many years with some companies located in Australia, UK, Germany, Greece and New Zealand. Teams falling to this tier may face almost all the challenges in outsource business but still there is overlapping business hours within the same day where distributed teams can use for collaboration.
By looking at most the SEA software engagements with western countries, its proven that If well managed and well modeled, this tier delivers most the benefits of outsourcing business for the outsourcer as well as the outsourcee due to many reasons. The only difference in the top most tier compared to this tier is that, distributed teams in outsourcing business who are falling to the top most tier has no overlapping business time for collaboration. This increases risk of communication and becomes quite difficult to practice some of the agile methods which need closer and casual communication for projects specially the “Daily scrum” in scrum teams. There are alternatives we may use in such context (But not the Scrum mail :) period!!!) which we will be discussing in the future.

I have used Waterfall and Agile management concepts on such outsourcing projects in almost all these tiers. Compared to all the frameworks and models I have used, I find agile management concepts help to reduce the risks of outsourcing software projects drastically if used wisely.

In the 3rd part of this article we will have a closer look at dealing with culture differences in the project management falling to 3rd and 4th tiers of outsourcing and in the 4th part onward we will have a detailed discussion on other common difficulties and risks we face in outsourcing compared to collocated development while discussing how Agile can be used in each case to reduce the risks by taking Scrum as an example.

Kanban , Scrum, waterfall.. XP ?????. Nope… its time to have fun !!!!

2009-12-05T07:37:00.002-07:00

Exilesoft Celebrates another successful year.. !!! We have been scrumming a lot this year !! :-) and now its time to have fun!!

PMI Colombo Chapter Event - November.

2009-11-16T05:04:00.000-07:00

Offshore project management and use of Agile. – Part 1

2009-11-14T15:29:00.005-07:00

Its again Winter in North.. So we are busy here at Exilesoft, Sri Lanka with most the customers who visit us. That's one nice thing in offshore business, as much as we enjoy travelling Europe, it seems our customers have found a second home to come when the winter starts in their countries. This is an ideal time we get to work together again as collocated teams. For them its quite exiting to work with us as well as to extend their business trip for one week or so to have little relax time in this exotic Island, explore the culture and have a better understanding and stronger bonding between the customer and development teams. Altogether it’s an awesome experience for both the parties. I too enjoy such visits of our customers a lot.

In the same time, being in software offshore business is not easy. Unless you have the right relationship between the outsourcer and outsourcee, the offshore business can become really painful to both the parties.Software development itself is quite challenging even in collocated development environment. When it comes to offshore software development, we are adding some more complexities to it, simple reason is that an offshore development team faces the same complexities which an in-house team faces + much more . So the Project management in this environment by balancing this distant relationship is quite a challenging endeavor.

This series of articles which Im writing to ICPM, will be focused on the challenges in such offshore business and how we use Scrum (One of the Agile methods) at my current organization to overcome these mostly seen challenges in Offshore business. I hear you.. It’s a trade off. When we overcome some of the main issues., there will be other issues which we may face.. Its understood. Its all about how to overcome the most serious issues in such environment and deliver the right value to the customer without scraping the organization’s bottom line.

To manage these offshore/outsourced projects with distributed teams successfully, We first need to understand why Organizations outsource their software projects. By working twelve years in this industry I have seen the same reasons with most my customers who decided on outsourcing their projects to us irrespective of the size of their projects.

1. Skilled Resources
In Some of the countries , its quite hard to recruit skilled resources compared to others. May be its all about the availability of such skilled resources, the market competition as well as the difficulty of hiring such experienced resources only for one or two projects (Shorter time period).

2. Business Focus.
Even if they have these resources available to hire, if the organization’s main focus is not the IT business, it may not be always wiser to hire such resources and expand the IT departments which is not their primary business focus. As an example, a company in travel industry needs to be focused on travel business instead being focused on expanding its software development. So in this context, outsourcing its software development to an organization which focuses on software business can be a wiser move.

3. Protecting the Intellectual Capital
If an organization develop one of its core software products which will give them their competitive edge in the market, the last thing this organization may need is to have its developers who worked on this product to join its competitors with all the knowledge about the business. Some times when an organization hire people from the same country or state, there is quite a risk factor that the developers who work for this product may join their competitors when the assignment is over. But outsourcing this product to a country far away which doesn’t have such closer relationship with the other organizations in the same market may reduce the risk factor.

4. Cost
Most the organizations carry their cost benefit analysis before outsourcing its software projects to other companies. Its quite important that the cost difference to be a visible factor. However there is hidden costs in software outsourcing which I will discuss in a latter article under this series.

5. Round the clock / Extended hours of production
As an Example, if there are 2 distributed teams in an Organization in Norway and Sri Lanka, and if both team work their 8 working hours, the total production time expands to 12 hours as Norway is 4 hours behind Sri Lanka. This helps in some of the product development and software support work.

Its important that as the outsourcee we understand the key factors which enable the outsourcing business of the customer and deliver the expectations throughout development.

In the next part of the article, I will discuss the tiers of such software outsourcing and how the challenges increases in each tier. >>

P2P Conference 2009 - Agile Stream.

2009-11-08T01:17:00.011-07:00

Monday :
Most the speakers who reached Cairo before the conference had a visit to Giza Pyramids and the museum on Monday which was quite fascinating , specially to get to know each other as some of us have never met before and in the same time to explore Cairo, History etc. We all had lots of fun together. What I mostly enjoyed was the camel ride !

Picture : Me and Giza Pyramids

When we reached the hotel it was bit late, Before I went to the room, I met Dave Prior (Immediate past chair of PMI IT & Telecom Sig), It was so exiting to see him as we have been knowing each other through articles , blogs and emails for quite a time. He was amazing.
At night Emad ( the host of P2P and the CEO of Brisk Consulting wanted to meet all the speakers in order to give an overview of the conference. Except me all the others were from eitther USA or Canada. After the meeting , others proceeded to the Dinner but I was tired and full with late lunch so I went to bed.

Tuesday
The conference started officially on 3rd Tuesday with Keynote speeches by some of the ministers of Egypt Government and some industry experts. It was quite interesting to see how Egypt government has understood the importance of proper project management expertise in the region. The afternoon sessions were more focused on PMOs and Maturity of PMOs in General.
There we met Ricardo Viana Vargas (PMI Board of Directors Chair) Dave introduced me to him and gave him a reminder about one of my articles which they have referred before with regard to Agile and PMBOK. Jesse who was with us didn’t forget to tease me about the PMI April issue and me being the cover girl ( oh I'm blushed ) in front of him. And we had a little chat. I was so impressed to hear how open he is to Agile and Scrum while heading PMI, It was very impressive. I thought to bring this up in the Colombo chapter discussion next time.
Dave proposed that we should grab a coffee and do a practice run of my first presentation with himself and Jim as I was little nervous about the presentations among all the very experienced speakers.. But they were quite happy with the practice run so their comments gave me lots of confidence before presenting to the audience.
Dave gave me more info on Transition of the PM in Agile which he thought would be the questions from the Audience.

We started the Scrum sessions by 4th November. This segment was conducted by James Cundiff- Jim( Managing Director Scrum Alliance, Dave Prior, Jesse Fewell, Bob Tarne and me. It was an amazing experience to work with such people and we were a great Cross functional Scrum team. we conducted most the sessions with some discussions ,questions and answers.

The Amazing thing in this sessions were that, we , speakers had arguments about certain concepts openly in front of the audience. It was never a stiff speeches we see in normal conferences. As a team we turned it around. As a team we made it very agile , open and direct. Jim mentioned his opinion on daily scrum which Dave and Myself disagreed openly, Jesse had a conflicting idea about initiating an organization with Scrum against my opinion. We all had certain arguments on how to position a PM in this transition .. Very upfront.. This was amazing and most the audience gave lots of encouraging comments about the way we handled it . There you go....They got the idea of Scrum not being a very prescriptive method.. In RUP you never argue on how to write a use case or a PFD.. So that was an eye opening for the audience. Thanks Jim for starting this conversations.

Jim and Dave opened the session by explaining the basics of scrum. they got some volunteers from the audience to play a game for the attendees to understand the effectiveness of initial one time planning Vs Iterative planning. Then the next session was mine. I had to present the Organizations moving from waterfall to Agile , the challenges they may face in this transition. I touched main areas in the presentation such as Why Moving to Agile, (there I had a great story to convince the audience with real pictures to support the story)Which Agile methods to be selected , In Which layer of the Organization to be aproached first, (there I explained the core cultures of organistions and how to spot the right layer based on the specific culture ) then the most important part, how to handle the people in this transition, such as customer, Technical staff, Management and specially the project manager. Phew !!! You know what.. I got a blue screen.. Why MEEEEE!!!!!!!!!!!! But somehow I managed to not to click "my Panic button". so all were ok and I got some good comments about the presentation.
lessons Leaned : Have story cards in your hand , when ever you go to a presentation.. If your computer make troubles, still you can continue without an issue.

After the coffee break, Dave presented about "Reluctant Agilest" quite an interesting presentation about a story how painful agile can be when not embraced in right way.
There after, Jesse took over and he explained "Agile PMO" how agile a PMO could be. Very informative presentation on that aspect and he showed his maturity in managing PMO through out the presentation with live examples.
Then the Audience was lesser for the second session after the lunch break and Bobs presentation was to address the knowledge management for Agile projects. Im sure which has been a very interesting presentation , But I missed it as I went out of the room to get ready for my next presentation on the same day which is Outsourced Project management and challenges in Agile.
I think that was the best presentation I ever made in my life. It all came from my heart as this is what I have been doing for past 12 years. I discussed about outsourcing issues openly in 5 key areas and how we have used Agile to overcome these issues in my current company. Which was the presentation that I have got most the positive feedback so far. ( Most the delegates commented to me at the next day coffee break that they have never known Sri Lanka as such a software offshore destination.. Hmm I was happy..)We closed the day with my presentation.

We had an awesome night that day .. With all the speakers and some of the other people , we had lots of fun. The night was too long .. Me and Jesse who had to take the next day morning sessions were half dead when we reached the hotel around early morning the next day.

3rd day started with Jesse’s presentation on Agile vs PMBOK, which audience had many questions which they needed to clarify. Again I missed most the parts of this presentation as next I had to present my last presentation on Effective communication in Agile. I explained the difference between agile communication and the traditional project communication. In the same time I got some real project examples to show how Agile communication can go wrong with such informal methods. According the audience they had a good presentation from me.. But to be honest I think I was not with my full energy for this presentation compared to others. The next session was a very interesting one by Bob about the user stories and the last session was by Jesse about the Agile contracts. There he explained how fix price works in Agile contracts which is the case in most the real world projects. Interesting !!!

We had the round table discussion afterwards, all 5 of us together.. it was very nice...

Picture : closing dicussion by all the Agile speakers (from left to righit ) Jesse Fewell, PMP, CST, Dave Prior (CST, PMP, Immediate past chair of PMI IT & Telecom Sig ), me, Bob Tarne PMP and James Cundiff( Managing Director Scrum Alliance )

At night some of the speakers went for a dinner in Nile cruise while me , Dave, Jim, Andrew and Bob conducted a retrospective about the Agile stream of the conference. It was time well spent.
After the retrospective again we had a late night.. Not that late as previous night as Jim had to catch his flight back home , Emad and Nora (the hosts ) invited us to taste a real Egyptian Dinner at a real nice exotic Egyptian restaurant.. It was really a nice experience..
After that we said Good bye to each other.. It was such a sad thing to leave such wonderful people whom we worked together for few days as a team.
My flight is today evening.. Only Dave and myself were left in the hotel with the hosts as all the other speakers have left. We both had a small breakfast meeting at Marriot to discuss what we can do in the future together, specialy my interest to become a CST and upcomming PM conference in colombo which will be really good.

Are you a good Scrum master ?

2009-10-23T22:23:00.003-06:00

Scrum master is a servants leader .. We say this all the time.. So Scrum masters .. how good you rate yourself as a leader is scrum project. check out this matrix introduced by Bob Hartman (Agile Bob)

1. Listening – actively listening to what others are saying
2. Empathy – feeling the pain and thrills of others
3. Healing – helping others after they have been hurt
4. Awareness – understanding the big picture
5. Persuasion – persuading others to do what is right
6. Conceptualization – helping the team understand
7. Foresight – seeing problems before they arise
8. Stewardship – helping the team use resources most effectively
9. Commitment to growth of others – helping others improve
10. Building community – helping the team become more than a
group of individuals

Microsoft Dynamics AX team

2009-10-02T05:35:00.001-06:00

We have openings for a Microsoft Dynamics AX consultant and few AX developers from Sri Lanka or India, if anyone.. Please send me the CV to twi@exilesoft.com

PMI Colombo chapter Open Forum Oct - 2009

2009-09-29T03:11:00.004-06:00

The Guest Speech: Challenges to be faced when move from Waterfall to Agile.
Speaker: Mr. Finn Worm-Petersen, CEO Exilesoft
Date: 8th October 2009
Venue : Taj Samudra Hotel 5 PM – 7 PM
RSVP: Please call Vajira on 0714353787 to reserve your seat (None members fee Rs. 500)

You can earn 3 PDUs under Category 4 by participating the event.

World is bigger.. Its bigger than SCRUM..

2009-09-26T10:11:00.006-06:00

Did you hear about the facebook addicted criminals story on Sheryl's keynote speech at Advertising Week! (She is the COO of Facebook. She explained a true story of a criminal entering to a house, seen facebook in the computer. Logged in to it but didn’t log out ! :) He must be a Facebook addict like me.
Ok where did this Facebook story came up.. Ok.. Now I can remember , I saw someone’s FB status said today that treat every problem as an opportunity. I believe in it ! I have been always whining about my home only weekends.. But now Ive kept my whining aside and learned to use it as an opportunity to spend little time on reading..
Never mind all that.. Lets get in to the point.. Scrum and Kanban.. I see some heated up discussions going on….!. Its sad that some people believe that scrum is a god given solution to all the problems.. Scrum is great and it works in the right context! But not in all the contexts. I saw an article published by Crisp.se, they ask what do you think is the best tool … Fork or spoon? Good example. I know It’s a senseless question. So if you ask me again what’s best Scrum or Kanban I would say it’s a senseless question.(But I admit that I have not used Kanban in practice) But if you ask what’s much more prescriptive, definitely I can see that Scrum is more prescriptive than Kanban. However all the agile methods are much much less prescriptive than waterfall methods and that’s why those are mostly referred as light weighted methods. When the prescriptiveness is less in a tool, one should use more creativity and brain to make it work, but you get less constraints and high freedom.
Scrum works perfectly in product development.. But I can foresee its definitely going to be failed when you cannot plan proper sprints, when you can’t have that committed time for committed user stories. The best example is maintenance projects. How long you can commit to ? 1 month sprint ? 2 weeks sprint .. No.. most the time you cant go beyond 1 day I suppose.
In the article written by Henrik Kniberg, about how you can make scrum works with Kanban, he describes the adaptiveness and prescriptivenss of various methods beautifully. There he compares RUP , XP, SCRUM , KANBAN, and another Agile method called Do what ever :) ( which most of us are frequently used to :)) He rates the Prescriptive to adaptiveness scale of these methods as RUP (highest 120+ ) XP (13) Scrum (9) , Kanban (3) and Do what ever as 0 . As he says “RUP is pretty prescriptive – it has over 30 roles, over 20 activities, and over 70 artifacts, this may be one reason why RUP implementations end up being heavy weighted compared to Agile methods such as SCRUM and XP”

The main difference between XP and scrum is that , XP stress on how to do work such as test driven development and pair programming.. But Scrum doesn’t tell us about how we should do development. So scrum is definitely going to be more adaptive than XP.

Lets look at RUP and SCRUM now.. Most the time Im in firing line about Scrum as most my colleagues are coming from "sort of RUP" environment. I had an interesting discussion today with a PM friend from my PM network, he said RUP is like a dish with too much of salt and SCRUM is like a dish with too less salt. You will not eat both as it is.. there are so much you should take out when you are implementing RUP , same time you need to add bit more essence to SCRUM when you are implementing it in practical environment. (Read my previous post about SCRUM and test cases/use cases.)

Ok looking back to Kanban, Kanban also looks very attractive to a less process person like me LOL

The main differences Ive understood In Kanban compared to SCRUM is that;
1. Scrum tells you when to do planning , when to do the retrospective when to do the next sprint planning.. in Kanban you do as you see the requirement for it
2. In Scrum you are focused on delivering what you are committed to sprint, you do your best.. deliver what you can , next sprint you see how to improve, you measure this by velocity of a sprint, in Kanban you limit your Que in a workflow state. As an example you can say you can’t have more than 2 to do items in the item dashboard at any given time. But in Scrum you commit to user stories and you control the work to do by committed user stories.
My personal view is that Scrum is somewhat lean(But I know there are lots of arguments over this at the moment.) However Kanban is much more Lean than Scrum for sure.
Kanban don't stress about time boxing as far as Scrum revolves around it , Kanban cares about lead time.
To me as I read Kanban can be scaled much easier for multiple teams. But I need to experiment more on that.

I think this is one reason why I think Kanban can be a help in maintenance type of projects when Scrum becomes challenging.. However today there are lots of mix marriages.. Mix when you want to get the best out of them.. I had a waterfall team who had 15 min stand up meeting every morning.. Im going to have scrum teams who will use use- cases for user stories from RUP process. Now I don’t mind combining Kanban with Scrum when its needed.. ! All what matters is the success of the project. All these are tools for you to use them right to get in there.

Following diagram is taken from http://www.infoq.com/articles/hiranabe-lean-agile-kanban

International Project Managers day 2009.

2009-09-25T04:08:00.000-06:00

International Project Managers day is scheduled for 5th November. ( Cool :) Like Moms day , Fathers day, valentine’s day. … PMs who are always in firing line also should have a day for them I believe :)
There is a very good webcast program which you can join on 4th and 5th November.. the great project management professionals such as Gregory Balestrero - President and CEO, Project Management Institute are scheduled to give speeches on this.
You can find more info on this at http://www.iil.com/ipmday2009/webcast.asp

Online Exam for Certified Scrum Master

2009-09-22T20:19:00.001-06:00

the Scrum Alliance Board of Directors (Board) has decided to move forward with the launch of the online Certified ScrumMaster (CSM) exam on October 1. For more details Visit Scrum Alliance web page.

Scrum and Documentation.(use cases/ test cases). ?

2009-09-19T11:08:00.001-06:00

I know I was suppose to write few posts totally focused on practical aspects of user stories. But I thought to write this post first, because last week I had an interesting discussion at office which could be really useful to other agile practitioners as well.
We were talking further about agile testing. Especially with Scrum. We do have a separate well focused QA team managed by an experienced QA lead. In our model, the QA department is independent from any projects and they directly report to the Project Director. So how does this model work with SCRUM? I find sometimes its bit contradicting with concepts. We know Scrum has cross functional teams and each developer is responsible about their Quality. However, there can be testers too working in scrum team full time, they will be team members within the scrum team and coordinate with the scrum master. But if the QA department runs separately how do we do that? We had 2 options. Running 2 scrum teams for same project, you can call it scale up scrum, one for QA and one for Development, then have scrum of scrum everyday to synchronize with 2 teams. The 2nd option was for QA team to give permanent QA resources to each scrum team and they will apart from the QA department. In that case it would be an organizational change as well as we will be losing the concept of the power of an independent QA team who certify the delivery before delivering to the end customer.We thought of maintaining the same independent QA team and still to run Scrum ( if you don’t like me calling scrum for this method.. sure .. you can call it something different.:). ) But then the biggest problem is that how the QA team members get the knowledge of the product? Because, in a Scrum team the documentation is very less. We don’t create lengthy specifications and pass them over the wall. Then how does my independent QA team get this knowledge from the development team who participate the Product backlog planning meetings and sprint planning meetings.The following are the points we discussed;
1. One QA member of the QA dept participate the product backlog meetings as well as sprint planning meetings.
At the product backlog planning meeting, the assigned QA member with the team will decide which user stories will need use cases. Further, we discuss about using some very light weighted use case only when required. You can find a good article on some light weighted use cases for Scrum in http://breathingtech.com/2009/writing-use-cases-for-agile-scrum-projects/

2. Once the product backlog planning is over , the QA team member who participated the product backlog meeting will educate the QA dept head about the scope of work in QA dept with regard to the project.
3. In the sprint planning meeting, when the team decides of which vertical to be focused on, the team will create those use cases only for the specific selected vertical for the particular sprint. For that sprint, the sprint should have tasks and enough space to complete the use cases. In this case sometimes we may have to go away from our usual 2 weeks sprints to 4 weeks sprint.

4. Once the team finishes the required use cases, they will sign in to development tasks. The QA will have tasks to create the test cases during the sprint. So now we have test cases too.
5. Once the iteration is done (At the end of the sprint), the development team delver the shippable product increment to the QA department. , One of the tradeoffs is that this will delay the customers immediate delivery at the end of the iteration by few days.. But as a company, we need to assure the quality of what we deliver to the customer by our focused QA unit. I think this is better , so in this way, customers product quality is basically assured 2 times. Which enable us to deliver a very good quality product to the customer.

6. This QA dept quality checking also can be time boxed to few days as there cannot be such a bottleneck for the product owner to test the vertical.

I can see we can eliminate few practical problems in Scrum model by using few extra steps. Because we all may not have that “Luxury of right context” for scrum in real world business.

Scrum... never ending questions !! “yeah It’s a framework :)

2009-09-01T11:09:00.001-06:00

Someone had an argument with me about something I mentioned about scrum at some place.. ( Ok I would call it a “discussion” :-)) I love when someone challenges me on something what I talk about..!
Ok the “conversation” I had is this;
I said the scrum project starts only when the Product backlog is ready !! Im sure Im correct.. Ken Scheber said it better way than me.. (Obviously he should! )…“The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog “sounds clear..!
The point is that, in business we position ourselves as a total solution provider in software. Specially in Outsourcing business where we are in to , the product owner becomes a role from the customer’s business manager or a product manager. Because the total understanding and the product vision is very difficult to be transferred to someone outside the geography boundaries to a person who doesn’t have much understanding about the business climate where the product will be marketed at.
We all know that Product owner is never a part of scrum team. Ok then, do we leave the product owner to create the product backlog in that case? The product owner has enough time and knowledge to do the groundwork which is required to come up with the product backlog? Don’t we have to do it for him?
May be I had a too quick and confusing answer to him as always J
I thought this would help many readers who are bit confused about this pre stage of scrum. The point is Yes ! Scrum doesn’t stop the team getting involved with doing necessary mind mapping work, wire frames , usecases and other background work to help the product owner to get the user stories of the product done.. But those will not happen within the scrum project. In scrum project everything is time boxed. We have a planning meetings within defined time , we have tasks to be executed ( sprint) within defined time and we have a scrum day within a defined time. So we know exactly how time is taken for these specific user stories to be developed in scrum. However, the pre tasks such as helping the product owner to get the user stories ready can be done with the team involvement, and then the question is actually “when the team can get involved with the process”, It can be anywhere but the latest is the product backlog planning meeting . Then the question comes.. How long the team need to come up with the user stories? I don’t think any Scrum guru can give an answer to that..( I learned during my CSM that there is an easy answer for all the difficult questions in scrum – the answer is “it depends”)
Actually the time needs to take to come up with user stories really depend on the knowledge of the product, availability of other stakeholders to work with product owner, business environment, and many other factors. I don’t think the time you spend to come up with Product A for 100 user stories will have any relationship to a time you need to come up with Product B 100 user stories. Otherwise there could be already set benchmarks in the industry for time to create user stories. Which is never the case.
Another area which I find bit confusing is that, in our waterfall projects we do lots of micro management. We need to track time based on various functions such as how much time we spent on testing , how much time we spent on coding, how many bugs we got etc. But in a scrum project, Ive never seen or have come across such micro management or related data as everything is measured based on verticals. As an example , coz in a scrum project testing and many other cross functional work happens within the user story.. I was thinking a lot about that.. while scrolling up and down through sprint backlogs. As I see….. ok if you want to find how many hours you have signed in to testing related tasks, you can really get in out of the sprint backlog. So there you go.
But again, in a scrum project what’s more important? Achieving the product vision and delivering the verticals within time boxes or work with past data of project X to determine project Y ? Estimation based on historical data is totally out of scrum. But true enough when we are dealing with real business world, we cannot assume that all the customers will be thinking “Scrum”.. So we may have to collect some data too based on various functions..if all of sudden the PO comes and say.. you know your guys make too many bugs and due to that they couldn’t get the right velocity or guy X makes too many bugs.. I know all scrum practitioners may say NO.... But I see the fact!. You need to do bit of “SMA “ in real world :D

User stories - Do they need a format ?

2009-08-27T11:09:00.004-06:00

Every person whom I meet teaches me how much I don’t know about some subject. Either its about the world, history, culture, religion, different industries… whatever it is…This happens to me all the time when travelling. I have some luck to have good company most the time while travelling or in transit. Those strangers ended up being my “friends” frequently.

This time when I was travelling from Frankfurt to Doha, Some stranger fell in to conversation with me after seen my notebook bag ( I think I have mentioned about this notebook bag before in this blog J ) He assumed that I work for an IT company and he is an Agile management consultant based in Denmark and travelling to Doha for some assignment. You can imagine now.. a conversation in a long flight extended by 1 hour delay J

It was very interesting to know about various experiences we both had with Scrum and he was quite used to many other agile methods which I have never been exposed to before. However we both agreed that Scrum is the most popular Agile (According to him.. “The well marketed and money making Agile”) right now.

Talking about various experiences I asked his experience about user stories. This was some challenging area in Scrum projects. Getting the user stories right…

I always believed its better to have the standard for user stories “ As a “, “I need to “ “So that I can”.. In this way the requirements become much clearer to everyone and we may not miss the users what their expectations etc.. But he disagreed. I was surprised, but he had a valid argument on this. Example: As a Job applicant I want to post my CV to the job portal so that the prospective employers can view my CV in PDF format”

His argument was that its always difficult to stick with real users in user stories. As an example; you want to have date widgets in an application, so that do you write “as a designer I want to use the list of widgets so that “…….. ??? Where is the real user in this user story? ? I couldn’t agree less. Because I just completed a project initiation where there were many many user stories which I couldn’t think of mapping to my standard template originally but I had to do it by force with tweaking them by using developers, designers , architects as types of users which may not be the best case.. He also had the same experience .. One of his initial product backlogs 80% of the time it has been “ As a product owner “ which doesn’t make any sense…J

But then.. Million dollar question.. Why Mike Cohn standardized that user stories in a standard way? Didn’t he see this problem? I don’t think so .. Need much more thinking and reading on this.. may be some times not using standards would be better than using standards if they are not meaningful.. I will definitely do a follow-up post on this..

Anyway bottom line out of scrum is that speak to anyone who try to make a conversation with you…never know what they will come up with J

Yeah Im not a person who can live with open ended questions.. So Im chasing answers:

28th June..

Follow up today : I purchased the book from Amazon "User Stories Applied: For Agile Software Development " by Mike Cohn

29th June

I found this article :

Missing Dimention of user stories : Interesting thoughts: