Where Culture meets Software
(This is a four-part blog addressing Process and Tools within Software Culture. This fourth part discusses our misunderstanding of Culture.. Part 3 can be found here.)There seems to be this thoughtful, slowly growing community of IT folks who believe that the future of Software Development (Agile or not) is about people. Not processes and tools – but Culture.
With the need for higher degrees of individuals & interactions demanded by this movement, both IT and business still appear to be answering this evolutionary call with more processes, tools, gate-keepers and hierarchical accountability structures.
"Bureaucratic cultures use procedures and structures to organize and control people and performance. Roles and duties are clearly defined and bounded, as are rewards. Each level and part of the organization has a defined set of responsibilities and authorities." – Esther Derby. ("Observations on Corporate Culture and Agile Methods.")
We want to fit people into the cogs of a process or tool, then force fit that tool and process into a Corporate structure – mostly because of our historical bias of 100 years of high-throughput, industrial age, mechanized production lines. Traditional Management still insists that people be measured by how well they conform to the process or tool. Unfortunately, IT aggravates it's own progressive agenda with these "solutions."
Perhaps Agile processes and tooling is getting in the way of its own tenets.
The Cultural Hope for Processes & Tools
I understand the concept that a process, tool or framework will contain the hope that cultural change will emerge from its intent. From an IT perspective, it seems so very logical to us that given the right tools and processes that high-performing cultures should arise because we are making lives easier. But addressing culture sideways like this is not a guarantee. The Agile mindset involves a cultural shift in organizational interactions – not just IT/Business structures.
If the hope is that our processes and tools will promote innovation via the practice of collaboration, is that a guarantee that innovative, strategic learning environments will emerge?
Placing a Honey Boo Boo type in a collaborative Agile team environment is not a guarantee of intellectual osmosis. Conversely, if a Honey Boo Boo type is the Manager keeping a good team down, a new structure *might* allow something better to emerge.
SAYING that we value the Agile manifesto tenets does not mean we're suddenly smarter by adhering to some latest institutional framework.
- Does a big-visual board make us smarter?
- Does a time-box/iteration guarantee a superior product?
- Can a process or tool create Team ba?
Our love for processes and tools highlights our misunderstanding of human Interactions.
Even IBM, historical stalwarts of Waterfall heavy process, is getting this!
"The Agile Manifesto clearly puts more value on the side of human collaboration and embracing change over updating tools or alignment with plans and contracts. However, teams tend to focus on the tools and processes and discard the major, essential enabling factor behind these tools and processes, which are the humans who will be using them." (Full article here)
Processes and Tools don't solve problems – People do.
From an IT perspective: We shouldn't be asking Developers if they're Agile. We should simply be asking what they believe is the relationship between Processes & Tools over Individuals & Interactions. The emphasis is on the skill – NOT the institution.
It is Principles over practices, and Values over dogma.
From a Company perspective: We shouldn't be asking our developers to address your Company Cultural issues of communication and politics. Like HR, IT hears this stuff from all angles and there is no software, process or tool in the world that can fix that. And seriously, do you really want the department you have communication stereotypes about fixing your culture?
Solving the Individuals & Interactions dysfunction requires a different solution set, one I'd suggest is outside of our discipline. And because it's not our major emphasis, we continue to fail in the eyes of our clients by providing technology based solutions.
Is this our industry limit in being able to provide solutions?
This is a human problem – not a technology problem. Perhaps we should be seeking the help of other disciplines – disciplines whose focus is HR, Company Culture and Communication. The medical community has adopted this principle in the form of cross-disciplinary teams. Perhaps we should too.
Right, we're not saving lives, but, we're meant to be making lives easier – including our own.
Great stuff, Brett. This is exactly why I like working in small business. We don’t build the barriers of forms and processes to get stuff done; we pick up the phone or walk down the hall and talk to the person. Everyone has to pull their own weight, or the whole team loses.
Thanks for sharing!
Pingback: Our IT Process Wars | SilverFern Software