Let’s Play!


Polar bears playing with dogs. Attuned right brains. Play as a driver for innovation. Great problem solvers are good with their hands. Full of interesting information that points to play as a practical tool for work and life. Tired of boring meetings? Try play – an out of the box suggestion in this video. Playing helps you think and do better – and helps build better teams.

Enjoy!

Perfection and Pragmatism


This is a long post, so here is the digest version first.

  • Develop a vision of perfection for your Agile business that includes the product AND the people that create it.
  • Think about what it feels like to work in this perfect Nirvana – engage your right brain.
  • Start moving toward that vision now as fast as you can without losing control – be pragmatic.
  • Be prepared to suffer some mental pain along the way – so eat cookies and drink milk.

That’s it. The rest of the post is some ranting to prime some thinking.

Continue reading

Software – Artistic and Innovative Expression


Creating great software is a lot like creating great music. Both require skill, practice, and technical knowledge. Both require creative thinking, collaboration and involve good judgment. Both have an end-customer. Both have a user-experience.

As software professionals we have deadlines. So do musicians. I think about being in a studio, engineer behind the console, producer on the clock, and you gotta create. Pressure… You often hear about the emotional war that takes place between band members, in many respects similar to what software teams go through. You want to add that great new riff you invented, and you search for a place to insert it but sometimes, you just have to save it for another day because it adds weight without value. Similarly, code bloat also occurs because a team member wants to make something cool happen in the code that does not add value. We often hear the words that musicians should “check their egos at the door”. This was made famous by Bob Geldof during Band Aid, the huge Ethiopian famine relief benefit. Bob insisted that the event was not about the musicians, but about helping those in need. As software professionals we can all take a page from that book. Set our egos aside. Create something of value for our customers. Celebrate the success together. Learn from our experience and make the next one even better.

Continue reading

Learning to Drive – Decision Making on the Fly


When I was 16 years old I got my learner’s permit and had a part-time job. My boss was was a really great driver. After work we’d hit the road. He taught me how to do double-clutch downshifts to match the RPMs of the next lower gear before executing the downshift. He taught fundamentals like learning to drive smooth. Nothing is jerky. No clutch dumping. No whipping the wheel into a 90 degree turn. The idea was to get the best performance out of your car without damaging it, and always staying in control, but on the edge of losing it.

I learned how to take a roundabout at high speed without losing control–feathering brakes, clutch and accelerator to transfer vehicle weight in and out of turns. Downshift into the turn to transfer weight to the front wheels so that they bite (but not too much). Accelerate on the way out at the apex to transfer weight to the back wheels and get maximum acceleration out of the turn (but not too much). He taught me about the line of a turn, and how to take best advantage to maximize speed. “Remain tangential to the outside on the way in, on the inside at the apex, and back to the outside for the exit.” I’m no race car driver, not will I ever be, but what I learned has saved my life at least once. Hesitate or miscalculate and the consequences can be disastrous.

Think of the decisions that need to be made, and the skills required to execute a high-performance drive. Demanding high-performance execution without training your driver to execute and make decisions in real-time guarantees sub-optimal performance and high risk failure. Deciding when to downshift to transfer vehicle weight taking into account road conditions, tire temperature, and your vehicle’s capabilities takes practice. The driver must learn to become one with the car. You can write a driving manual, with every conceivable detail captured, but putting that manual in the hands of a novice driver and expecting the driver to deliver high-performance is naive. Think about all the implicit knowledge that influences your decision making on the road. The sound of the engine, the feel of the wheel, the sound of your tires on the road, your instrument panel. Imagine putting a top-notch driver in the passenger seat and having her tell the novice driver what to do and when. How effective would that be? Better than a driving manual, but not the best. Driving takes skill and practice. The skills are implicit. Until you experience what your car can do and how you handle it, you don’t really know how far you can push towards high performance. Put a high performance car in the hands of a novice and you can end up with a wreck.

The ability to deliver high performance execution comes from experience. It’s the applied knowledge accumulated through trials, failure, feedback, and the development of the sixth sense that aggregates the sensory inputs with one’s experience to deliver real-time, high performance decisions.

If you have read Malcolm Gladwell’s Blink, you know what I am talking about.

How are you coaching the “drivers” in your organization?

Mike Cohn on Team Structure


I read a blog post by Mike Cohn on the Nine Questions to Assess Team Structure.

Some of the takeaways and questions I found relevant are:

  • Organizations often build short-lived project teams that disband at the end of a project. Is there a way to minimize team churn in this environment? Is it is possible to build cross-functional feature teams that can persist over multiple feature deliveries?
  • Sometimes the need for a specific skill is not required for the life of a project. Some expertise is required to deliver IPSec for example, but the individual with this knowledge could work with multiple teams. How do you enable the skills transfer to multiple people so that no one individual has to be involved with more than 1 or 2 teams?
  • Will your team structure minimize communication paths and enable communication between technical experts who would otherwise not communicate together?
  • Does the team structure make accountability clear?

Creating these teams implies the building of redundant skills and overlap. This helps to create teams with no single point of failure–a necessity for business continuity. Doing so may feel inefficient. The value is reduced project risk, smoother flow, better throughput, and happier teams. If you are forced later to move team members between projects, the redundancy you build in gives you added flexibility and agility.

Creating teams is not just about maximizing short-term value for the project. It is about balancing the short-term needs of the business while building in long-term flexibility and resiliency of the teams and their capabilities to support the goals of your business. Don’t think of this as a trade-off. Think of this as an integrative process that gives you the best of both worlds over time.