What if you are too fast?

Picture this. You are in a 120 km/h zone, you’re driving a car more capable than the speed limit and you need to be somewhere, but you are stuck in a traffic jam. This is familiar to most people: A traffic jam. What should be a speedy highway, is now the world’s largest parking-lot. The same thing happens when one has a more capable tool that demands a faster development pace for efficiency, but the current environment is in a dead-lock of inefficiencies and status quo’s.

Mendix Business Engineers have the opportunity of churning out functionality really fast. So fast, some regard it as disruptively fast. The environment cannot adapt quickly enough to change, especially if the organisation has processes built for traditional development teams. People with job-insecurity might perceive this as invasive, they typically do not like change and might even consider the current state of affairs as optimal

The cause of some dead-locks in IT, is dead culture. Tradition determines culture; it is distilled from experience and gathered over time and determines the way we work and the way we predict outcomes.

Here are some telltale symptoms of a bad cultural legacy:

• slowness to react or adapt
• taking little ownership over the domain
• lacking creativity and craftsmanship
• failure to understand business and a dependency on spoon feeding
• too many impediments caused by technological constraints
• an incompatible vocabulary with business
• a “not-invented-here” syndrome
• leaders threatened by new technology not their flavour and that use straw man arguments to keep the status quo
• an attitude that limits Business and often dictates what can and can not be done
• an environment where failure is punished and innovation can not happen.
• an environment with a gang culture where the choice morsels of knowledge of systems are only shared freely with those that comply with the gang’s culture and is liked by the alpha members of the pack

If these indicators match we can expect an environment where we need safety checks and processes that protects team members and dictates to the development team and business, in short and environment with lots of red-tape and ego’s. Processes and formalizations are always necessary, but the tail should not wag the dog. These should be support processes, not impediments. And often we find that in such environments the current “best practices” are not even blogged, documented or publicised and provides and insecure environment for any innovation to happen safely.

Most entrenched coders want job security, and want to be spoon-fed what business requires. They are low-risk – but not in a progressive way. Completer-finishers are crucial to teams but often fall into the low risk, pro status quo group that like security, getting things done – but generally happy to introduce technical debt at business level just to “get the job done”.

Everywhere we go, we see a general pattern emerging: Business is not happy with the pace of development that current IT shops can deliver. We see a similarity emerging with the construction industry where roles are clearly segmented in verticals and specialisation forces people to silo and only look down at their part. For instance, a brick layer only lays bricks and does not have the ability to read and interpret the architect’s plans. They rely on supervisors to take ownership and just do their thing. Plans can never detail everything and clients often feel cheated at the results they get. They feel they pay too much, get too little and that it it delivered late. The answer is typically to get new builders, new plans and better plumbers. And better processes. What we need is more than that. But a better process is a start.

Like Scrum. Implementing a better process is an excellent start. However, few seem to understand that it is a framework that requires customization to fit and optimally serve the environment. It can change the environment as its provides a division of roles with the minimum one should have to be successful in systems development. But we see environments where “the way we do things” are branded Scrum and is not allowed to change when required. The Scrum term gets branded against any disruptive force and Scrum’s rhythm and velocity arguments are used to structure teams in ways that do not make sense – when the goal is to develop great systems that satisfy the business requirements and where rhythm, velocity, measurability etc. should be supportive of this rather than the goal! The tail wags the dog. IT is there to write great systems that allow business to double their business.

Mendix engineering is fundamentally not traditional development. Mendix teams will find that they will have to challenge these processes to gain maximum efficiency and freedom to create business value. One needs to reform what IT means in the eyes of everyone else. This is a gigantic task and may take some time to break the deadlock depending on how agile your company is. It will be a change that will require time and effort and will probably upset people who are comfortable and in cozy jobs. An Oil Tanker takes a long time to change direction, and it is to be expected from other large organizations. Hang in there and work with lots of compassion, openness and communication, however do not comply with bad/non-optimal practices just to keep the peace. We have to put business first.

Mendix, as quick as it is, is not a silver bullet. The processes and approach around Model and Domain driven development needs reformation. Pick your engineers carefully, since they will be your first line of change agents and culture trend-setters, the ones who will share the vision of your business. If you want a comfort delivery zone and do not like change – look somewhere else for a solution as this is not a get-popular-quick scheme but a new and fresh business driven approach to churn out value with lots of changes to support that. It offers a new set of experts and building techniques that allows us to focus on what our clients wants and works best in an environment where ownership and initiative is encouraged rather than playing the blame game that results in dead culture and causes people to hide behind red-tape.