m&ms are not just for eating, it thought me something about establishing SCRUM metrics.

As part of my Operations Management module at MBS, we studied the concept of performance and quality measurement. We played a game whereby a team of four separated into two quality inspectors and two operators. I was an operator. The inspectors were told to develop two measures of product quality. The product? m&ms.

m&m's are not just for eating

The M&Ms were laid out and given the quality metrics: fail any m&m if the 'm' was less than 50% visible and if there exists any visible cracks. I diligently went through each m&m, examining the quality of the printed 'm', its opacity, the shape of the 'm'. I then did a 360 degree check on the m&m checking for uniformity in the shell. This was repeated for my colleague and we each repeated the check for consistency.

In the end I failed 40% of the m&ms. So did my colleague. The quality inspectors only failed 5%.

This example illustrates the difficulty in establishing performance and quality metrics that furthers and organizations goals. As an operator, I wanted to do the best job that I can to the established metrics. I also let pass m&ms that had pinhole defects, but did not fail them as they were not specified in the metrics, although they were clearly defects (still as yummy though). The danger in metrics is that they may create an imbalance between performance and quality, in this case, the number of sellable m&ms and clear defects (e.g. missing 'm').

SCRUM performance and quality metrics

This made me wonder as to the effect of scrum's performance and quality metrics have on a team. Increasing and maintaining the velocity is a performance metric. That's the amount of work a team is able to accomplish during a sprint. If a scrum team's only key metric is velocity, the team could overly focus on cutting code, thereby increasing velocity. The cost would then be defects introduced. The performance metric of velocity would then have to be balanced by the number of defects introduced, this would promote creation of unit tests and developer testing.

The metric of defects introduced would have to be denominated by velocity (defects/velocity) to provide an apple-to-apple metric, whereby a team's velocity increases, but so does the defects introduced as the team is producing more per sprint.

There are a couple of challenges with the defects introduced metrics. Firstly, it is a lagging indicator. Defects introduced would only be found beyond the current sprint, thus would reflect on past work done. Secondly, if there are testers on the SCRUM team, then there is a conflict of interest for testers to report found defects. Perhaps a relevant control metric would be number of test cases executed against the story size (via points).

Unfortunately, defects, unlike m&ms, are not as tasty.

Is your SCRUM team too big?

How big is too big? Some people say you can never have it too big, but in this case, it is.

I'm talking about team size. The team that I am currently working on supporting a large eCommerce portal, has 18 members. We also practice SCRUM. This is a big no-no in SCRUM teams as it becomes difficult to manage. These were the signs that our SCRUM teams were not lean and agile:

1. Standup meetings

Our standups were taking 30 minutes or longer. Team members were not engaged as it takes a while to get to their turn to update. People were bringing in laptops to do "work." People stopped coming because they had more important things to do. Daily updates were sent via email to be "more efficient." The team was SCREAMING that the team was too large, but it takes a skilled scrum master to listen.

2. Sprint planning

Planning was taking two days, sometimes longer. Many tasks were added to the sprint after start of sprint. Many of these could've been identified if we had performed better planning upfront in discussing stories and breaking them down to bite size pieces. Many members did not have the information they required to start working on the tasks before sprint start.

3. Team Dynamics

Our testers did not fully understand the stories in the current sprint or even which developer were working on them. The developers, business analysts and testers were not working in concert to deliver a feature.

4. Sprint Status: Burndown

With every sprint, we have problems burning down to zero. Of course many of these problems lie with the quality of the requirements, but it goes back to team dynamics where the business analyst, developer and tester were not working in concert to deliver a feature. By having the three roles in close communication during the feature development, information is more quickly shared and know-how is transferred.

As what Jesse Fewell has thought during my SCRUM product owner training, SCRUM is a diagnostic tool. SCRUM will not solve our problems, but rather explicitly display it. It just takes the team to listen and bite the bitter pill to improve.

We did listen and bit the bitter pill and took the decision to split the team. In the spirit of empowerment, the manager set the stage for why we need to split and promptly left the room. It was then left to the team to self-organize in to two teams. Typically a manager would make the decision, as in "you go here, you go over there, you I don't need." By giving us the opportunity to self organize, we discussed in length about the pro and cons, how to address the cons and it resulted in a better understanding of the WHY and the HOW.

All this without having a manager in the room.

Identify, Exploit, Subordinate, Elevate

One of the concepts of ToC is to IDENTIFY the bottleneck, figure out how to EXPLOIT it (how to use it), SUBORDINATE other processes to support it (realign processes) and figure out how to ELEVATE it, so that its less of a bottleneck.

We recently had a problem where the constraint (bottleneck) within our team is a particular senior developer. This is not to say that the developer was not good, but rather the opposite. He was *too* good. This person has a lot of experience compared to the rest of us, as it is a relatively new team. This developer knows the history of the current application, and the one that came before it and has the contacts within our organization (a large enterprise). This developer would also frequently play the role of a business analyst and generate requirements.

