It appears that many have found this topic interesting, therefore we shall be conducting this open house one more time. it will take place on Monday, February the first at Sela offices. This event requires registration so if you are interested just leave me a comment.
If you wish to review the slides they can be found here.
"Were doing Scrum-But ..."
The ScrumBut phenomena has started to appear more and more as scrum has started to take its hold in the industry. I want to add one ScrumBut i was in charge of and it went like this:
We were doing scrum but: We had no release planning.
At the time we were undergoing so many directional shifts that each time we tried to flesh out a release plan, it changed drastically causing any planning effort to fail. Also our acting PO wasn't involved enough, a fact which also contributed to to difficulty of achieving a stable enough release plan. So we went and continued without it.
And actually it wasn't a complete disaster, we achieved a very short sprint length of 1 week, we added to that various engineering practices like TDD, CI and Pair programming and we managed to maintain a constant development rhythm with good quality.
however we were missing several big things, in fact we completely gave up on any attempt to see and track the bigger goals. I wasn't able to predict anything beyond the end of the current sprint and the developers found it difficult to understand the "bigger" picture. Eli has described the problem:
So if the management has a goal: Close Sale with Customer [put huge customer], and to do this the R&D must implement the ABC feature. We might reach the end of the month without that feature being implemented and management won’t know about it.
The thing is, that what we were doing seriously lacking, and due to us changing the process and failing to do it properly we got the what can only be described as the logical result.
When you don't plan on the higher level (release), you cant project beyond the micro level (sprint). You don't measure overall progress, and you lose the ability to manage on that high level. Naturally you cant be sure when things will be done or when things are not going according to plan.
At Typemock the solution for this was to adapt an "integrity" based management approach, and so far it seems to be working for them. However what Eli reports as "The differences between Scrum and integrity" is actually based on a something which is Scrum based but is too lacking to represent actual Scrum done properly.
I attended Giora Morein Agile boot camp course yesterday and during the day Giora (while talking about Agile Planning) has shown the following diagram:
He then asked the class what would they think should be the best order in which to tackle the given features. Several answers were given and all of them started with the "Low Risk- High Value" category.
I cant say I was too surprised by this. People, especially developers, have a tendency to first pick up the "low hanging fruits". Their natural reaction is to fear risks and go for path of least resistance (I've touched this subject in a previous post:Cost of Change – The Fear Factor).
However the "responsible" answer, would be to start out with the "High Risk - High Value" category and only then tackle the "Low Risk - High Value" features. The reasoning for this, is since the features in the "High Risk - High value" category have a HIGH value, eventually they will need to be done. It would be better to tackle and remove the risks involved in them as early as possible. Removal of risk is healthy for a project. One must try to remove as much risk as possible as early as possible, if a real nasty surprise is lurking, which will cause the project to fail. We want to fail it fast to minimize the amount of money wasted on the failing project.
BTW, after finishing all the "High value" features, a good strategy would be to proceed with the "Low Risk - Low value" category, and find something better to do besides "High Risk - Low Value" features.
1/13/2010
Posted in: 
Posts
