I just got new hosting, so moving all my old blog content over….
Moving the blog
Reply
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.
Groundhog Day
It dawned on me that in most enterprise, at least those that I have worked in, and I have worked in MNCs of all sizes and nationalities, that managers of software development teams do not understand our craft.
Too often they look at it from a operational perspective. That is the “project” has to be able to be delivered on time, scope and budget (yeah right) and that the team is to be managed by pushing the right buttons and creating the right processes.
This is the wrong way.
If managed properly, software is about solving problems. If you are a software developer and you are continually solving the same problems, then your application and the development team has room to improve. A simple example would be a piece of code that does the same, or similar, function in two places. Generalize and put that into a library.
Software done right should be like innovation, you’re always solving the new problems, or old problems in new situations, but never old problems in the same situation.
In short, you should never have to do the same thing twice.
The Goal
Why am I starting this blog?
I am a computer engineering graduate and a career software developer. I am also an MBA student.
It all started with the book “The Goal” by Eliyahu Goldratt, which introduces the Theory of Constraints.
This blog is on my thoughts on software developer, particularly on gaining a deeper understanding of creating software from a non-technical perspective; from management, processes and achieving excellence in our craft for a holistic perspective.
Continuous Integration as an Innovation Engine
Innovation – that’s an increasingly used buzzword in business today. As more companies have become more efficient, through the use of well known operational processes (e.g. TQM, Six Sigma) and the proliferation of IT has enabled more firms to adopt these methods quicker and cheaper; firms find it increasingly hard to be more successful then their peers. Hence, creating innovation is the latest business trend – and that’s a good thing.
Innovation does not mean that a firm has to invent new products. It does not even mean generating radical ideas. Innovation is about bringing together ideas and inventions that are already there, in a manner which solves an existing problem and generates real economic value.
However, innovation also means failure. Most attempts at innovation will fail and how could it not? The act of innovation is to experiment and try new things and not all of them would be success. Therein lies the contradiction: firms say that they want to be innovative, yet fear failure. To be truly innovative, a firm has to build an environment that not only tolerates failure but to encourage it; to remove the stigma of negativity from the acts that fail would embolden the organization to try bigger and ever bolder experiment, with greater payoffs.
In the business of software engineering, there is ever the contending forces of adding new features and making sure nothing breaks. Most of the projects which I have worked on would inevitably reach a point where the rate of new features added would be outstripped by effects to maintain its stability. Tell tale signs that your projects are nearing this stage is having your application described as spaghetti code, cutting and pasting code as to not “break something” and rejecting a feature request, not because it lacks value, but its deemed to be too difficult.
That’s why continuous integration can be your development team’s innovation engine. An application with a mature continuous integration environment would ensure that the code is healthy and the application works as it is expected. The team is allowed to freely innovate, by adding in big features, radically altering its underlying architecture to enable new paths of growth or even just flat out experiment with new technologies and ideas. If an experiment does not pan out, through a string of unfixable broken builds, just roll back and and you’re good.
Continuous integration is able to form the foundations of an innovation engine, however it is just a start. The team must be willing and able to try, fail and try again.
Purpose Driven Companies Are More Successful
A couple of days ago, I had sat through our company’s quarterly all-hands. One point that struck me was the statement that purpose driven companies are more successful in the marketplace. So that does mean that every company should start being purposeful? Any student of Econ 101 are already thought that firms seek to maximize profit. According to behavioral economics, it may not be profit but rather market share, market valuation or personal perks. But bottom line is that every firm has a purpose, not not every firm is equally successful!
Where success comes from is when the purpose is aligned to those of the market, in the case of a retailer – that would be their customers. Econ 101 teaches us that the market would ‘clear’ at equilibrium, that is when the supply and demand curves meet. What it doesn’t explicitly tell us is that firms must provide something that the market wants, is willing and able to buy.
Take the example of the iPhone and Windows Mobile. Windows Mobile has been around for more than a decade yet it had not captured the imagination of the market in the ways of the iPhone. From my very first Windows Mobile phone, it was very clear the natural inclination was to touch the screen with the fingertip! Microsoft did not listen to his customers and had stuck to the stylus. Apple has listed and gave the market what it had expected.
In the end, its a no brainer. For firms to be successful, listen to your customers and give them what they want in a way that is easy to get it.