Tuesday, February 23, 2010
Labels: SCRUM PMBOK Comparison
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.
Tuesday, February 02, 2010
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.