How to mislead teams with irrelevant processes

Agile. KanBan. Scrum. Lean. SAFe.Waterfall.

Different names, different styles, different flavours. Each methodology attempting to somehow get a bunch of people with diverse skillsets, different backgrounds, locations, expertise, and motivations to work towards a common goal.

As always the intent is great. And then somewhere along the way we lose the plot. No matter what process we follow, we all eventually revert back to our good old styles of breathing down people's necks, stress, anxiety, distrust, finding fault and polish it off with last minute frenzy.

Does it matter what methodology you follow? More importantly, is the methodology at fault here? Is it right to create a cookie cutter approach for any goal, any team?

Getting things done isn't easy. Doing something yourself is a lot easier than getting someone else to do it. It's harder to get a group of people to do it. Difficult when you have to get a group of arrogant, smart people to do anything. Even more challenging when it comes to dealing with highly creative, passionate people.

That's where the fundamental philosophy behind blindly following these frameworks is flawed. Process frameworks don't account for the human element in software development. We overlook the nature of software development, and retrofit meaningless borrowed practices.

We need to stop misleading ourselves that a defined process will turn our teams into functional, dependable, predictable software makers. Below are a few things we need to stop doing immediately.
Treating people in software as an assembly line workers in a car manufacturing unit. Churning out code is not the same as fitting nuts and bolts on car parts. It is not a mechanical skill. Building great software involves a lot of creativity. So, any framework that treats software teams as a factory unit is a piece of garbage. People are not machines. So why are we more keen to learn software processes from the Toyota car factories? What have we learnt from the umpteen software projects? We are meant to be creators, and dreamers. Not automatons. We need to internalize this.

Expecting predictable, repeatable results. 

Building software is an art. Projecting delivery metrics based on presumptive estimates is futile. Imagine asking Da Vinci how much time he would take to paint something like Michelangelo's Sistine Chapel. Well, he can base it on, say how much time he took to paint the Monalisa, extrapolate and then put in some buffers. Right ? And then we can replace Da Vinci with other artists and assume that it will still meet our timeline (if not sooner). Ah! the sheer uselessness of estimation techniques in software delivery. Pruning a product backlog is more effective than predicting delivery through estimation.

Abusing agility

Imagine again, that Da Vinci actually signed up for painting a Sistine Chapel look alike. Half way through the painting, he's hanging mid-air trying to smoothen some rough edges. You walk in and suggest that he change the theme of the painting. Of course, you'll get an earful from him. And now, you lecture on how he needs to be agile. Plus, it would factor on his appraisal, you know - not being a team player. Not putting the interest of business above his personal goals. I mean after all, things change, right? Agility isn't an excuse for random decision making. Changing goal posts can do far more damage to a business than badly written code. Most methodologies account for how software developers can respond to changing business needs. We need to start creating frameworks for holding business teams accountable for outcomes.

Assuming people are replaceable

Well, they are. But not without an impact. People are not plug and play blocks. You can't pull one person out and fit in another person, and then expect that things would work just the same. People bring relationships, trust, and personality to a team. We need to recognise and leverage the value that people bring to a team, over and above their core technical skill set. We need to understand that motivated, passionate people will contribute long after they have moved on from the project. Any process framework that treats it's teams as less human will always fall flat on it's face. Undermining people will get you "hands on board" but not commitment. Set realistic expectations based on team synergies.

Ignoring culture

Culture impacts how people perform. Leadership styles create a huge impact on team motivation. Create visibility in decision making. You don't need to label that as Agile or Lean or Kanban. Encourage people to seek help. Provide a safety net for making and recovering from mistakes. Listen and communicate effectively. Account for ups and lows in productivity. Offer flexibility. Insisting on clocking in and out at the same time everyday; or assuming that in-person conversations alone can foster innovation or undermining the value of diversity can blindside us. What matters is how much freedom there is; how empowered people feel; how motivated they are. Everything else is fluff.

The core Agile principles capture the essence of this. 'Individuals and Interactions over Processes and Tools'. But we have translated that into frameworks that have created meaningless processes, and tools. There's no framework to predict how passionate, creative people can make magic. There's no magic pill that can measure human potential with numbers and graphs. Use a process framework for what it's worth - organizing stuff. And nothing more. Let's stop using process methodologies to fit people into boxes that undermine human potential.

Title Image Source: https://www.flickr.com/photos/great8/5624774486 original work by "the great 8". Licensed under creative commons.