Observation Deck

The Superhero Culture: Our Grown-Up Teenage Addiction

2012-01-10T19:24:00.000-08:00

I know a little about smoking. My mother smoked her whole life. It eventually killed her. I never did understand the grip it had on my mother and those like her until I read Malcolm Gladwell's The Tipping Point.

Teenage smoking is one of the great, baffling phenomena of modern life. No one really knows how to fight it, ore even, for that matter, what it is.

Gladwell goes on to point out that education has not been effective. In fact, it is not that teenagers don't understand the dangers. In fact, they believe smoking to be more dangerous than it is.

Now what has this got to do with product development you might ask? Well, it seems as product development teams we have a similar addiction that affects our ability to deliver value and create a sustainable pace. Despite the best efforts of Covey and others to educate us we continue to multi-task, constantly change priorities and work our most valued contributors to the point of exhaustion. We know the hidden costs. It is not that we lack intelligence, in fact some of our most ambitious and driven companies seem to be where this culture is most pervasive. Why do we do it? Why do we continue to reinforce the superhero culture? Gladwell provides clues to the answer.

The significance of the smoking personality cannot be overstated, If you bundle all these extrovert's traits together you come up with an almost perfect definition of the kind of person many adolescents are drawn to. Maggie, Pam and Billy were all deeply cool people but they weren't cool because they smoked. They smoked because they were cool. Smoking was never cool. Smokers are cool.

We know the superhero culture is bad for us but it persists. It persists because we want to feel needed, we want to feel indispensable. We find it easier to be reactive than proactive. We love the sense of urgency and get a buzz from putting in the extra hours and saving the day. But most of all we persist the culture because the people we look up to and aspire to be got where they are through being superheroes.

The Real Star of the Show

2011-04-20T11:42:00.000-07:00

In a 1990s version of the Chicken and Egg scenario we witnessed the spectacular rise in popularity of the video projector and Powerpoint.

Dilbert and others have done a lot to help us come to our senses and remind us that (as Garr Reynolds says):

Powerpoint slides are not the "star of the show" and that we shouldn’t let our message and our ability to tell a story get derailed by slides that are unnecessarily complicated, busy, or full of what Edward Tufte calls “chart junk"

So, we need to keep our slides simple. How simple? Garr suggests:

The best slides may have no text at all. This may sound insane given the dependency of text slides today, but the best PowerPoint slides will be virtually meaningless with out the narration. Slides are meant to support the narration of the speaker, not make the speaker superfluous.

If you’ve been to a Rally presentation or class you might have noticed we subscribe to the same philosophy. My colleague Ben Carey has taken this to the next level. Influenced by Dan Roam and Sunni Brown he has been experimenting with deckless training using butcher paper and a marker pen. You may not have the confidence in your drawing skills to do what Ben does but it does illustrate (excuse the pun) that we can succeed without Powerpoint.

Of course, the star of the show is not the presenter, as Garr points out, the real star of the show is the audience and in direct contrast to some of our established paradigms the less the presenter speaks the more the audience learns. As Sharon Bowman points out in her excellent book Training from the Back of the Room: 65 Ways to Step Aside and Let Them Learn:

If learning is your goal, that is, enabling learners to remember and use the information you give them, then listening to you won’t get them there. What will get them there is involvement and engagement during the entire training – high interest, content-related, physically active involvement – where they are teaching and learning from each other.

Sharon encourages trainers to get to the back of the room and not to talk for more than 10 minutes without some kind of learner activity. This approach dovetails perfectly with the games and exercises we in the agile community have always included in our training but are only perhaps now coming to value for the intangible benefits they bring.

Two excellent books on games are Gamestorming by Dave Gray, Sunni Brown and James Macanufo and Luke Hohmann's Innovation Games.

Games enable us to get up on our feet, exercise our minds, relax and of course have fun. But games also help us learn to self-organize and work together and can spark innovation as they help us approach business challenges from different directions.

Are games childish? I hope so. I am always amazed at the openness of a childs mind, how easily they soak up new information and how eager they are to learn.

If you are considering attending one of our Rally training classes I look forward to seeing you soon as I do my level best to:

not read slides
train from the back of the room
encourage you all to be childish

What's Your Point of View

2009-12-16T10:48:00.000-08:00

As a Scotsman living in the US I take more than my fair share of trips through Heathrow airport. There are many things I enjoy about being back in the UK but Heathrow airport is certainly not one of them. For a while HSBC bank tried valiantly to cheer us up, as we trudged wearily from terminal to terminal, our journey made more colorful by the many posters from their What's Your Point of View campaign.

