There are so many factors that can contribute to the ultimate success or failure of an Agile team. Agile Project Managers are always thinking about the little things: are our sprint planning sessions too long? Why aren’t we finishing our story points? Should we switch to a different Agile style (Kanban/Scrum/Scrumban)? These sorts of questions are the tip of the tip of the TIP of the Project Management iceberg when it comes to keeping an Agile ship afloat.
What if I told you that, no matter how strictly you stick to the structures of Agile, most of the time it’s just not going to work EXACTLY how you planned? That’s what I’m telling you. Allow me to elaborate from the perspective of working in a rapidly growing Scrum team.
Sticking to the Framework.
Ever since I was a wee baby project manager learning about this magical world of Agile, the main thing that was drilled into me was to believe in the process. Agile is supposed to be just that – a nice flexible scope that can change on a minimum weekly basis that evolves to fit what the client wants. The steps are clear: Scope it out, create the epics, break them down, estimate the stories, pivot every sprint, reflect on the results, repeat. We were even warned about the common pitfalls: Don’t shoehorn, make sure team roles are clear, don’t break a sprint, yadda yadda. I can safely say in my experience that at least 2 or 3 of the major pitfalls of Scrum are alive and kicking at any one time, no matter the team. I’d go as far as to say that sticking PURELY to the structures of Scrum in a diverse team that does more than just build software is borderline impossible. There’s going to be a bleed of resources, there are going to be client requests that are so outside of the scope, it creates waste etc. In my opinion – I find it incredibly hypocritical that a framework claiming to be proven for success and as flexible as a gymnast, in fact, breaks at the first signs of stress.
It’s all about the Externalities
The main thing that has stuck with me from my economics undergrad is the word externalities. I love that word. To define – an externality is a “side effect or consequence of an industrial or commercial activity that affects other parties without this being reflected in the cost of the goods or services involved, such as the pollination of surrounding crops by bees kept for honey.”
The abridged and in context version of this is basically anything that is external noise to our project scope that is throwing us way off course. “But this is a Scrum Agile team, not waterfall! Isn’t this supposed to be your specialty?” is probably what you’re thinking right now? Not so simple. There’s a big list of externalities that I’ve found to be particularly challenging, to name a few:
- Deadlines on projects changing frequently
- Access to highly important resources or platforms are restricted or delayed due to partner or stakeholder issues
- Data privacy and version control setup can take longer to approve than estimated
- Scope changes and new requests on projects can be bigger than expected between sprints
The list does go on, so, let’s use a working example.
You have a Scrum team of four developers, data scientists, and four ‘digital ecosystem specialists’ (advanced analysists). You run on weekly sprints (the ‘fastest’ option) and have five active projects within one external organization with different departments, stakeholders, deadlines, interaction levels, subject matter knowledge etc. The analysts help the product owners scope out, assess and refine the work that is needed, and the developers build the solutions based on the client’s needs. There’s a project manager and a product owner to act as the main liaison between clients.
When you began with just one project, it was easy. You were estimating features, giving them points and crushing them out. But as the team grew alongside the number of client stakeholders and needs – the structures start to fall down. You start skipping retrospectives, issues are being added and removed mid-sprint all the time, you even considered switching to a different Agile method to see if it would work. It almost became a situation of “which fire needs to be put out first?”. As a project manager – this is NOT where you want to be, especially when you’ve been told that this Agile framework was supposed to work itself out if you kept it on track!
Sounds gloomy right? Well, it’s not. There’s a secret sauce.
More Flexibility
You learned quite early on that sticking strictly to the Scrum framework wasn’t working for your industry’s needs or team’s respective demands. You knew that simply abandoning all the hard work your team had done learning Scrum and getting your stakeholders on board was not worth throwing away so hastily. The effort to learn a whole new method is just not feasible with so many competing priorities. So what do you do?
In true ‘agile’ fashion – you PIVOT. You throw away the stuff that simply isn’t working and you keep what is.
Let me switch this back to a real-life example rather than the hypothetical above. We had a few things that weren’t working: accurate story points for everything and anything, constantly broken sprints, scope changing faster than weekly, and keeping all stakeholders on track. To address these we:
- Created a few different issue types rather than just “Story” to classify different work allowing our team to become more relaxed when estimating the next sprint.
- Created “On Deck” time and issues for potential items that could come into the sprint, allowing us to swap tickets in and out mid-sprint without causing headaches,
- Created and trained Stakeholders on a specific process to update scope and deadline changes directly into our Project Management system (Jira), giving them direct vision and (some) access to the work we were doing in virtually real time.
The results were almost immediate. We were delivering better quality work without stressing about not finishing every story on the board.
In conclusion: if your chosen method of project management isn’t working, it’s your job as an agile team member or leader to raise this as a no-no and do something about it. For some teams – sticking to the framework religiously works, for others, keeping it fast and loose is a better alternative. Regardless of the approach – don’t be afraid to find that perfect balance between Structure, Externalities and Flexibility.
