How can you tell if your team and organization is making forward progress?  And I don’t mean just any progress, but progress in the right direction?

What I’ve noticed is, depending upon your role in the organization it can be extremely difficult to know on a day-to-day basis if you are working on the right thing, and the consolidated efforts of the team are moving together in harmony.

Developer: Did I finish my sprint tasks? Daily

Senior or lead: Did the sprint finish correctly? Weekly, or by Sprint

Project manager: Did the project hit its milestones? Monthly

Product lead: Did the product have successful releases that the customer wanted? Quarterly?

Portfolio manager: Are all the products releasing, and their bugfixes and features complementing each other? Bi-annually?

Division manager or Director: Is this line of business making money? Annually

As you can see, if you are in more of a management or leadership role then it can take a long time to know if what is being worked on is the right thing.

Something a lot of organizations seem to forget is that the person with the most perceived importance, that senior executive, their strategic goal is the overall aggregate success of all the projects to the degree that the organization is showing profit, not loss.  But absolutely none of that happens unless all those developers at the opposite end of the chain are successful as well. All those sprint tasks need to be completed, correctly and on time, or the entire chain falls apart. But what’s critically important is the CORRECT sprint tasks need to be prioritized, and that’s the hard part (especially when looking at things from a strategic-level view).

So if this is true, if you are a manager or in a more strategic role, what can you be doing on a day-to-day basis to ensure that the organization is moving in the right direction?

Delegate

When it comes down to it, that Portfolio Manager or Director is essentially responsible for the health and success of every project, and thus the efforts of every developer.  Typically though there are too many projects for that Director to truly monitor every one. That’s the whole purpose of all those layers of the organization.  As you move through them people’s areas of responsibility become more and more tightly coupled to those sprint tasks.  The Director delegates the monitoring of sets of projects to a Portfolio Manager, who delegates individual project monitoring to a Project Manager, who delegates the monitoring of a sprint to a lead developer, who delegates the success of a single sprint task to a developer.

Trust…

The delegation really only works if there is transparency and trust.  The Director has to trust that the Portfolio Manager is doing their job and providing accurate data, the Project Manager trusts the lead developer that the sprints are being planned and monitored, and the leads are trusting the developers to work on their sprint tasks and get them done.  And in return, the developers need to make sure they are honestly, accurately, and rapidly reporting their status to their leads. If a sprint task is falling behind that lead needs to know RIGHT NOW because they are responsible for the health of that Sprint.

…but Verify

As reporting rolls upwards, there’s a tendency for the data to become more and more normalized, and subject to bias and filtering.  The lead might only hear about the health of a couple of the sprint tasks, and even then only the ones that the developers think they are having issues with.  A sprint task may be being worked, and the developer is completely on-task and on-schedule, but the developer doesn’t realize that the solution being developed doesn’t align with the architecture.  Or a project manager may happily report that the project is meeting all its milestones and is on schedule, but the features being added from month-to-month don’t align with the priorities of the portfolio.

As a lead, what I used to do was milesone reviews, daily random sampling spot checks, and deskside peer reviews.  In general, you need to be thorough at your milestone gate reviews; for example, at a Sprint Review you need to not be afraid to take some time to dive into the solution and make sure everything is aligned.  The developer needs to understand that the lead isn’t trying to call them out or show them up; instead, the lead probably has some broader contextual vision across the sprint so they can understand how everything fits together.  But in addition to that, I also monitored the daily code checkins and CI pipeline test runs and test reports.

This same approach works at the management level as well.  For example, project manager conducts monthly project management reviews (PMRs), but in addition might be monitoring that daily burndown chart to ensure that the project is on track to meet its monthly goals.

The success of an organization as a whole does distill down to that director-level metric, did the company make money?  (If a company isn’t making money then they can’t afford to pay everyone’s paycheck, after all.) But as you can see, the efforts of everyone, especially the individual engineers and developers, are critical to ensuring whether or not that success can be achieved.  Everyone’s perspective is important, and everyone needs to have that trust and transparency so that the organization can work together to all achieve success.