As an Agile Coach I am often confronted by different points of view.

If I am speaking to a group and criticize waterfall development there is a chance someone will feel I am disparaging their team or their efforts. Sometimes use of the word agile does not serve a good purpose. Many have negative perceptions of Agile and believe it to be chaotic, undisciplined and unpredictable.

As a coach it's not my job to fix negative perceptions of Agile. My passion is making teams and organizations successful. I like to steer away from the waterfall vs. agile discussion and instead focus on sharing what I see high performance teams and organizations doing.

Without knowing what value really is we can't reduce waste. A focus on customer valueanswers two key questions: a) who am I building this for; b) why am I building this. Once we have a keen sense of what value is we can then prioritize our work to deliver the highest value first.

By delivering early and often we give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can help us improve.

One of the biggest impediments to delivering early and often is the inability to reduce batch size and many teams struggle with this. This is a battle worth fighting.

Another impediment to delivering value is not pull testing forward. If we don't complete our work as we iterate then we are creating technical debt that will affect our ability to release.

Successful teams know it is best to take small incremental steps towards improvement and to establish a rhythm of continuous improvement. We don't try to define the perfect process, we don't set the bar too high and we continuously inspect and adapt.

As Émile Chartrier once said "nothing is more dangerous than an idea when you only have one". Successful teams and organizations know that to survive long-term they need to create a collaborative culture that fosters innovation and shared commitment.

Are these agile or lean principles. Some like to draw an ideological line between the two but like Wille Faler I don't believe that's a bottom-line discussion. Call them waterfall if you like so long as you're successful. You might not like the list and that's fine too. Make your own list but don't just pull it out of a book. Visit the gemba and come up with something visceral that your team can identify with.

Paper Clip Consulting

2009-11-20T07:58:00.000-08:00

Remember this guy. He used to pop-up when you least expected him and offered up information about something you already knew.

I'm sometimes reminded of Clippy when I hear the rhetoric from some in our agile community.

We're at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.

As teams from these later adopters are striving to become leaner and more agile they struggle with the inertia that is inherent in large organizations.

They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
They know that it is much more efficient to work on one task at a time but someone way above their pay grade won't let them have such a single minded focus. This is not a battle they can win right now.
They know that value can be delivered faster if testing can be pulled forward yet they don't have budget to buy the tools they need.

For such decisions Clippy always knows the right answers for everybody. But Clippy doesn’t have to walk in their shoes and it won’t be Clippy who gets fired for taking a risk.
Maybe Clippy needs to listen to Norm Kerth (from his book Project Retrospectives)

or as my colleague Julie Chickering says:

"I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship cant turn on a dime. To me this is part of being the trusted partner."

As you strive to become leaner, more agile, you don't need Paper Clip Consulting you need a trusted partner. You need someone that will begin with the end in mind yet not seek to get there immediately. A trusted partner will take the time to understand your environment, accept that there are always constraints and help you establish a cadence of continuous improvement.

All For One, One For All

2009-08-18T10:43:00.000-07:00

I was struck recently by the low energy of a daily stand-up that did not signal the end. Some people headed back to work, others started follow-on discussions, others were not sure if the meeting was over or not. The lack of a clear sign that the stand-up is over can lead to problems:

People feeling left out
Not having the right people there when decisions are made
Time wasted on interesting rather than useful discussions
People starting to question the merits of a daily stand-up that consumes a lot of team capacity

One way to avoid a never-ending stand-up is to have a clear signal at the end.

The ScrumMaster is the facilitator for the daily stand-up and they shouldn't assume the authority to close the meeting. I like a signal coming from anyone (not necessarily the ScrumMaster) followed by a response from all.

A friend of mine enjoys climbing. At the end of his daily stand-ups he would signal "On Belay?" and the rest of the team would respond "Belay On".

Sports teams are good at signaling the end of the huddle. One of my favorites is the team portrayed in the classic book by Alexandre Dumas. The Three Musketeers would end their stand-ups with a single cry of "All for one" which then be followed by the refrain "and one for all"

What are your favorite signals?

Chi Development: The Process Is The Goal

2009-06-03T09:40:00.001-07:00

