Scrum - play by rules

A recent post by Ken Schwaber, on his blog made me think on the real pressures and culture of some of the workplaces I have encountered recently where that say they implement SCRUM and they claim their implementation fits their culture and company. Upon closer examination, there are short cuts, there are aspects where teams seem to adjust the process. To me it seems these teams are scared to go all in with the process, since the process of SCRUM is very well defined, the rules are known and its a question of getting better with time as you use the methodology. Perhaps they think they are better than SCRUM in some way by making these adjustments ? or perhaps just lazy?

I am not questioning that it takes time to absorb the concepts, make use of them, learn from your mistakes and get better. Everything gets better with practice and I don't believe SCRUM will fail you, its safe, if executed correctly.

Have a safe SCRUM - it won't fail you. 

Importance of team structure and risk evaluation

I was talking to a couple of software professionals recently and they employ the use of SCRUM and what I found interesting was that they all said, "we use N scrum teams" and "we have been using it for a while now ( over 1 year or more) " but it seemed to me that achieving the right level of communication was still missing and the deadlines were somewhat missed. I asked them , how do structure the team and how do you evaluate risk ? They all said, we have teams that are focused on particular competencies like network, or applications or platform ... they all use accurate stores to define the problem to be solved ( which is ok )... but they all had cross communication issues, which in effect caused a "silo" situation among the teams.

In my opinion, I think one really needs to look at the teams structure and ensure that the right representatives are part of the team, for instance, if you have a feature that requires operations, and you are deploying to a website, then its natural and a must, to have the operations folks be part of say the application team standup. I strongly believe that the team should be structured as a feature team which needs to include all participants impacted by that feature throughout the planning and execution phases. This increases transparency and understanding early on so that when it becomes time to deploy or ship, you are in a better place and less riskier place to succeed. The team structure and risk are really separate concepts, but I think merging them together makes sense and adds to the overall reduction in shipping risk.

In addition, as the stories are getting figured out, its important to understand the "feature risk" and the probability of impact and understanding the scrum risk curve.

Scrum risk curves, would involve understand the feature in a few sentences and its risk, the probability of success or failure, the exposure and time lost.  This is a concept originally introduced in 2004, by John Brothers in The Agile Times in 2004: the risk burndown chart.

Figure 1: Risk Census

Our simple risk census here describes each risk, provides an estimate of how likely the risk is to occur, the impact to the schedule if the risk did occur, and then the expected exposure to the risk which is the probability multiplied by the size of the loss. I recommend creating a risk census during the first sprint planning meeting and then updating it quickly during subsequent planning meetings as new risks are identified or as the probabilities or sizes of known risks change.
The risk burndown chart is then created by plotting the sum of the risk exposure values from the census. My recommendation is to sum only the top ten risks even if the team has identified more. Do this even if the top ten change over the course of the project. A risk burndown chart will look just like a normal burndown, except that it plots risk exposure over iterations.