Welcome to In-the-SPIN Newsletter
Newsletter of the Boston SPIN
In this Issue:
We hope you enjoy these articles from our presenters over the past quarter. Remember the Boston SPIN is on summer hiatus in July and August. We'll be back with a new line up in September.
Have a terrific summer and we'll see you in fall!
Breaking the Rules by Rick Brennar
Many outstanding advances are due to those who broke rules to get things done. And some of those who break rules get fired or disciplined. When is rule breaking a useful tactic?
In the race to be the first to the South Pole, the two contenders were Robert Falcon Scott, of the Royal Navy, and Roald Amundsen of Norway. Scott had Royal sponsorship, but Amundsen had to persuade his backers of the commercial possibilities of his expedition. These were the days before the Panama Canal, and the only shipping routes around the Americas were long and expensive. To make the investment in his expedition attractive, Amundsen told his backers that he was exploring the Arctic, which held much more commercial interest than did the Antarctic.
Just one thing, he was lying. His true motive was to be the first to reach the South Pole. Amundsen successfully misled everyone. He broke the rules.
Breaking the rules is sometimes the best way, sometimes the only way, to get things done. When we break the rules, and then fail, we can end up in deep yogurt. But when we break the rules and then later succeed, people sometimes overlook the transgression. And sometimes they do not.
When is rule breaking a useful strategy? What rules can we break safely? Here are some tips for breaking the rules.
Old rules can be more breakable
Older rules tend to be more breakable than newer rules. Sometimes the conditions that led to them no longer apply, and sometimes their chief architects have moved on. Of the older rules, those that are frequently applied tend to be the strongest. The old, dusty ones that lack constituencies tend to be the most breakable.
We do not admit it, but goals count
The end doesn’t justify the means, but what people care about does matter. If the goal is attractive enough, people tend to look the other way when rules are broken. Break rules only when you’re aiming for a goal people care about and you think your chances of achieving it are good.
Stay within the law
Breaking organizational rules is one thing. Breaking laws is another. Law breaking invites all kinds of consequences, and organizational benefits are not likely to count for much. Be knowledgeable enough to stay within the law.
Personal gain is a liability
If you personally gain from your rule breaking, you are asking for trouble. Breaking the rules is much more likely to be acceptable if the organization is the principal beneficiary. Even better if your boss and the applicable rule enforcement unit are beneficiaries.
Prepare to accept adverse consequences.
If you fail, and if you broke rules in the attempt, you might have to pay a price. The price can include organizational discipline, termination, or even “blacklisting” in your profession. Be certain that you’re prepared to endure the consequences if the organization decides to take action. Most important, rule breaking is a white-knuckle sport. Those who care passionately about achieving the goal have a definite edge. What are you prepared to do?
To read Rick's presentation with more details, visit: Rick Brenner
Reprinted with permission from Richard Brenner. Copyright © 2011 Richard Brenner.
Rick Brenner is an independent consultant who works with people in problem-solving organizations who make complex products or sophisticated services that need state-of-the-art teamwork, and with organizations that want to achieve high performance by building stronger relationships among their people.
He presented “The Race to the South Pole: Ten Lessons for Project Managers” on February 15.
Embedded Agile: Slicing the Cake by Nancy Van Schooenderwoert
Agile thinking is all about risk and how to mitigate it. Iteration is the biggest risk mitigation strategy for Agile teams. Regularly delivering tested, working features is the way we avoid having built components that cannot work together.
But engineers are used to building products in component layers. It seems more efficient to focus on completing each component. The problem is that there are always enough unknowns in development to make that a risky strategy
In embedded systems, significant infrastructure must be in place before even the smallest user feature is shippable. That is the “transient state” where the goal of iterations needs to be focused sharply on early infrastructure, and knowledge creation.
As an Agile embedded development team makes the transition to being able to deliver tested working user features, they stay in control by using iterations that deliver to internal customers such as the electrical engineers, the algorithm designers, or other engineering groups.
Embedded systems with their subsystems can present much deeper stacks of engineering component layers. This makes it more difficult to create stories that slice all the way through the architecture. But there is still great value in making progress along functional lines. The practical solution is to define vertical slices that do not cut all the way through the architectural layers. An example would be completing boot code that is sufficient to bring up flash memory and access on-chip RAM. This is not an end-user deliverable, but it is easy to define a clear pass-fail completion test to know when it’s done.
This approach has been called, slicing the cake, by Mike Cohn in his book User Stories Applied because vertical slices through architectural layers are the best way to define functional chunks of work a team can deliver early – a great way to please customers.
© 2011 all rights reserved