Zooming In and Out

October 28, 2011

In my last post, Change the Right Things, not Everything, I highlighted how Intel shifted away from the memory business and into the microprocessor business full time. Andy Grove and Gordon Moore concluded that this was the correct decision when Grove zoomed out – as Jim Collins and Morten T. Hansen in Great by Choice call it – by posing his question about what a new CEO would do in their place.

Collins and Hansen adopted the terms zoom out and zoom in to capture a duality they observed in “10X” leaders. These leaders have the capability of remaining “obsessively focused on their objectives and hypervigilant about changes in their environment.”

Zooming out in a leadership context is about sensing changes in business conditions, the time frame involved, and the risk – ultimately leading to an assessment as to whether new conditions will call for disrupting existing plans. Zooming in, on the other hand, is all about “supreme execution of plans and objectives.” But there is another flavor of zooming in and out.

Change the Right Things, not Everything

October 25, 2011

As Andy Grove: The Life and Times of an American Business Icon relates, at one point in mid-1985 Andy Grove and Gordon Moore determined that Intel should get out of the memory chip business after Grove asked, “If we got kicked out and the board brought in a new CEO, what do you think he would do?”

Moore immediately replied, “He would get out of memories!”

The decision wasn’t easy to come by until Grove posed his question. The memory market was Intel’s historical bread and butter, whereas up until 1984, the microprocessor (logic) business wasn’t particularly good for Intel. Making the decision even more drastic for Intel was the fact that this change was a change in identity. “Our priorities,” Grove said, “were formed by our identity; after all, memories were us.”

Book Review: Great by Choice

October 21, 2011

Great by Choice: Uncertainty, Chaos, and Luck--Why Some Thrive Despite Them All

Why do some companies thrive in uncertainty, even chaos, and others do not?

This is the key question that Great by Choice seeks to answer. I’ll state up front that if you are looking for a how-to cookbook on success, this book isn’t for you! Instead, Great by Choice leverages solid research, analysis, and examples to clearly illustrate the principles used by seven companies to significantly outperform comparison companies in the same industry during turbulent times by an order of magnitude – generating 10 times the performance – to become what Collins and Hansen call “10Xers” (pronounced “ten-EX-ers”). But it’s still up to you to figure out how to apply those principles to your situation.

The Elevator Story: Guiding Behavior Changes with Scrum

October 18, 2011

Scrum is a great framework for self-organizing teams to manage their work, but it lacks any real guidance or techniques for teams to use when they encounter problems. All too often the default answer is either get a coach or let the team work it out.

Both options can work, but there will be times when neither is an option. As Agile adoptions increase, problems will emerge on too many fronts. Coaches won’t be available when we need them, and there will be times when the teams themselves will be ill-equipped to deal with problems on their own.

Changing behavior is the most difficult aspect of change, particularly one that involves conflict. Consider the following hypothetical scenario.

Software Developers Should be More like Writers

October 14, 2011

As I’ve noted in my last couple of posts, hard work is the backbone of success, but the best don’t just work hard for the sake of working hard. The best work hard at understanding what it takes to be better, to learn and train themselves in new techniques to raise their game.

A vast majority of the software developers that I’ve ever worked with are hard workers, without question. They’ll toil for countless hours at solving difficult problems; they enjoy spending their time writing code. For many, I feel that there is too much time being spent writing code and not enough time reading code.

Committing to Being Our Best

October 11, 2011

Towards the end of my last post I commented that we need to be committed to doing our best. To work harder at being smarter. It’s all about committing to and living up to the United States Army’s recruiting slogan (1980-2001), “Be All You Can Be.”

Doing our best doesn't require a competition to sort out the winners and losers. In business and in life, what is more important is your drive and mindset. Winning a contest is about who is the best on a given day. A winner’s mindset is about improving, about making a realistic assessment of where you are right now and what you need to improve – and to work at getting a little better every day.

What are you committing to?

October 7, 2011

As a result of Sprint Planning, your Scrum team has made a commitment to completing a certain set of Product Backlog features. This act is a public commitment, with the team’s Task Board visible to all. The ScrumMaster even sent out an email to all stakeholders outlining what the team committed to in this Sprint. However, during the course of the Sprint unforeseen problems emerge…

The team is faced with a quandary. The team cannot meet its Sprint feature commitment while supporting its other commitments to high-quality, well-designed code (related to the definition of “done”) and sustainable development. The ScrumMaster takes action on behalf of the team and removes features from the bottom of the Task Board, reminding the team that, “A commitment is not a guarantee!”

As a team member, how does that make you feel? How do you think the Product Owner or other stakeholders feel?

The Versatility of Velocity

October 4, 2011

Scrum teams understand that velocity is an indicator of how much work a team can accomplish in a sprint. Velocity can also be used to forecast completion dates, using an estimated backlog and the team’s velocity to project how deeply into the product backlog a team will be at a given point in time.

Scrum estimation works because it avoids making time-based estimates, and for good reason. People are poor at estimating task-completion times; we tend to focus more on what we want to achieve, underestimating or overlooking potential impediments.