Last year I entered the Marine Corps Marathon. I'd never ran more than 10K in my whole life but I felt the urge to do a marathon just once. Of course I didn't want to just finish I had to get close to my friend Dave's time who did 3:17 in the Loch Ness Marathon. So I started an ambitious training program and as time progressed and I was not getting any faster I started training more. 4 weeks before the race I had to pull out with a stress fracture and slightly torn achilles tendon.

I failed to heed my own counsel. As an agile coach I tell my students that the number one cause for failure is scaling too fast and you need to start with baby steps.

This year I'm entered again but I'm going to take it easier with the training and not care how fast I go in the race.

Looking for a better way to train I was intrigued by Danny Driver's book Chi Running: A Revolutionary Approach To Effortless, Injury Free Running.

I was fascinated reading about the Chi Running Method and Mind-Set.

The optimal conditions for running and the fundamentals of the method:

Great posture
Relaxed limbs
Loose joints
Engaged core muscles
A focused mind
Good breathtaking technique

The benefits:

Great posture
Relaxed limbs
Loose joints
Engaged core muscles
A focused mind
Good breathtaking technique
More energy!

His point. The process is the goal.

Similarly with agile/lean teams the fundamentals:

Deliver highest value first
Release early and often
Shared vision
Empowered collaborative decision making
Engaged customer proxy
Sustainable pace

The benefits:

Deliver highest value first
Release early and often
Shared vision
Empowered collaborative decision making
Engaged customer proxy
Sustainable pace
More energy!

I Don't Like MoSCoW

2009-06-02T17:16:00.000-07:00

It's OK Sergey and Boris I'm not referring to the capital city of your homeland with it's rich history, wonderful literates and great hockey players.

Instead I'm referring to the technique that the DSDM consortium recommends for prioritizing backlog items.

Must Haves
Should Haves
Could Haves
Won’t Have (this time around).

There are a couple of problems with this technique and in my classes my students spot them right away.

The customer always thinks everything is important and therefore the distribution of the backlog items is hopelessly skewed towards the Must Haves.
If we are planning an iteration and we have only room left to take on one more backlog item and we have two Must Haves which one gets planned into the iteration. Of course we should ask the customer but what if they're not there.

Many customers think that promoting backlog items to Must Haves is exercising better control over delivery but it is not. A customer who cannot differentiate between the importance of backlog items is ceding control to the delivery team. Work has to be sequenced and if the customer will not choose then the team will.

A better technique is to rank backlog items such that no two items have the same priority. In this instance it is very clear the preferred order of delivery.

Pick Up Your Clothes

2009-05-26T05:53:00.000-07:00

With a four year old and a six year old familiar sayings around our house are "pick up your toys", "pick up your clothes", "brush your teeth", "get dressed". Of course we could get our short-term objectives met much faster if we did these tasks but we don't. We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.

Giora Morein tells us that ScrumMasters's should track hours remaining on a sprint

Time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important.

While I don't question Giora's good intentions and there is no doubt this approach is expeditious I believe it is worth striving to have the team updating their own hours remaining.

There are many many benefits to being a member of a self-organizing, self-managing team but with those benefits also comes responsibility and accountability. Here are some dangers I see in team's not updating their hours remaining:

They become less accountable for the number they provide
They don't understand the mechanisms of the self-managing, self-organizing team
They become dependent on the Scrum Master
The Scrum Master becomes frustrated and disillusioned
The Scrum Masters morphs from a leadership role to a management role
The team starts to revert to form

Microcosym in a Teacup

2009-04-30T19:14:00.000-07:00

If you haven't already heard Matt Aimonetti’s talk “CouchDB + Ruby: Perform Like a Pr0n Star.” at the Golden Gate Ruby Conference caused quite the stir.

There are so many different angles to explore. Here's some that come to mind:

Although I was not offended this crossed my standards of good taste
Although hopefully not his best example Matt obviously has a talent for creating presentations
Like Giles Bowkett says if you're going to apologize then make sure you really mean it. If you don't, then defend your position
If someone from a different sexual or ethical group says they're offended then you have to take their word for it. You have and will never have a basis to refute their argument. Washington Redskins take note.
Strange that Sarah Allen didn't leave. I admire Ken Schwaber's work but recall not staying for his presentations at Agile 2007. His (lesser) crime: he was boring.
In a country where the Sopranos is such a popular show why is it not OK to have a few PG-13 pictures in a presentation
In a male dominated industry is it discrimination to treat others differently or is it discrimination to not
This presentation probably would have been a hit in the UK. I'm hoping John is alluding to my British upbringing when he remarked that "of course you weren't offended"
Why are the US and the UK (two countries I love) so different
But of course this was not the UK so Matt really broke rule #1: Know Your Audience

