It turns out during a global pandemic you have more time to sit and think about things. The time spent commuting, or breaking for coffee, or riding up elevators, or switching gears to talk to a coworker about their dogs is now freed up to spend on other things. (I originally wrote ‘freed up to *do* other things’ but if I’m honest I find myself not doing much of anything these days.)
In the first weeks I spent an inordinate amount of time checking covid-19 dashboards. I’ve sense turned to streaming decades-old baseball games.
All of this to say, I haven’t been very productive with my newfound free-time.
Good for me I’ve procrastinated on more than one professional project. And no matter how long this current pace of life lasts, I have work to keep me busy.
How does the Agile Manifestor apply to actual project work?
I recently started work as a software project manager, working in a medium-sized SaaS company in Austin. It is largely focused on delivering internal change management projects related to a recent merger. My first project was big and hairy, one that requires the PM to go across multiple functions, moderate competing team requirements, and quarterback a lengthy project schedule with ever changing scope. Just another IT project really.
Now that we are a week away from the project going live, I’ve taken a chance to step back and consider what parts of my project could have been improved, helped along, or strengthened by the tenants set out in the Agile Manifesto. Or better yet: does any of it really apply to projects outside of the core software development domain? Can it be applied to any project work stream? (i.e. Assessment, Design, Testing, Data migration)
I thought I’d take a deep dive on each pillar of the Agile Manifesto to see what made sense to me, my work, and how I think about the idea of ‘projects’.
I’ll also preface this by saying: this is not meant to challenge project management, project thinking, or even the agile methodology. This is simply my thoughts on what is (or is not) there in both theory and in practice.
Value individuals and interactions.
Individuals and interactions over processes and tools
while there is value in the items on
the right, we value the items on the left more.
The authors lead with a handful of value statements that form a sort of framework for agile software development. The framework is akin to those SAT analogy questions we agonized over in high school. Though less reaching than a standardized test, the authors ask us to draw comparisons from what’s there on the left (in bold and larger font size) to what’s on the right.
In reading what’s there, it’s immediately obvious that they valued brevity above all else.
Agile takes it’s queues from Extreme Programming and Lean Manufacturing and like Ken Kesey’s acid tests of the 60s, attempts to ‘move past’ the tired, waterfall software development lifecycle (SDLC) methods made popular in the throughout the second half of the twentieth century.
Agile was looking for the next thing in software development. And part of that search and what came out of the manifesto was a recipe to curb developer burnout by working more efficiently.
Individuals are kind of important in the manifesto.
Business people and developers must work together daily. Too many ‘big’ businesses fall into the ‘department trap’ in their project work. Business people focus on business development and padding their metrics, while technology people (re: developers) focus on deciphering whatever the business said in the four hour requirements gathering workshop two months ago. The chasm between business and IT can be so divisive that some companies have rebranded their IT departments. Some have done away with IT altogether, choosing instead to blend (re: embed) technology workers into business functions.
In practice, I think about it like a newlywed couple re-designing a kitchen. They hire a general contractor to come out and estimate the work. The wife explains her ‘vision’ of what a great kitchen would look like. She wants the cabinets to match the walls, and the window treatments, and the backsplash. She wants a nice granite countertop. And oh yeah, the floors too. So there’s a laundry list of requirements. Now what if I told you the newlyweds met the contractor once, agreed on the bid, talked for about thirty minutes and then never met up again until the kitchen was ready to show? Do you think the wife is going to like what the contractor built?
Think of a slightly different scenario where the contractor agrees to review the scope twice a week over the phone or in person, just in case he needs a quick decision or needs to re-evaluate priorities? In this scenario, the wife is there to decide on the grout used on the backsplash; she’s there to pick out the hardware for the cabinetry; and she’s even there to make a decision on the countertops before they’re set in place. In this scenario, the ownership of the final product is shared.
This is the spirit and intrinsic value of business people and developers working) together daily.
Build projects around motivated individuals. If you’ve worked in agile or considered it for your team, you’re likely familiar with the idea of self-organizing teams. Scrum leans heavily on this idea. One the hand, a self-organized team ensures that the members are ready and willing to work together. It’s easy to imagine that a team built around mutual shared understanding and vision would lead to a better work environment. They can take pride in being valued and picked for the team. Managers can take it one step further to ensuring that members are tasked with the work they enjoy doing, or even excel at doing.
On the other hand, agile tends to keep the project team small. Jeff Bezos coined the phrase ‘Two pizza teams’ in the early days of Amazon to paint the picture of a team that can be comfortably fed by two pizzas when pulling a late nighter. The smaller the team the more likely project responsibility is delegated and shared. Smaller teams are more likely to visualize their work and discuss progress regularly, if not on a daily basis.
Interactions are important too.
Face-to-face conversation over email. I’m sure at the time of writing (2001) the authors of the Agile Manifestor were focused on reducing email chatter. Like many of us they were probably on a quest do away with it completely as it related to software development requests.
Nothing can spin up a developer more than sending a barage of emails to: (1) socialize an idea, (2) request it be delivered in the ‘next sprint’, (3) check in on whether it cleared sprint planning, (4) check in on its progress mid-sprint, (5) ask one more time when you didn’t get a response back. Emails even then were inefficient. Emails get lost and they lead to poor developer morale. So please, if you can, and you are the product owner, engage the team in person.
You might ask the Scrum Master to attend the daily stand-up once or twice during the week so that you can get a feeling for progress and make yourself available in case questions come up.
Where you might challenge this idea is in a time of pandemic. You might say, well, face to face at best means jumping on Zoom, or Slack, or Teams. If so, it might just be you and a single developer, who is working on that one user story you requested. I’m not sure the fathers of Agile had video-conferencing in mind at the time when they were gathered in Snowbird, but it meets the principle at least in spirit. At the end of the day, treat everyone like people, not resources, or cogs in a wheel. It’s just better that way.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. If there was one principle that really hits home for me, this one is it. We’ve all been there: The sprint is halfway done and we haven’t even started build on the user story; the team is stressing on whether there will be anything to demo; questions are being floated on whether the demo should move to the right, or just flat out be canceled; everyone’s on edge; and it feels like the world is against you. Take a breath. You’re OK. Ask yourself: what can I do right now to help move the ball forward?
The whole point of agile is not to burden yourself with the time until the next demo. If the sprint’s are too aggressive, you can work with the team, engage the product owner, to agree on a longer time box, or a smaller work in process limit. Maybe the team is accepting too many story points at the moment. If everyone is now WFH due to COVID and the team is struggling to maintain old-ways-of-working and old BAU cadences, then accept that and slow it down a little. Work should be sustainable and (if possible) even predictable. Replace your stress and whinging with structure and efficiency. Try not to take yourself too seriously.
And if you’re business sponsors are applying too much pressure, remind them: while their work is important, it is not the only important work. Quality work is a commitment to do the best work, with the most motivated individuals, working in a way that maximizes flow. That last part about ‘Flow’ assumes that people aren’t scurrying about putting out fires for the loudest voice in the room. It assumes that people are taking the time they need during the day so that they can bring their best self to bear on whatever problem may arise.
So the next time the team is wigging out about a defect or a shitty demo, step back and take the long view. It’s not the team that needs fixing. Maybe its the system in which the team is operating.
Putting it in perspective.
The agile values are important reminders when projects hit the fan. They call us back to the frameworks, methods, and ways of working that define our daily work lives. Their staying power is in the success stories of teams that have gone before, tailoring the values and principles to meet their operational needs.
Work isn’t always glamorous. Scrum ceremonies may seem like going through the motions. Kanban boards might seem too basic. Whatever it is. The truth is: we can choose to aspire to a higher echelon by treating individuals like family and valuing our time spent together.
Thanks for reading. Until next time..