It’s a myth and we need to stop feeding it!
“Agile won’t work for us because we’re not doing software development.”
Seymour obliges and the plant whom he affectionately names, “Audrey II”; continues to grow and grow after each feeding and becomes more demanding. Eventually, Audrey II wreaks havoc on Seymour’s life and Seymour realizes he must destroy his beloved plant to not only to save himself, but the world.
Believing that agile is not only for Information Technology is like feeding that weird little plant, and perhaps we’re not saving the world by destroying the myth, but we could be saving your next project, the morale of your team or maybe your career!
Although it’s been over two decades since the publication of the Agile Manifesto, there is still a long-held belief that agile only applies to software development. It also doesn’t help that many agile certification programs reference software development as the standard when teaching agile concepts.
While it’s true that in our modern times, we rely heavily on technology and the need for software developers continues to rise, agile can help streamline common activities for many different roles or types of work.
Agility is best defined as the ability for a team or person to embrace change by preparing for the unexpected so that they can deliver quality “work” “faster”.
Change can be anything from responding to a catastrophic event, customer needs or wants, market trends or even changes in how work is done (even software is developed differently than it was 20 years ago).
“Work” can be anything from feeding Audrey II, planning a wedding, delivery of a marketing campaign to building a bridge. Wherever there is a need to deliver faster, better and adapt to change, “agile” can help.
“…but nothing changes when you are building a bridge so agile won’t work!”
Even while building bridges, the project can suffer from unexpected changes such as earthquakes, job site accidents or even a loss of funding.
Let’s dispel the myth by learning about 7 steps that can be adopted for any type of work, team or individual.
1. Teaming: Develop Team Working Agreements
Gather the team into session and create a set of working agreements which are a simple list of guidelines that your team will follow. This list of guidelines can include values, behaviors or rules that are meaningful to your team.
Examples:
- How often the team will meet
- Any norms such as a promise to be honest and transparent at all times
- Collaboration tools the team will use
Skip this step if you are solo.
2. Create a Definition of Done (DoD)
What does it mean to be “done” with the “work”? Decide on what conditions must be met to consider something “Done” means and write this down (hint: add to your working agreement).
At minimum, establish a DoD for the task, but consider establishing one for larger chunks of work as well as the entire body of work.
3. Build the Backlog
A backlog is a list of anything that needs to be done. This list of things could be all the activities or items needed to ensure that “Audrey II” never asks to be fed again or the wedding is planned, the marketing campaign is a success or the bridge “complete”.
4. Define the Timebox
A timebox is a box of time which is alloted to finishing work. Choose when the timebox starts and ends and since it’s more effective to have a short timebox, the time frame could be minutes (i.e Pomodoro Technique) to weeks.
5. Establish the Plan for the Timebox
Consider which activities or items from the backlog are the highest priority.
There are many methods to prioritize a backlog such as Must Have, Should Have, Could Have, Will Not Have (MoSCoW) but for simplicity’s sake, imagine you only have until the end of your timebox to complete a set of items from the list and there will be no more time after.
Which items would appear at the top of the list? From this prioritized list, create the plan for your timebox.
6. Go!
Start working on the plan!
7. Pause and Reflect, Rinse and Repeat
At the end of your time box, reflect on what was done or not done. Think about the process itself.
Does it need to be revisited? If so, enact and validate those changes and begin the next cycle of work and don’t forget to celebrate success (but please do forget to feed Audrey II).
