Tuesday, September 29, 2009

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.

Saturday, September 26, 2009

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

Friday, September 25, 2009

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

Tuesday, September 22, 2009

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.

Saturday, September 19, 2009

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.

Tuesday, September 01, 2009

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.

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