Fortune Cookies and Process Improvement

2008-03-20T08:46:00.000-07:00

Yesterday I was at the Rational Comes To You Seminar that we hosted in Chicago. I presented a favorite topic of mine Agile Risk Management. The keynote speaker was Per Kroll. Per talked about the Agile Practice Library that the Eclipse Process Framework team are developing, an initiative that we are actively involved in. Dan Gilio and Frank Du Pont gave a presentation on Agility and Compliance and laid to to rest perceptions that agility and compliance are not polar opposites. After all, think about it, how does a waterfall process help with compliance? Great job Dan and Frank.

I was listening to NPR on the last leg of my journey home from Chicago. Michele Norris was interviewing Jennifer 8 Lee about her upcoming book The Fortune Cookie Chronicles. Jennifer was born in America of Chinese parents and was perplexed why the food in the little white takeout boxes was so different from her mother's traditional Chinese dishes. Then when Jennifer was 13 she discovered fortune cookies weren't Chinese. "It was a disconcerting discovery, like I was adopted and there was no Santa Claus at the same time. In a way, I had bought into the myth of what is really 'Chinese,'" she says.

This led to an obsession that eventually led to her upcoming book. Jennifer's research yielded that an overwhelming majority of fortune-cookie "fortunes" originate from one of two sources: Wonton Food in New York City or Steven Yang, who works out of a warehouse in California where fortune writers craft bits of wisdom that meet an American audience's expectations. Amusingly these fortunes don't translate well in Asia where negative feedback is welcomed because it is seen as essential for improvement.

What an interesting day. It started out with Per talking about agile practices and expounding on lean methods and it ends up back at lean with a real-world Kaizen example. For those Fortune Cookie afficionados out there this blog would not be complete without me adding that shortly after listening to this story I ended up sound asleep "in bed".

The Search for Scorpion

2007-11-01T19:06:00.000-07:00

On May 27, 1968 USS Scorpion was reported missing with ninety-nine men on board. Nobody had any idea where Scorpion was or what had happened to her. All they knew was that the 3,500 ton nuclear attack submarine was due back in Norfolk, VA and had failed to arrive.

Dr. John Craven, the Chief Scientist of the U.S. Navy's Special Projects Division had been instrumental in locating a missing Hydrogen Bomb off the coast of Spain on January 17, 1966 and he was to play a key role in locating Scorpion.

Craven and his team of mathematical consultants launched a search that would take so many twists and leave him so at odds with the rest of the navy that he himself would begin to wonder whether he had indeed gone mad.

Craven and his team together with Wilton Hardy of the Naval Research laboratory and his team of acoustic experts examined the acoustic data. Hardy found it first. Right on Scorpion's track was an explosion strong enough to tear through a steel hull and 91 seconds later there was a series of much louder blasts as the submarine began imploding as it sank to the bottom.

The site of the first explosion – codenamed Point Oscar marked where the search would begin. The water at Point Oscar was 2 miles deep. The Scorpion would have stopped imploding about 7,000 feet before she hit bottom, cutting of the acoustic trail. Depending on how fast she had been traveling, and in what direction, and depending on the force of the implosion and the position of her stern planes as she fell, she could have been thrown miles further. All that meant that the submarine could be anywhere within a 20-mile-wide circle, leaving a vast unknown universe to search.

Craven began digging for more evidence. He set about trying to map each implosion in the hope that he could figure out how far scorpion had traveled before the final sounds of her loss subsided. Craven's map showed that Scorpion had not been traveling west toward Norfolk during her final moments. Instead Craven's calculation surprisingly showed that the submarine had been moving east back toward the Mediterranean. Craven asked several captains and admirals "what would make a submarine go in the wrong direction". Each time he got the same answer. A submarine turns around 180 degrees when a torpedo activates when it is still on board. The boat turns because that triggers fail-safe devices on the torpedo shutting it down.

The only problem was that nobody of any rank from the chief of naval operations on down thought Craven could be right. Craven persisted, he began to mathematically construct a map of the ocean bottom, using Bayes' Theorem of subjective probability to draw on the knowledge that even experts are not consciously aware they have. After Craven explained to the Navy brass that he was going to use a system of Las Vegas-style bets to factor the value of hunch into his data, some of the operational commanders were convinced that he had gone completely over the edge.

