The Agile development problem
Agile is great at delivering the wrong things faster and making people miserable
After 10 years as CTO, the most common problems I encountered with Agile development are that it’s great at delivering the wrong things faster and it’s really awesome at making people miserable.
The solution to this is anti-Agile by definition - you need to slow down, you need to give yourself and your team space to breathe and you need to shift your focus on the right things.
In essence, building software is a very simple 2-variables equation: customer value and team morale. That’s really it. Maximize for both and you’re golden.
What to do:
- maintain real-time feedback with your customers (variable #1)
- read everything you can about Yerkes–Dodson’s law and maximize your team’s happiness (variable #2)
What not to do:
- employee tracking
- dumb estimates
- meetings & more meetings
- e-mails & more e-mails
- standups
- backlogs
- TDD when you don’t need it
At kronup we prioritize deep work over deadlines, experimentation over execution, choice over delegation and flow over ritual.
Experimentation over Execution
As outlined in its 2001 Manifesto, a core Agile value is “responding to change over following a plan”. This obviously has its merits, especially in a context when Waterfall was “the only way to do things”, but current Agile methodologies (not going to name them here) have sadly taken this principle to the extreme, prioritizing speed and “iteration in production” over common sense.
At kronup we believe in applying the Scientific Method, and going back to first-principles reasoning, and that this approach is much faster than “brute-forcing it” long-term, so our workflow looks something like this:
Define the customer value item
Attempt to list assumptions
Attempt to invalidate assumptions with small experiments
Document findings clearly in very short sentences
Go to step 2 for as long as it takes
The end result here is that, before writing a single line of code in production, your entire team deeply understands the context of the issue at hand and the reasons behind it.
Plus at this stage you can afford to move as fast as you like: experiments are always small, never unit-tested, never integrated into a larger system, and never exposed publicly so you have total freedom to break anything in search for your answers.
When the value item is clear and all assumptions are validated, we can begin to break it down into tasks and allow team members to choose the work they do based on Yerkes–Dodson’s law.
This was kronup’s first principle, “experimentation over execution”.
Choice over Delegation
I have always encouraged my leaders - from PMs to VPs - to “learn to step aside”.
It often feels like you should intervene to fix an issue or that you should lead by example but this often turns into either micromanagement or setting the tone for a toxic hustle culture. Best case scenario, you have just robbed your team of valuable opportunities to make their own mistakes and learn and grow.
I have also struggled with this impulse to “fix it myself” but I have learned over the years that if I feel like the most competent person in the room, I am likely at fault for that.
You have to let your team fail from time to time - especially when you see it coming from a mile away and you know exactly how ugly it’s going to get. After the shit hits the fan, don’t say “I told you so” - be stoic, be kind, guide but not push your team to get themselves out of the mess.
You don’t teach your kid how to ride a bike by showing them your sick tricks, you let them fall so that they learn they can get up again.
In the words of The Mandalorian - “This is the way”. It truly is.
We don’t delegate tasks. Team members choose what they want to attack next from a list of tasks.
These tasks are graded by our system for each team member individually by something we call “the happiness factor”. This is just Yerkes–Dodson’s law in action, nothing fancy.
Deep Work over Deadlines
Estimates are drugs - they give you a high then slowly kill you.
No engineer ever claimed in their CV they are “good at estimates”, yet somehow project managers keep insisting that developers do have this skill and they stubbornly refuse to use it, as if out of spite.
Building any piece of software is not a recipe - you do not know the ingredients (yet), you do not know the steps (and they will change constantly), and you have no idea what you’re cooking. Exploratory work presents the worst type of variables: unknown unknowns - the things you don’t even know you don't know yet.
Asking a software engineering team to give any sort of estimates on a completely new feature is like Divination (from Harry Potter). You’ll get the answers you want to hear, but those have nothing to do with reality.
When estimates become commitments because of incompetent management, you’ve got yourself the perfect set-up for silent quitting.
As a manager, if you truly need that estimate for whatever reason and you cannot fight back, what you should do is let your team work, jot down their current “speed”, use the rule of three, then triple the result. Keep that result to yourself or whomever asked for it and move on.
Our team at kronup believes in deep work over deadlines as a catalyst for productivity. Sure, as Elon said, having an insanely tight deadline might yield some temporary increases in output - but it will also lead to burnout.
As the Romans used to say, “festina lente” - make haste slowly.
Following Cal Newport’s rules for Deep Work - book here: Deep Work on Amazon - we strive to keep distractions to a minimum, and estimates are considered one of the most toxic types of distractions.
Flow over Ritual
The main reason “Agile frameworks” fail is ritual.
Why do rituals exist and why are there (rigid) frameworks for (fluid) Agile development? The “Agile framework” oxymoron should be a red flag in itself, yet it is ignored.
For one, following a blueprint feels safer. This is a combination of two or more cognitive biases, including “Authority bias” and the “Bandwagon effect”. We are inclined to follow the advice of authority figures and ideas that have mass adoption even though those notions do not apply to our unique circumstances.
It’s also much less mentally demanding to follow the guidelines than formulate unique solutions to our unique set of problems.
Last but not least, when you’re following a well-known recipe you can blame the ingredients, right? “It’s the team’s fault, they didn’t do Scrum correctly”.
When rituals are seen as disconnected from progress they begin to feel like barriers.
Team members will say “this is stupid!” - and their frustration is justified. Meetings for the sake of meetings, standups that interrupt deep work “just because”, backlogs that become synonymous with landfills, retrospective this, adaptation that - it is all ritualistic nonsense.
At kronup we believe in flow over ritual. Flow is not some fancy term we made up, it is just the mental state in which a person performing an activity is fully immersed. That’s it.
We have minimized distractions so that each team member can reach a state of flow and perform deep work.