Tag Archives: team culture

A few weeks ago I posted about the relationship between organizational culture types defined by William Schneider in ‘The Re-Engineering Alternative” and MBTI types and temperaments. My theory is that as a change artist, whether it be an external or internal coach, can you increase the odds of creating a successful change by understanding these factors:

organizational culture type

type and temperament of the influential people or ‘change sponsor’

flow of power throughout the organization

I am still learning about this and refining that theory. Here’s a quick example, suppose you, as a change artist, are brought in to transform an organization to Agile. Suppose this organization is a control culture (likes rules, process, stability, hierarchy and power) and the change sponsor (VP or Director or whoever brought in Agile, let’s call him Rick) has MBTI preferences that lend themselves to align with the attributes of a control culture.

Rick may be more likely to see ‘Agile’ as a set of processes and practices over a set of values and principles. As a change artist, an Agile Adoption approach may make more sense. ‘Adoption’ and ‘Transformation’, IMO, are different. Transformation is transforming an organization’s culture to build a learning culture or Agile mindset. Adoption is adopting Agile practices and processes for perceived benefits that are (or at least seem) concrete.

As a change artist providing a less ‘fluffy’ and values/principles approach in favour of a more pragmatic approach of a list of processes and practices with benefits, possible outcomes and an implementation plan increase the odds of a successful change. Continue reading →

I attended a great session on Agile vs Traditional last night with the Toronto Agile group and while there weren’t many traditional folks there, the session helped validate much of what I believe is the most important aspects of ‘becoming agile’. Continue reading →

Uncle Bob (A.K.A Bob C. Martin) posted an interesting thought about his keynote from Agile 2008. The idea was a metric for code quality as measured in “WTF’s per second”. That is, during a code review, how many times you see code that makes you say “What the F***?”

I’ve always thought that the underlying principal of Agile practices, particularly Scrum, already preach about quality software. The goal is always potentially shippable and bug-free software so maybe it’s the optimist in me, but shouldn’t the programming methods used in Agile development (pair programming, TDD etc) already police against writing crap?

If developer A writes crap and then code reviews it with developer B, I would fully expect developer B to point out what’s wrong. I don’t think anybody wants to churn out crap for the sake of getting something done and I can only see lack of knowledge or experience being the culprit. This lack of knowledge or experience should be able to be fixed through Agile processes. If a team member is struggling, help them. If a team member is knowingly churning out crap, try and help them or boot them off the team.

I don’t think we need to update the Agile Manifesto to state the obvious.