Unless you are in IT, IT tends to be this mysterious department. There are lots of strange words and magic to get that glowy box on your desk to turn on every morning. However, they have a secret in IT that I think everyone outside of IT can benefit from. A secret that can help you get twice the work done in half the time. This secret methodology offers clear roles, processes, and tools that you can use not only at work – but at home. It’s the agile methodology.
What is the agile methodology?
I could go into the official definitions of agile and link to a ton of software pages and descriptions. However, if you’re like me, your eyes would quickly glaze over. So, here’s my non-technical interpretation of agile. The agile methodology:
- is flexible and iterative to achieve continuous improvement
- sets clear, prioritized, accomplish-able tasks and goals
- has set roles, processes, and tools that support the agile environment.
Why is agile a secret?
It isn’t really. It’s only a secret to those of us who call computers glowy boxes on our desks. It’s also a secret if you are focused so heavily on your area of specialty and a mile-long to-do list that you don’t have time to read or learn about these methodologies that are so heavily relied upon in other industries.
Agile is also a secret to those of us not in IT because it tends to use somewhat scary or unusual terms. Terms like: product owner, scrum meetings, backlogs, and sprints.
Why does the agile methodology work?
In my opinion, it works because of several main features.
The agile methodology depends on clearly specified and prioritized task lists.
Basically, the leader (a.k.a, the product owner) lists out all the tasks that need to be accomplished. Then, he/she prioritizes what is most important to be accomplished. In IT, these tasks are called a backlog.
Now, keep in mind that one of the benefits of agile is that it’s iterative and flexible. This means that as the work progresses, it may be found that some tasks can be removed or demoted in priority as work progresses and the team adapts. It can also mean that some tasks are added or promoted in priority.
You don’t have to be in IT to see how having a clearly specified and prioritized task list would be A-mazing.
This is a shift for extremely busy, over worked people. It means taking the time to think about the big picture. Instead of writing up a to-do list of whatever comes to mind, it’s a more strategic look at the goals.
What is our end-goal? From start to finish – what are the major products or accomplishments that need to be completed? If we can’t get all the products or accomplishments completed – which ones are the most important and which ones are ‘nice-to-have’?
In short, the agile process focuses on only the essential work. All other work is put aside.
The agile process requires a selection of tasks that can be completed in short cycles (usually in two weeks)
There’s nothing more overwhelming than a project that appears to be months or years long. Or, conversely, there’s no greater opportunity to procrastinate than to believe you have months or years to accomplish something.
In an agile environment, the task list is consolidated into what can reasonably be accomplished within a two week period. These are agile sprints.
Even more impressive is that the ‘reasonable amount of work’ is determined by the team that is responsible for completing the work. In the IT world, this is sprint planning.
No more unreasonable deadlines set by management!
The flip side of this is benefit is that because the team determined what tasks could reasonably be accomplished in two weeks – they are on the hook to deliver. No more claims of – there was no way we could have finished XYZ by then! It’s truly a situation of – you made the bed, so you’re going to be the one to lay in it.
To help keep everyone on task (and honest), there’s a daily 15-minute check in to see what’s been done and what is on the agenda for the day. These are scrum meetings.
An agile environment has someone with organizational clout dedicated to removing blockages to getting work done.
Imagine a world where you didn’t have to chase down a signature to finish a project. Or, a world where someone was there to take an issue up the chain of command to make sure you got the information you needed to complete your task.
Because I don’t know about you – but I could lose days just trying to figure out who the ‘real’ person is that needs to sign off on something. Never mind, that once you figure out who that person is, inevitably that person is on leave. Or, in the same vein, it’s not unusual for a task to be held up because someone hasn’t/won’t do something.
I recently observed a situation where a team member had the simple task of shepherding a form through multiple people to meet a deadline. Unfortunately, the first person that needed to sign the form ignored the first two emails and blew through a stated deadline. In the daily scrum meeting, the team member was able to raise the concern of the blocker. The leader of the team (in agile terms this person is called the scrum master). Because the task is blocked and the issue has been raised, the leader takes on the responsibility for removing the blocker. This allows the team member to move on to a new task while the current task-blocker is being worked.
In this particular situation, the leader used political clout to raise the issue of the missing signature. She went through multiple leadership chains until someone was found that could make the first-signer take notice and sign the document. Ultimately, the first signature took 5 days to gather. If that team member had sat and waited for the signature, 5 days of work would have been lost.
Applying the agile methodology to your work
My challenge to you is to think of one project that you could apply this agile methodology to this week. It needs to be something that has at least 2-4 weeks of lead time (the more, the better). That way, you have time to do 1-2 sprints to try out this approach.
1. With your team (or just yourself if you’re working alone), list out all the possible tasks required to complete the overall project.
2. Take the list and prioritize the list.
You could rank order them. But a better way to prioritize is:
- Must have (or accomplish)
- Important to have (or accomplish)
- Nice to have (or accomplish)
Now before you tell me that absolutely everything on your list is a MUST have, imagine a scenario where you just don’t have enough time to do it all. Something will have to slide. Something won’t be able to be accomplished. This is your opportunity to plan ahead what will have the smallest impact if it didn’t get accomplished. Assign that set of tasks into either the important to have or nice to have category.
Also, check out our post on the ‘official’ agile tool for creating this to do list – the Kanban board.
3. Looking only at the MUST have list, select which tasks can you (and your team) get done in the next two weeks.
Your team, if you have one, should be involved in deciding what can reasonably be accomplished in two weeks. If they say it cannot be done -believe them!
Remember: The entire set of these must have tasks have to be accomplish-able in the next two weeks. So, if one task alone will take the entire two weeks then:
- The task needs to be broken down further.
- No other tasks should be added to the two week sprint.
4. Tell us in the comments how this challenge went for you. What did you learn? How did it go over with your team?
Want to learn more about Agile? Take a look at this Breathtakingly Brief and Agile Introduction.