Undeterred Craven asked a group of submarine and salvage experts to bet on the probability of each of the different scenarios being considered to explain scorpions loss. Once the bets were completed Craven sat down to draw a probability map. The calculations concluded that the scorpion was east of Point Oscar, 400 miles from the Azores on the edge of the Sargasso Sea.

Years later mathematicians would write a book based on their work with Craven entitled Theory of Optimal Search, the U.S. Coast Guard would adopt the method for search and rescue and the navy would use Craven's interpretation of Bayes' Theorem to locate sunken ordnance in the Suez Canal.

Yet in the Scorpion search naval officers just shook their heads and continued to look to the west of Point Oscar. Months passed by with no trace of Scorpion. By October with the weather worsening Craven finally persuaded the navy to look east of Point Oscar. On October 29, five months after she had been reported missing Scorpion was found within 220 yds of where Craven, his mathematicians and a group of experts betting for a bottle of Scotch had said she would be.

The above is an abridged version of a chapter in the book Blind Mans's Bluff: The Untold Story of American Submarine Espionage. The book is a great read but one might wonder how it relates to our business.

There are many good lessons to be learned from the book but what is particularly interesting is the technique Craven used to draw on the knowledge that even experts are not consciously aware they have. Not only that but it is impressive the quality of the estimates. We deal with uncertainty in our line of business. Most notably in risk management.

When we implemented our agile risk management technique we used a modified Delphi technique to increase our confidence in a series of subjective measures. However, the word subjective always bothered me. At the time intuitively I knew that behind the scenes of every expert judgment was a series of decisions based on real experiences through the years and just because those data points were not discussed or written down did not mean they did not exist. They perhaps just flashed through someone's mind quicker than a value remains in a register on a chip but they were there. I really did not have any science to back up this theory but then I read Blind Mans Bluff and there it was, a real-life example that worked and was backed up by science. I think if we had known about Craven's work and Bayes' Theorem at the time we might have been able to make a much stronger case for the validity of our approach. An approach that at the time yielded some alarmingly high numbers yet reflecting on them now, our team of experts were also spot-on.

Kaizen

2007-08-28T17:28:00.000-07:00

Only after American carmakers had exhausted every other explanation for Toyota's success - an undervalued yen, a docile workforce, Japanese culture, superior automation - were they finally able to admit that Toyota's real advantage was its ability to harness the intellect of 'ordinary' employees.", "Management Innovation" by Gary Hamel, Harvard Business Review, February, 2006

Taiichi Ohno (February 29, 1912 - May 28, 1990) is considered to be the father of the Toyota Production System, also known as Lean Manufacturing.

When I attended Mary Poppendieck's presentation on The Role of Leadership in Software Development at Agile 2007 she talked a lot about Ohno and had a marvelous quote from his book Workplace Management.

There is something called standard work, but standards should be changed constantly. If you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen [change for the better]. Standards are set arbitrarily by humans, so how can they not change? You should not create these away from the job. See what is happening on the gemba [workplace] and write it down.

When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve 'the best way.' This is a big mistake. Document exactly what you are doing now. If you make it better than it is now, it is kaizen. If not, and you establish the best possible way, the motivation for kaizen will be gone.

One way of motivating people to do kaizen is to create a poor standard. But don't make it too bad. Without some standard, you can't say 'We made it better' because there is nothing to compare it to, so you must create a standard for comparison.

We need to use the words 'you made' as in 'follow the decisions you made.' When we say 'they were made' people feel like it was forced upon them. When a decision is made, we need to ask who made the decision. Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

But in the beginning, you must perform the Standard Work, and as you do, you should find things you don't like, and you will think of one kaizen idea after another. Then you should implement these ideas right away, and make this the new standard.

Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, 'The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.' I said 'What do you come to work to do each day? If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.'

At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying 'Have you been goofing off all month?' If it takes one or two months to create these documents, this is nonsense.

I found this very profound. I saw ghosts of many failed and failing projects pass before my very eyes. First with Rational and then Number Six I've been lucky enough to work with some great people with a passion for change. They find it hard when customers do not embrace improvement so readily. I don't think they set expectations that cannot be met but, they are perhaps naive to assume they will be met immediately.

Maybe it's time to consign to the scrap heap that silly phrase "set the bar high". After all, a high jumper may have lofty ambitions but, they do not set the bar high, a high jumper sets the bar low and then gradually increases the height as they become more comfortable.

