CoP – How to get one up and running


Communities of Practice are a solid way to help experts in their field stay on top of the latest in their domains. They also help managers and leaders create a collaborative learning culture.

A CoP is a forum where experts meet together on a periodic schedule to share and learn from each other. It can be a one hour event every other week or from time to time, a mini-conference using an open space or trade show format.

I like to see managers or leaders shepherd or curate CoPs. A CoP needs care, feeding, and leadership to get off the ground and remain useful. The best CoPs I’ve experienced have the following characteristics: Continue reading

Co-Creation presentation from Agile2013


Last week I presented a talk on Co-creation at Agile2013. It was well received and at least for me, made it clear that co-creation is a challenging topic that requires intestinal fortitude to execute successfully.

Co-creation


Given the blistering rate of change, increasingly savvy consumers, and a noisy market, businesses must change the way they engage customers, particularly for new product innovation. Here, the requirements are nebulous, ever-evolving, and customers have as vague a notion of what they really need as their suppliers do. There are tools for navigating this grey-zone of ambiguity. One of them is co-creation.
Continue reading

Whole-Team Dynamic Organizational Modeling a Success at Agile2012


Yesterday, Catherine Louis and I delivered our three-hour workshop on “Whole-Team Dynamic Organizational Modeling” at the opening of the conference. It was well-attended–standing room only. Our colleague, Neil Johnson wrote about in his AgileSOC blog here. InfoQ wrote an article about it here. Thanks to Shane Hastie of InfoQ for attending and sharing our work with everyone.

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