Agile software development — 5 essential facts for startup CEOs
The 5 essentials that startup CEOs should know about Agile software development:
(Test your CTO 😉)
1. Real users are unpredictable and full of surprises.
This is the why of Agile — the reason it exists.
You (CEO) are an expert in your industry.
You have used your unique insights to build a product.
But something unexpected happens when people see or use it.
They can't work out how to use it.
It solves a problem they don't have.
It doesn't solve a problem they do have.
It solves their problem, but causes another.
It solves a problem that you didn't know about.
They don't want to use it the way you intended.
They love the idea of it, but never actually use it.
It does its job, but they hate it and can't explain why.
OK, not all of these, but at least one.
Get over it — nobody has solved this yet.
But Agile is an effective workaround.
2. You get more things right, faster, by taking small risks.
Getting your product right first time is possible, but unlikely.
It's a large investment riding on single spin of a roulette wheel.
Instead, the Agile approach is to develop small slices of functionality, collect feedback, adjust and repeat. You make consistent incremental progress, using tight trial-and-error feedback cycles.
Smaller stakes, but multiple spins.
But unlike roulette, your knowledge of previous spins gives you an edge. 😎
3. Prioritise face-to-face collaboration with stakeholders, and especially, real users.
It is unlikely that you (CEO) know exactly what to build and how, because of point zero: "Real users are weird and unpredictable".
But you do have a vision. Share it with your product managers and engineers. They will collaborate (not just talk) with stakeholders, including Real Users™, and will figure out the best path to realising your vision — one small step at a time.
4. Changes are expected and welcome at any time!
Agile expects requirements to change constantly. However, I'm not referring to your (CEO) whims — I'm talking about changes that are based on real world feedback.
5. Agile is challenging for many CEOs.
a. Autonomy & Trust
You'll need to entrust product managers and engineers with a high degree of decision-making autonomy (see point 3).
b. Minimalism
Agile has a minimalist perspective.
It can be tough to decide what NOT to do.
Or at least, what not to do YET.
If you just tested your CTO on the above, don't be too hard on them.
They might not have summed it up as casually as this, picking out only the bits that CEOs should know. (If they mentioned roulette, give them full marks, because they must have read this post.)
However, this is what I hope they told you:
6. What problem does Agile solve?
I once worked for a consulting firm that catered to large organizations. We spent weeks analysing a client's needs, then wrote a formal specification — a thick book. They signed it, and we spent months building the system. When development was complete, it slammed into its first real users. They would complain that it was out of date, or even useless. It took many further months to process and deliver formal change requests until the system became somewhat acceptable.
This process was too rigid and was highly resistant to changes in the specification.
Problems were discovered late, making them expensive to fix.
Such a processes have been dubbed "waterfall" — a linear sequence of steps that must be followed in order, to completion. Each step has a beginning and an end, and the output of one step is the input of the next.
In this case (simplifying): analysis → design → development → testing → deployment.
Waterfall works well for construction and manufacturing, but not for software development.
It is too expensive and inefficient in terms of effort, time and money, because we cannot get most software features "right" first time.
We need something that is less formal, more flexible, makes our inevitable mistakes cheaper, and suceeds faster.
In one word: "Agile".
7. What is the essence of Agile?
Agile is an iterative, cyclical process.
We reduce up-front investment to a minimum.
We also progress in small increments, which compound fast.
Agile's feedback loop is tight, measured in days / weeks, not months.
When we get something wrong, we find out early, and it's cheaper to fix.
Agile prefers:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Key principles in Agile:
Cadence
Deliver working software early, frequently, and at a constant, sustainable pace.Collaboration
Software developers must collaborate face to face with business people.
Autonomy
Trust motivated people to get the job done, acting in highly autonomous teams.
Reflection
To increase the effectiveness of the process, reflect and adjust your behaviour at regular intervals.Progress
The primary measure of progress is working software.Change
Requirements will change — embrace this.Simplicity
Maximise the work you decide not to do.Excellence
Technical excellence and good design enhance agility.
Some of these principles can be hard for management; others are challenging for engineers. But it's worthwhile to overcome the difficulties.
8. Agile Vocabulary that you'll hear
You'll hear these words — let me dispel any mystery that surrounds them:
Scrum, Kanban — agile ways of organising software development work. (If your engineers are too insistent on dogmatic adherence to these mystical ideologies, send them to me.)
Sprint — another name for an iteration or cycle. It's essentially a team-level unit of planning and execution.
Story — describes a *tangible*, incremental unit of functionality that can be implemented and delivered independently.
CI/CD — continuous integration and continuous deployment allow features to be deployed to production as soon as they are completed. (FYI Continuous Deployment is like teenage sex: everyone talks about it, but only a few know what they are doing.)
Feature Flags — allow deployed features to be released in a controlled way to subsets of users, in order to gather feedback. With feature flags, deployed does not necessarily mean released -- that's a good thing!