Follow by Email

Tuesday, November 6, 2012

Team Tips – 11 {Myth busters}


One of the many, many, many things that one learns from the Core Protocols and the concepts in Software for Your Head by Jim & Michele McCarthy is that axioms we have been taught elsewhere about teamwork just aren't necessarily true. In other words, these “axioms” are more correctly  accepted wisdom, rules-of-thumb, even assumptions, that need to be verified and validated.

Just as once we thought the universe revolved around the earth – with really obvious evidence – we have learned that this knowledge, once taken to be fact, is actually wrong. Similarly, a lot of the accepted wisdom about the behaviours of successful teams, has not survived the living laboratory of teamwork we know as BootCamp. From teams' experiments in BootCamp we have captured essentials of great teamwork in the Core Commitments and the Protocols – the Core.

Some of these axiomatic falsehoods about teamwork we previously accepted from training or experience include:
  • teams need to be led by an appointed leader
  • teams need facilitation
  • team decisions need consensus
  • effort matters
  • all team members have to work equally hard
  • the best ideas come from the tenured members
  • unsolicited feedback is useful
  • emotions shouldn't be allowed
  • conflicts should be set aside
  • there is no “I” in “Team”
  • etc. (I'd like to hear about your list)
But one of the bombshells concerns a myth of Project Management in an intellectual property development world.

Anyone who has worked on a project, or been taught classic project management thinking, knows about the scope, time, resources triangle. Given X resources on the team, to produce a Y scope of work, in Z time, we can visualize the triangle with sides X, Y, and Z. If one of these sides is to shorten or lengthen, then clearly the other sides must flex or else the triangle breaks and the project fails.
We can all think of many examples where that appears to be self-evident. If I decide I want a second story on my one floor bungalow in the middle of building the house, then the contractor will certainly tell me it will cost more money, more materials, more equipment, more builders – in short more resources.

So how can it be that teams using the Core and the experiences of BootCamp are successful with the Intentional Development Protocol which says:
There is not a rigid triad of time, resources, and scope as you may have been told in your project management class. The triangle is in fact an angle with an infinite space between the two lines. The infinite space is the “resources” space. Maximizing the human potential of your team, your resources, can overcome any deficiencies you feel in the time and scope domains. Your belief that you don’t have enough time or too much scope is the signal to you that you are not being receptive enough to what’s available to you.
And that statement is from Jim McCarthy (Bell Labs, Microsoft) who had previously promoted the classical triangle is his previous book The Dynamics of Software Development!

What gives? How can a finite team have indeterminate / unlimited / infinite resources?

One clue from the BootCamp experience is that in the realm of creative production one never knows when or from where the next good idea will appear. When the resource constraints are simply the minds available to the team, and the team knows how to best access these resources, that side of the triangle starts to bend, balloon, flex, wiggle, and expand, if not vanish.
If the team's focus is on delivering quality features for this milestone at this deadline, and the Simple Rules and Tools of the Core are familiar to them, then there is virtually no limit to whom, and when, they might ask for help in getting results.

Compare that to a team not having been to BootCamp, working the traditional paradigm of time, scope, and resources. The resources they perceive available to them are primarily, if not exclusively, the individuals on the team. They may or may not even ask each other for help on their own tasks. If they do ask for help, it is often restricted to non-significant issues - certainly nothing that is frightening to them: challenging egos, being vulnerable to appearing lacking in knowledge or capability, giving up on positions of power and influence from seniority or status, etc. They don't naturally ask for help quickly and easily from those outside the team, the department, the company, their locality, the world at large.

When this group gets into trouble with delivering quality on time, they do all the standard things: put in extra hours and effort, de-commit from scope by dropping features or the depth of features, ignoring quality, asking for more team members or different skill sets, changing timelines on task achievement or overall deadlines, focusing on "easy" stuff, not testing, not prototyping the end product, getting sick, spending more energy on working out options, excuses, blame, tossing the issues in the project manager's or boss's lap, etc.

The team that has been to BootCamp knows they don't need to do any of the above.
  • They know they can ask anyone anywhere around the world for help. Just asking alone often provides the answer that was waiting to be found in their own minds.
  • They make quick unanimous decisions about this new insight based on their shared vision of the outcome.
  • They convert planning time into building prototype solutions to check the boss's and or the user's acceptance.
  • They spend their energy on results – the results they agreed in advance they could produce.
  • Their focus and energy dilates time – they get better work done faster.
  • They are receptive to opportunities that appear spontaneously, perhaps are strange, unclear, yet somehow align with their vision and resolve an issue, add quality, provide a shortcut, help meet the deadline. This receptivity is key.
Impossible isn't it? And of course, the sun revolves around the earth – until one gets a new perspective. Then...

Myth busted.