I rarely use the term “agile” these days. If I mean “responsive to change” or “adaptive”, I just say those words. If I mean “self-organising”, I say it. If I mean “lightweight”, I say that. If I mean “cynically exploiting a trend to sell certifications”, I say that
From https://twitter.com/jasongorman/status/1043117677768843264
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
And the principles behind the agile manifesto are:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Prototyping to learn
The team started by quickly building a prototype wall using index cards with mail-merge stickers on them describing each procurement project. This information had previously lived in a spreadsheet. With the work quickly thrown up onto a wall, they asked themselves the question: “What is this wall not telling me?”.
Answer: a lot! There were so many cards it was hard to see what was going on. They were hard to read. And the wall couldn’t tell the team anything about cycle time: how long was each project taking to go through the whole procurement process?
Additionally, one of the team members had a visual disability, so the team wanted something with high contrast and large lettering. This was going to be hard to achieve with cards, given the number of procurement projects which were in flight at any time.
With this learning, the team built a second board, this time from Lego.
Gather the team and your subject experts (e.g. ops, legal, security, policy, HR) and ask them these questions*:
The Waterfall methodologists feel comfortable with long timelines. They typically work ‘right-to-left’ from a desired delivery date; the agilists prefer to work iteratively, ‘left-to-right’ as much as, and where possible. Whatever your preference, timelines are important and an inescapable part of delivering. A timeline is not a dirty concept.
I start this conversation by sticking post-its across the top of a wall with time intervals running left to right. I use 3 or 6 monthly intervals over 1 or 2 years, but whatever is right for you. Choose a timeframe that creates some discomfort for your colleagues to think beyond the immediate “deadline” in everyone’s head and to get them to think strategically.
Place known, real or imagined, time constraints and events across the top too, maybe on a smaller or more muted colour post-it so they don’t become the only focus of conversation.
From http://www.jamiearnold.com/blog/2014/07/22/seven-questions-to-build-a-roadmap
Combining agile and non-agile into a jerry-rigged mishmash misses the point of working in an agile way.
Being agile doesn’t mean you give up on governance or deadlines. The idea that agile somehow “needs” a waterfall-type methodology to give it control and governance is nonsense. When you work in an agile way, governance is built into every step of what you do. You build and iterate based on ongoing user research. You build what users need, not what you guessed might be a good idea before you even started building.