The mindset of Agile: why we struggle in enterprises

As a developer I've wondered why we struggle so much to get along with business people in a classical enterprise or big corporate. With the whole "agile" movement, we are now supposed to work a lot closer. So why do we still struggle?

My suspicion is that we think fundamentally differently, like a right-brained artist versus a left-brained bean-counter. In this article I'm exploring these differences to try and discover how this affects agile adoption.

The Developer

We software developers are used to thinking in an agile way. The nature of our business is to think about both the big picture and sweat the details. We need to understand the business needs as well as how to realize it in software.

To be able to do our job, you need to keep on top of technology, and therefore learnt to learn really quickly. In my case, the downside of this is that my memory and attention span became shorter, in no small measure due to the volumes of information my brain is fed daily.

So, put a team of us together and you get a bunch of hyperactive kids who don't like sitting still and has the attention span of a 2-year-old. But we can get the job done, learn really quick, get kicks out of well-written code and new toys, enjoy cool UI design and have a drive to excellence (I hope).

What we struggle with is structure, meetings, lots of Excel spreadsheets or thick requirements docs.

The developer's idea of agile is to adapt often, learn and deliver quickly and to be a bit chaotic. The time-frame for this tend to be one to three weeks max before we lose interest.

The Business person

With a degree in, let's say, financial planning, banking or an MBA, the typical business person is trained in an industry and practices refined in the past 50 years or more. Efficiency, creating order from chaos and planning and the tooling that goes with it is a staple. You learn to follow the rules laid out by your industry. These rules do change, but typically only a small percentage of it, and only once a year.

Put a bunch of business people together and they hold meetings, create plans, hold road-shows, create documentation explaining rules, or listing financial plans.

So essentially generating contracts, and plans to execute these contracts. 

The business person may also use some software to assist them to assist a client or do their work, depending on their role or industry. In general though it is a linear process, well-known and oft-trodden.

What they struggle with is delivering value quickly, with a minimal plan, and postponing details until the latest. They struggle to not write too much and not plan too much.

A business person's idea of agile is to measure and adapt to client needs relatively quickly and to get to market faster than the competition. The time-span is measured in a few months or a financial quarter/year.

The mindset of Agile

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To paraphrase the agile manifesto, which I believe is about behavior and a mindset and less about a SCRUM or SAFe framework, it is all about collaboration and teamwork, trust, accountability and fail-fast/learn-fast/deliver fast.

So, essentially it fits developers like a glove. Not so much the business person who was trained to do process, documentation, contract negotiation and following plans.

SCRUM and SAFe help mending bridges

SCRUM helps to create a little bit of order in the chaos that is software development and the developer's mind. It helps the business people to plan a little bit at least and understand (by virtue of visual elements like the board, burn-down and demos) where they're at and get a better grip on what they'll get.

SAFe does nothing for developers but lets higher-up business people feel like they're doing agile. Hopefully after a while they will actually be thinking agile and not just do it lip-service.

None of this makes any difference if business do not trust developers, developers don't trust each other, accountability isn't given where it should be and collaboration is still a once-a-quarter meeting.

SCRUM and SAFe then become marketing tools and status symbols instead of assisting an agile way of work.

The enterprise and HR

Often times in an enterprise, HR (and the enterprise as an entity) don't really understand or know what to do with this new way of work.

The company has ceremonies to award individuals and bonuses are given out to (those perceived to be) star players. Quarterly or yearly performance, or "360", reviews revolve around individual performance, and exclude or minimize the key values of teamwork and the agile mindset or expected culture. In essence the company then rewards an individualistic culture, while on paper it states that it is an agile culture.

I believe this is a result of business and HR following the world they know, which is indeed individual-based. HR themselves aren't necessarily schooled in the arts of being agile or the new "startup-style" of work.
Maybe they should also be included in the same SCRUM and SAFE training or agile bootcamps as the rest of us?

Conclusion

By understanding the way we think vs the way business and even HR or the enterprise as an entity thinks, we can be more aware and tolerant of each other and become "agile-ish" enough to satisfy both the chaos of software developent, and the realities that are Business.

In a future post I'm going to list some key points of research on exactly why agile (could) fail, what gets in the way of making it work and a road to get to agile nirvana.