Throw Away Your Agile Framework

Introduction

I would value modern project management more if it were not so ineffective.

In software development, this often comes in the form of an agile framework called Scrum. The concept is simple:

• Projects are broken into features called epics.
• Epics get task lists called stories.
• Stories are done in iterative cycles called sprints.

Sprints complete stories. Stories complete epics. Epics complete projects.

It never works out this way. Lazy engineers spend more time creating stories, estimating completion time, researching, and are overall afraid of making real contributions towards the project.

They rarely fault themselves either. Processes need to be changed. Ticket scope was not correct. A system did not behave as expected. These are perfect ways to shift blame off of their incompetence for delivering results and onto anything else.

I believe this is the majority of engineers at the majority of companies. It does not provide the business value leadership was promised by agile project management, and I know it does not feel fulfilling from a developer's perspective either.

Instead of valuing team velocity or story points completed, I think there are three more important metrics.

Enthusiasm

Value excitement. Ask any developer who has done a side project - the first week or so, when you start something new and are figuring it all out, is the most productive week of the entire project.

It's new and unexplored. You're focused on accomplishing a single goal, which is typically the MVP of your future product. Getting there as fast as possible is the primary concern.

Involve your dev team in product and customer interactions, and get them excited about the value you're delivering to customers. Treat each feature like a new product with a single goal. You lose this as soon as you start writing stories.

Deep work

Value real effort. There are so many studies, podcasts, books, videos, and more about deep work and its value. Andrew Huberman and James Clear are a couple of my favorites on the subject.

Humans don’t have a great capacity to accomplish large amounts of creative brain work in a day. Studies show that this capacity is between three and four hours, and it can be affected by anxiety or excitement.

Simply doing a couple of ninety-minute blocks of deep work in a day would make a drastic difference in output for most corporate workers. Stop letting daily standups, Slack messages, syncs, handoffs, and other distractions get in the way of that time.

Ownership

Value people taking responsibility. My favorite TED Talk is "Extreme Ownership" by Jocko Willink, where he explains that taking responsibility for anything you have any bit of control over is extremely beneficial to your life.

Do this in your workplace. Even if you didn't get assigned something, but an issue comes up and it needs to be resolved urgently, do it. Feel personally responsible when your team misses a deadline.

In a corporate culture where anything is anybody's fault, make it yours and fix it. Taking as much responsibility for your life, your team, and your output is such a rewarding change.

Bringing It Together

Especially as engineers, we value measurable metrics a lot. Life is really about the intangibles though. I'm hoping that you're seeing the argument for it.

You can't measure how excited a team is about any given task. You can reap the rewards when things are done on time, maybe even early.

You can't measure how much deep work you've done in a day. You can look back on a task you made leaps and bounds of progress on in just a morning though.

You can't measure how much responsibility someone takes. You can respect people who take ownership over things that aren't their responsibility and change processes for the better.

Project management has been inflated to task boards, planning meetings, and agile processes. Poll your team, track the time it takes team members. Maybe even factor in distractions into that deep work topic.

If it were really effective, you'd be hitting deadlines and getting things in front of customers faster and faster each project. I'm willing to bet you aren't, and that scrum isn't delivering on what it promised.

It's time to try something different. Hire good engineers. People who take pride in their work, can identify where they aren't proficient, but no matter what make progress. Let them work without distractions, but with a customer goal in mind. Iterate quickly and get feedback often. Ruthlessly get rid of everything else.

The overplanning and overmeeting encouraged by scrum is blocking your effective engineers from accomplishing your business goals. It's process that had good intentions originally, but like many things is only good in moderation. Don't block your team from doing their job, but expect them to communicate about what is important.

Product owners are familiar with simplifying projects to the minimum viable product. Project managers need to start focusing on the minimum viable process.

Throw away your agile framework.