Does you use the Agile methodology at work? What do you think of it? Do you think it helps you be more productive?
I suspect your answer to that question depends on a number of factors, but the key determiners are likely the role assigned to you by the Agile framework, and the details of how Agile has been adopted by your company.
Why Agile is Supposedly Better Than Waterfall
Waterfall has a fatal flaw – although thorough planning and a long-term roadmap are useful in organizing a coherent project plan and achieving a big goal, you’re stuck with this plan once you’ve started. Projects planned with waterfall will often do huge portions of their work before they are able to grab the separate pieces of a system and try them out together.
This means that if something is wrong, you don’t find out for a long time – possibly until its too late.
And if the market changes while you’re working on this project, well that’s just too bad. You’ve already committed to making the thing you planned from the beginning. At this point you have no choice but to see it through and release your too-late product to the already-moved-on market.
Agile is primarily intended to solve one key problem in Waterfall; just as the name describes, it gives businesses the ability to change their mind quickly, and pivot to a new plan.
It accomplishes this by prescribing that work be chunked into 2-week commitments (this can vary from 1 to 4 weeks). At the end of that 2 weeks, the entire software system should be in a working (shippable) state, and everyone should be able to choose the next most important thing they can get done in the next two weeks.
This is an elegant idea. And it works for some teams, but it requires a lot of discipline, and it doesn’t scale well.
Agile for really large teams – sucks.
What Is Hard About Scaling Agile
There is a whole industry that has arisen around trying to apply the Agile methodology to large corporations. And this is a noble pursuit. It is easy to see why corporations would want to adopt these paradigms – all the little guys do it with great success, why shouldn’t they!
But agile is inherently challenging for large teams. Imagine a team of 1000 – this breaks down to at least 100 scrum teams if you keep a maximum of 10 people per team.
The projects endeavoured by these types of teams are enormous, and require detailed planning and coordination on multiple levels.
How do you simultaneously get a team of 1000 working together in the same direction on these projects, but then also be able to change the direction of the company at a week’s notice?
How do you simultaneously empower 1000 employees to feel ownership for their work while retaining the ability to change what they work on at a week’s notice?
The answer is, of course, you can’t. You need to compromise somewhere, and so these frameworks for applying Agile principles at a large scale do compromise.
Instead of being able to change the plan every couple weeks, you group sprints into sets, and re-evaluate at the end of that couple-of-months period instead. You play mini-Waterfall.
And to make sure everyone at the business level stays up-to-date on how things are progressing, you have hoards of personnel dedicated to communicating status between teams.
And this is where scaling Agile breaks down. When you introduce this much planning and coordination into agile, you lose the agility.
It’s like Heisenberg’s uncertainty principle – trying to measure a thing causes a change in that thing, and you’ve kind of ruined the accuracy of the measurement.
How your role in large-scale agile defines whether you think it’s working:
This is where we can see that your feelings on working within an Agile system will depend on your position with that system.
If you are an individual contributor, you will now spend a large portion of your time allowing others to measure you. It will go far beyond your daily standup. Every project or initiative in the company will have its own meetings to both plan and assess progress, and you will be expected to attend lots of these.
If you are a communicator in this system, you are incentivized to ask lots of questions, and have a clear picture of everything that’s going on at all times. But this incentive works against the pure productivity of the team. Every status update you give is an interruption from whatever you were working on. And each interruption takes a long time to recover from. Focus is not just lost for 15 seconds while you have a “quick check-in” – it is lost for half an hour while the you struggle to re-enter “the zone” and re-establish the deep concentration they were in.
If you are a leader or executive in this system, you are too far away from these interruptions to see their devastation first-hand. Without real proximity to the scrum teams or experience working as a contributor, you may not realize that the your effort to stay abreast of status in an attempt to make informed decisions has introduced a counter-productive vector in the system.
The need to keep executives appraised is important and fair – the business does absolutely need to understand what’s going on in order to make the best decisions about how to allocate money and resources.
But it’s also what sucks about working as an individual contributor at giant companies.
So What?
It helps to understand these things to make them less painful. Agile doesn’t have to be bad.
It is up to the implementers to avoid imposing onerous bean-counting requirements, and to protect the developers from as much of the structure of the scaling up as possible. Sprint planning is still useful! But implementing a company-wide restriction on how to type out your task descriptions is not.
If you are a communicator, know that you are the key to pulling off agile without being a pain in the butt. Communicate effectively, but try to do as much observation from a distance as possible.
If you are an individual contributor, advocate for what you need to make yourself more productive. Remember – you are being paid (probably a lot) to use a specialized skill. Try to preserve most of your time for that job.