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.
Post a Comment

Popular posts from this blog

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!

Highly Effective Software Teams

A few weeks ago our Board of Directors asked me to present my assessment of the state of software.
 I was hired to organize and grow the software team and the directors wanted to know what kind of a team we needed to build.  I was hoping that I can just reference an article somewhere that would give me the answer, unfortunately I didn’t find anything suitable. During my research I did find some great material that will be helpful if your job is to put together a highly effective software team.
A highly effective software team has the following key characteristics: dependable, committed to shared goals, passionate about technology, respectful and compassionate.  These are not limited to technology industry, it can easily apply to finance, medicine, or sports as well.  Below is the summary and references that I found. Dependable If you are creating a software product, you need to deliver your software to your users.  Your users need to know that you are able to solve their problems on …

Two Critical Questions for Your Next Interview

I’ve interviewed probably over 500 engineering and management candidates over the last several years.  There have been a lot of really smart people who have applied at DocuSign, Microsoft and Tempo Automation. A surprising number of them didn’t have a clear answer to these two essential questions:

Why are you interested in joining our team?Why should we be interested in you? 
If you are an applicant, having a prepared answer for these questions is critical.  If you are a hiring manager, you should ask them and have a clear answer to these questions at the end of the first interaction with your future team mate.

In a field where work is somewhat predictable and static, those questions are less critical, but in software development perseverance, ingenuity and focus make all the difference. These are the two main questions that will separate a subpar and a superb hire.

When I discuss those two questions with an applicant I try to go below the surface.  Generic answers like “it says you ar…