Do we blame SCRUM for that too :).?

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

Risk Management – where it fits in Scrum?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Seasons Greetings from Projectized !!

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

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

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.

Offshore project management and use of Agile. – Part 1

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.

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 ?

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

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

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

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.

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

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

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

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 Schwaber 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 the product manager. Because the total understanding and the product vision is very difficult to be transferred to another person who is outside the geography boundaries as he has no much understanding about the target market. ( we could hire someone from the customer location as a consultant for sure, but its not a practical solution for every project we do )

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? Do we have product owners who has enough time and knowledge to do the groundwork which is required to come up with the product backlog?

I thought this would help many readers who are 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 , use-cases and other background work to help the product owner to get the user stories of the product done.. But those tasks 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 “when the team can get involved with the process”
It can happen at anytime, but the latest is the product backlog planning meeting . Then the question comes.. How long time is needed 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 needed to come up with user stories really depend on the knowledge of the product, availability of other stakeholders, 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 the 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.