From the outside, it looks like this guy's a star (he's very valuable), but think of the team. If he is the constraint, then wouldn't all the shifting between tasks lead to other resources idling?

This was the case in our team. He felt that he was stretch and working 50-60 hour weeks and some of the rest were idling and on facebook for significant parts of the day.

From the ToC perspective, we should determine how to exploit the bottleneck. The most valuable function for him was to generate requirements. Not just any requirements, but QUALITY requirements.

The first step is to IDENTIFY the constraint. This meant identifying which of his functions and responsibilities carried out by others. This involved work that did not require much undocumented knowledge, like building new features or fixing defects. What remained is the core constraint. Once we freed up some of his time, hence capacity, we identified his most important function - a business analyst. Generating requirements will allow the developers to be able to do just that - developer software.

Secondly, we have to EXPLOIT the constraint. He was made a business analyst and generate requirements. To minimize the level of rework for both requirements and code, generated requirements are vetted and reviewed prior to start of work, thus SUBORDINATING the process. This usually leads to higher quality requirements as gaps are identified and the review process would lead to better understanding of the requirements and allow the developers to generate better estimates.

Lastly, we attached junior business analysts to him. The junior BAs would follow up on communications (relationship building) and to write the first draft of the requirements (to gain knowledge and experience). This ELEVATES the constraint.

The results were good, but other challenges would arise such as personal interests and perceptions of the individual's career progression, but that's a story for another day.

Planning Poker

Today we just did planning poker for the first time. It was an interesting experience as it I realized that it is not just for planning. By doing consensus based estimation (similar to Delphi model), the exercise of estimation will:

1. Identify gaps in the requirements. This leads to better requirements.

2. Great equalizer of information. As the high/low estimations will need to discuss their positions, knowledge and information is shared.

3. Generates buy in. Since this is a group effort, consensus of estimates will have team buy in and greater likelihood of commitment.

It was a stimulating discussion, but the facilitator needs to keep an eye on the clock as discussions can devolve into something else and sidetrack the team from the task at hand. The facilitator is integral to formulation consensus based estimations as a team will usually have one or two persons have seniority or just plain talk loudest that can anchor an estimate.

What is anchoring? Take the following scenario as an example. During our planning exercise, we had discussed a story prior to estimation. One of the first things the developer said was "well I don't think this will take very long." With that one sentence, it will 'anchor' a team that the task is small, thus the estimate should also be small. Imagine if the developer had said, "Well, this should be a two day job." BANG, everyone will think its a two day job.

One of the key concepts of a consensus driven estimate is to level asymmetric knowledge and experience. A low ball estimate may mean that the estimator may not see the complexity of the problem, or know a better way of doing it and vice versa. The key here is to let everybody form their own idea of how long and complex a task is suppose to take, get all the information and experience into the open, discuss and reestimate. With each cycle, information, experience and how to get the task done is shared and hopefully the best solution will be byproduct.

Update: There is an online planning poker tool provided by Mountain Goat software.

Can Political Correctness Stifle Creativity?

I recently attended a leadership workshop in Singapore as part of my MBA program, where a significant portion of the material was on "creative leadership" based on the Manchester MPIA (mapping, perspectives, ideas, actions) model. The crux of creative leadership entails that the creative leader brings out the creativity from his team.

The MPIA model and many other like it, uses a combination of brainstorming and lateral thinking to reduce the mental barriers to individual and team creativity - thinking outside the box. That phrase is oft used but may not be deeply understood. It this workshop that had provided additional insight into what shape that box takes.

Each of us have our own biases, opinions, experience, knowledge and fears; factors which shape our individual boxes. What may be considered out-of-box or creative, may not be to another person. This leads me to the question of can political correctness stifle creativity?

At the leadership workshop, our team had the project assignment of creatively addressing a critical problem of a charitable organization. This organization has the challenge of reaching out to the hearts and minds of people everywhere to make peace on world peace day. One of the techniques of MPIA is to use perspectives to capture key challenges. A key example was when I had said "How to make this movement spread like bird flu?"

The team was aghast at the working of this how-to. Immediately they had rejected it (being an island state - I take it to mean that contagious viral diseases were a sensitive subject), when they're not suppose to at this stage, and offered to reword it as "how to make this spread like wildfire?" I did not object, as at first glance they would mean the same thing, however upon reflection, there are significant differences.

First off, wildfires spread because there is able fuel (dried grass), and a catalyst, strong winds. Flus spread differently, there are the hosts, means of transmission and mutation. Applying the flu metaphor to an idea has vast implications - hence the phrase "going viral."

In the end, we did well with our group presentation, although a part of me wonders what would have changed if i had objected to the rewording. For a team to be creative, rules must be established, but boundaries broken. This would enable exceptional performance.