When a company has made some inroads to being agile it seems as if something is always under construction. A process, a team, the software… something. On a real construction site, it’s a hard hat that provides some degree of safety. LOOK OUT! The same might be said for an agile environment. But within the context of thinking caps, I think of a hard hat as a mode that seems to be stuck, frozen. There is something to an agile environment that puts us into the edge and makes explorers and problem solvers. There are always a few that seem to hunker down and are really uncomfortable with the participation. Sometimes it is trust, sometimes it is a slower rate of acceptance… the reasons are legion. A good way to take some team members and start them down the road to perspective and context switching is Edward de Bono’s 6 Hats Exercise for a retrospective. Now this isn’t a Scrum thing, but it is a way to get team members to become flexible thinkers. To describe it quickly – each of the six ‘thinking caps’ represented by a color has it’s own way of thinking. Take a look. Black- critical, Yellow – optimistic, White – factual, Blue – process, Green – creative, and Red – intuitive. Scrum masters might want to switch up their entrenched black and yellow thinkers in order to move a team forward and get them to be agile thinkers. Mix it up, rotate or randomize.
Lincoln once said that if “I were given six hours to chop down a tree, I would spend the first four sharpening the axe.” In his wisdom Lincoln was differentiating between activity and achievement. Something John Wooden as a coach would often tell his teams were two very different and distinct things. Activity. Achievement. Scrum teams often have to use this disruptive innovation to focus at a level of thinking. Are we tasking? Or maybe we are using this next (some-time box of) minutes to talk about and clarify our stories, features, epics, releases, product, or portfolio?
Now, as a manager or a project manager, I occasionally hear something that goes to the effect. ‘Why are my developers in a meeting? They should be coding 100% of the time” I try not to sigh noticeably. This, is after all, where the some of the organizational terra-forming begins. It can be a mistake made by some traditional practices. It is more surprising to continue to uncover this years into an agile adoption. But make no mistake, I am always glad to bump into it. We can’t get to the correction which makes it right until we are speaking openly and truthfully. There is an echelon of QA and test professionals that echo this mantra. However, I’m not usually the first to bump into the mentality – which means it is rather a rigidness of thought that has a tendency to persist until it meets with its paradigm shift. Some one buried in activity has little time to change how they work, let alon how they think. We advocate and support it should be expected instead some time is spent to focus on improving how we work. Kaizan.
Agile does more than just re-arrange the way we do our work. It changes how we think. Software is problem solving and some pretty hard thought work. If there is a difference between achievement and activity – the axe that we should spend some time sharpening – it is our own minds. Other tools and processes certainly fly into the mix, but the interaction still leverages our ‘thinker’.
A rigidness of thought. The thinker might have stalled out. Ever meet that contrarian person? Just so negative all the time? To go the opposite extreme and be perennially optimistic can sometimes lead to solutions which might not be robust. We need everyone to be agile thinkers to get this software to done. I think I can… I know I can set aside my hard hat as we improve the software, ourselves, our team, and the organization.