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!

How Adopting Agile can Lead to Business Failure


For Agile veterans, this list of failure reasons is not new. But it never hurts to be reminded of what they are.  So here is the list by Clinton Keith and Mike Cohn. I wish everyone would read this list and post it on their bathroom mirrors. You can find the source document here.

  1. Don’t trust the team or agile. Micromanage both your team members and the process.
  2. If agile isn’t a silver bullet, blame agile.
  3. Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
  4. Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
  5. Undermine the team’s belief in agile.
  6. Continually fail to deliver what you committed to deliver during iteration planning.
  7. Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
  8. Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
  9. Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily stand-up.
  10. Don’t communicate a vision for the product to the team or to the other stakeholders.
  11. Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
  12. Replace a plan document with a plan “in your head” that only you know.
  13. Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.
  14. Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
  15. Drop and customize important agile practices before fully understanding them.
  16. Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
  17. Don’t continually improve.
  18. Don’t change the technical practices.
  19. Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
  20. Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

Bad Decision Making


I tried an experiment with a few colleagues over the past couple of months based on Karl Popper’s famous experiment for confirmation bias. The results have big implications on how we can easily head down the path to making bad decisions.

The experiment goes like this. The experimenter gives the subjects a 3-digit pattern, “2 4 6” and asks them to write the rule that makes any other pattern conform to the same rule. The subjects may ask questions in the form of another pattern. For example, a subject may ask if the pattern 1 2 3 conforms, and the experimenter will answer either yes or no depending on whether or not the pattern conforms. After several attempts, the subjects write their “rule” for the pattern.

For example, subjects may ask:
“Does 4 8 12 conform?” The answer is yes.
“Does 6 8 10 conform?” Yes.
“Does 3 6 9 conform?” Yes. And so on…

Confirmation bias guarantees that you will ask more questions that get answered with a yes than with a no. The reason is that you start to build a model in your head of what the pattern conforms to, and you go about proving that you are right.

The answer to this puzzle is that the numbers must be increasing in value from left to right. (a < b < c). All someone has to do is offer the question “Does 2 3 1 conform?”, and you quickly start to converge because the answer is NO. One of my colleagues supplied negative integers (-2 -4 -6) and the answer was no. This led to some debate among the pair and they were far faster at converging than when they got yes answers.

I did the experiment with a pair of programmers and another pair of people, a programmer and a tester. The programmer-tester pair won. Why? Testers have the mindset of disproving rather than proving. Programmers like to prove their design works. Testers like to break features. Ironically, two testers in a pair don’t always do as well as a designer-tester pair. The diversity of the pair is what helps create the conditions for rapid convergence. Try this simple experiment yourself and share the results. The experiment is described in detail at the Developmental Psychology web site here.

Confirmation bias implies you filter and interpret data to support a belief you already have. The debate on Gun Control is an example of how the same data is interpreted different ways by people with differing perspectives. To increase government spending or reduce taxes to stimulate the economy is another debate where confirmation bias plays a role. There are huge implications for decision making. Human beings try to fit data to support their beliefs. Forcing yourself to disprove a hypothesis is powerful.

If you are responsible for delivering high quality products, what are the implications of confirmation bias on how you work? What can you do to create healthy team diversity and conflict which leads to better collaboration, and ultimately, better products?

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.