Maybe we can draw some inspiration from Taiichi Ohno:

Set realistic goals for improvement, goals that can be achieved in the short term
Continuously challenge and improve processes
Define processes at the workplace not in the laboratory
Remember that people are much more likely to follow through on a commitment they made than one that was forced upon them

A Process Definition Is Not a Process

2007-08-07T17:14:00.000-07:00

It hit the desk with a thud. "What's that?" "Oh, that's the Risk Management Plan." "Great, let's see the Risk List?" "Oh, we didn't bring that, it's on Tony's laptop somewhere."

This was a real conversation. We were meeting with some of the staff in the PMO and they had brought their Risk Management Plan for review. It was an impressive document with 65 pages of everything you ever needed to know about risk management. This was the culmination of weeks and weeks of effort and many meetings. The sad thing is that in the time they had spent documenting the process they could have collected, analyzed and responded to all the program's risks and been in a much better position to ensure program success.

You don't need to spend weeks and weeks defining a risk management process, it has already been documented to the finest level of detail and there's not a lot of options to ponder. Likewise, you don't need to spend hundreds of thousands of dollars to be told that you need a change control board (sadly another true story).

As real process engineers will tell you, a process definition is not a process. Instead of spending months and months documenting processes it is far more effective to reference existing documentation. Keep the process simple and transparent so that it can be easily implemented and iterate often in the early stages to right size the process to fit the team. Remember a process definition is not read but referenced, so make sure it is small, online and referenceable.

Drivers Never Get Car Sick

2007-08-02T16:42:00.000-07:00

I recall one day sitting in a meeting when our project's sponsor, very proud that our team had just delivered a release on-time and under budget gave a very passionate speech to our team about how proud she was to have worked alongside us and how we had triumphed over adversity. It was very touching and heartfelt but she lost my vote when she stated that process cannot be allowed to stand in the way of innovation.

I agree in spirit but why is process perceived as counter productive and stifling. The main benefits of process are not control but rather ensuring best practices are repeated and people understand the direction the project is going to take.

Did you ever notice how drivers never get car sick? The reason is of course that they know where the car is going. On this particular project we had a lot of very sick passengers. As a driver of a car you can take some steps to avoid your passengers getting sick:

make sure they know where the car is going
keep them talking and involved with others
make sure they keep focused on the road ahead
keep them involved in tactical decisions such as speed and direction.

Applying that analogy to our project drivers can keep their team productive, engaged and healthy by following a few simple steps:

create a simple roadmap to ensure everyone knows the direction and there are no unexpected changes in direction
continuously talk to the team and communicate progress
make sure the team does not lose sight of the end goal
ensure that the team has visibility and input into project direction.

Lastly, don't let stubborn pride get in the way, if you're lost, stop and ask for directions.

Listen Carefully For That Tearing Sound

2007-07-09T17:01:00.000-07:00

Last weekend I was hanging drywall in the bathroom that I am remodeling. It's a lot like developing software. If the framework is sound then the biggest risk is wondering whether you can do it in time as opposed to worrying that it will all fall down.

Hanging drywall is easy if the studs are all the same width, not warped and bowed and all the angles are 90 degrees. But, of course, this is the real world. Even with new construction, it is very time consuming to find perfectly straight studs and even if they start straight they move over time. You can buy studs made from engineered wood that are very straight and stable but they are expensive and you can't just pick them up anywhere. But if it is not new construction then we just have to make do with what is already there. Luckily drywall has a bit of flexibility so you can hang it on studs that are not perfectly straight and you can patch it later if there are some gaps to fill.

I was hanging a particularly heavy drywall sheet. I had the sheet balanced on my raised knee, my left hand was holding the sheet firm to the wall, two drywall screws between my teeth and a cordless drill in my right hand. I quickly managed to drive the two screws into strategic positions and was able to free up my left hand to get more drywall screws. When I heard that ever so slight tearing sound I knew I had to move fast. The drywall wanted to move in a different direction from the screws and as it pushed back against the screws, the paper on the drywall was very slowly tearing as the screw head started to work its way through the sheet. I was lucky this time, I was able to add more screws and spread the load but if I'd had the radio on I might not have heard the ever so slight tearing sound.

Similarly with software development sometimes you have to make sub-optimal decisions based on different constraints but, you can still proceed to deliver a successful solution. However, it is very important to keep your ears open and tuned in so that you can repond quickly to any tearing sounds.