What does it even mean to do Agile?
Let’s jump right in with a very brief history of Agile.
Agile was launched by 17 white men (from only 3 countries and aged between 36 and 61) in late 2001.
They created and shared the Agile Manifesto at that time. The manifesto is made up of principles and values. 12 short principles and 4 short values to be exact.
It focuses on the creation of software, nothing else.
Because of how it was documented and shared, purists call Agile a ‘mindset’. You use the values and principles to then bring together other ways of working, which are then called Agile Methodologies, or Agile Frameworks.
The Agile Manifesto, specifically its values and principles, is where any good Agile Coach start when assessing an organisation for their Agile maturity and potential for growth.
The Hidden Rules
But if you look deeper, you’ll see that the 12 Agile principles contains specifics that are worth investigating.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Rule 1. Release something that can be used every 2 to 8 weeks. Shorter iterations are better.
Business people and developers must work together daily throughout the project.
Rule 2. Stakeholders must work directly with developers daily.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Note: face-to-face here doesn’t have to mean in person.
Rule 3. Meet in person or over video call for discussions where there is a potential for misunderstanding
Working software is the primary measure of progress.
Rule 4. Other measurements can be used, but we must measure working software above all else
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Rule 5. Ever-increasing velocity (output) is not desirable and should not be encouraged or required.
Simplicity — the art of maximizing the amount of work not done — is essential.
Rule 6. We must actively seek out work not to be done.
The best architectures, requirements, and designs emerge from self-organizing teams.
Rule 7. Teams should be autonomous.
Worth noting that teams as suggested as the creators of requirements.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Rule 8. Retrospectives are not optional and must be focused on ‘inspect and adapt’, not on external pressures or people
Doing Agile
Are our 8 rules enough to allow implementation with no additional guidance, or do we need more?
Rule 1: Release every 2 to 8 weeks
So we have a timebox range for our increment. It seems reasonable.
Rule 2: Daily contact between stakeholders and developers
In product companies, this is unlikely to be an issue. It would be more of a challenge in an agency, where teams are smaller and budgets need to be focused on having days of just creating.
Rule 3: Meet in person or over video call
Show faces and benefit from the details video calls and in-person meetings bring. Likely only required where clarity and certainty is at risk.
Rule 4: Measure working software
So although it doesn’t tell us how, we’ll prioritise the measurement of working releases of other ways of gauging success.
Rule 5: Ever-increasing velocity (output) is not desirable
Not many teams I know live by this rule, but in real terms it means we’ll look for ways to encourage a maintainable pace. For example, limiting overtime.
Rule 6: We must actively seek out work not to be done
Not everything proposed by a stakeholder or from user feedback should be prioritised. Where work is prioritised we should attempt to find the valuable aspects and only do those.
Rule 7: Teams should be autonomous
No managers telling teams how to work or how to achieve agreed priorities. Product roles focus on managing work, not people.
Rule 8: Retrospectives are not optional
Focus on ‘inspect and adapt’ and not on external pressures or people.
Is it enough?
What isn’t covered by our Agile rules.
A Way To Track Work and Progress
Whether Kanban, Jira, Backlog tools, it feels like this is a choice for the team and doesn’t need to be prescribed.
We know we need to have work to do. It should be valuable, as confirmed by in the 12 principles. How that work is defined and prioritised can be different per team.
Rules About Meetings
We don’t know when to meet, who to meet with, or what should happen when we do.
But do we need that? We’ll meet with stakeholders daily (Rule 2), ideally face-to-face (Rule 3). We can talk to other team members as often as we like.
Planning an Increment
How do we know the right amount of work to put into our 2–8 week increments (Rule 1)?
There is no mention of what happens before or after an increment to help be ready to begin the next. This could potentially be answered by the addition to Rule 7 above about requirements emerging from self-organising teams.
It suggests the team will take the regular discussions with stakeholders (business people) and create requirements from the needs they share.
There is no mention of how we know these discussions will convert into valuable software. I see value as a balance of business needs and user needs, but end users aren’t mentioned in the manifesto.
Is Agile still just about software?
This is a topic I love.
If we remove software specific language from the Agile Manifesto, is it usable in other contexts?
In my opinion, yes. We can replace ‘Software’ with ‘Outputs’ or similar, and replace ‘developer’ with ‘team member’ or similar.
Everything else works for the creation of a physical product, or graphic design work, or branding, or marketing. Anything where discovery and responding to change would result in better outcomes.
If we buy in to the idea that Agile can be done with only the 8 rules above, then it becomes an approach anybody can implement using whatever tools and processes they like.
The primary measure of success is about releasing working outputs early and often, which are valuable in their own right.