Skip to main content

The #1 mistake in Agile Project Management

It’s been over 12 years since I read the life-changing Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. I’ve been a big proponent of Agile in every organization I’ve worked with since, including Microsoft and DocuSign. Now, in the position of directing 4 engineering teams that execute Scrum in parallel, I continuously see one mistake that almost all agile practitioners make: they think that taking the Agile approach means they don’t need a plan.

Engineers who use Scrum or Kanban often hesitate when it comes to long-term roadmaps. The most common rebuttal: “this is not agile! We’re going to plan one sprint, adjust our backlog, then re-evaluate in two weeks.” Of course this see-what-happens style of project management appeals to engineers, but it doesn’t work very well for big projects that require marketing, partnerships, customer rollouts, or other external coordination. This a frequent predicament.

Then the question arises: how do you reconcile Agile development with planning a marketing blitz or roadshow 6 months in advance? An engineer can’t just tell the marketing team, “we don’t know what features we will have in the product... we don’t know when they’re going to be done... we’re just going to go sprint by sprint and we’ll let you know what we’ve created by then.”

The answer for synchronizing Agile with planning is to shift the perception of what Agile means. Contrary to common assumption, being Agile is not based on an inherent lack of planning. Rather, Agile is about getting feedback as quickly as possible and adjusting plans accordingly.

Early in my Agile career, someone gave me a useful analogy. It goes like this:
Just like with driving, software development is full of surprises. There are virtual detours, stop lights, crazy drivers, and flat tires.  And just like with driving, a virtual detour doesn’t mean you’re not going to arrive at your destination. It does mean, though, that you might need to drive a little faster to make up for lost time or let your friends know that you’ll be a few hours late.  
The beauty of Agile is that it encourages engineers to identify surprises as early as possible and adjust plans accordingly. That way, software teams don’t leave their colleagues hanging at the last minute or waste months pursuing the wrong goals.

Comments

Popular posts from this blog

Quality of Code is Quality of Life

About 20 years ago when I started working in technology companies I remember “the best” engineers had similar patterns:
-They worked crazy hours
-They knew the systems no one else knew
-They could react and deliver something faster than anyone else
You could always hear other employees say: “Bob is really smart, no one knows how to get anything done in system X besides him!”

This reinforced optimization around being the only person who knew how to do something in some part of the code.  That in turn reinforced job security and bargaining for those engineers, but also chained them to a particular system.  We had big code bases of C++ or Java code where some “Bob” hacked up features as soon as he possibly could.  “Bob” would have occasional nuclear disasters where he’d sleep in the office or through the weekend and then everyone would thank him for how he “saved the day.”  “Bob” sacrificed his quality of life to get praise when he hacked stuff up quickly and then the second time when n…

SDET / QA Engineer Interview Checklist

After interviewing and hiring hundreds of engineers over the past 12+  years I have come up with a few checklists.  I wanted to share one of those with you so you could conduct comprehensive interviews of QA Engineers for your team.

I use this checklist when I review incoming resumes and during the interview.  It keeps me from missing areas that ensure a good team and technology fit.  I hope you make good use of them.  If you think there are good questions or topics that I have missed - get in touch with me!


SDE/T or QA Engineer interview checklist from Mike Borozdin
If you like this checklist you might want to check out these posts:
Emotional Intelligence in Software Teams  and Good-bye manual tester, hello crowdsourcing!

Why you should take the software job in San Francisco (or not).

Silicon Valley is an iconic place for technology.  Many people say this is the place for the “best and the brightest.”. Apple, Google, Facebook, Salesforce, Twitter and other top companies draw a lot of talent form all over the world and the largest chunk of VC capital goes to companies in the Bay Area, so it seems like moving here is a no brainer!

The real situation is actually not that simple, I believe there are three scenarios where it makes sense, but in many cases living in the Bay yields disappointing results.  The cost of living, housing situation, homeless catastrophe make places like San Francisco a lot less appealing to a lot of people.  So in what situations does it make sense to move to SF?

Startup founder raising millions There are many places to be a startup founder, but if you are looking to raise capital the largest pool of VC money is in the Bay Area.  There is an established network, events and conferences which give founders an opportunity to pitch more people th…