How Do We Help Agile Engineering Managers STAY AGILE?
This post explores the challenges associated with loading the burden of project management onto Engineering Managers (EMs) as opposed to Project Managers (PMs). We will also delve into the question of whether project management even belongs anywhere in the modern agile space of developing software applications, SaaS products and managed service offerings.
EMs vs. PMs: The Spectrum from “How” to “When”
EMs are typically accountable for the work performed by their teams for shaping and crafting, char-by-char, config-by-config, the stories and features that have been articulated and prioritized by product owners and product managers. EMs are accountable first and foremost for the technical output of their teams. We could measure their effectiveness by how well their development teams fashion technology into solutions that match customer needs. Our perspective on this would characterize EM effort as being technical, ongoing and evolutionary with respect to the work of iterating products, and most concerned with the “how” in terms of fashioning technology into fulfilling solutions.
On the other end of the spectrum, the work of project managers is concerned with finite efforts that have a distinct beginning and end based on reaching some final state or outcome. In the modern day, the approach of PMs can be starkly contrasted with that of a typical EM role in that EMs usually approach a product as being evolved over time such that it is never necessarily “done,” but is instead in a continuous state of improvement. PMs are concerned with being “done” with something, ensuring quality control against requirements, and moving onto the next effort. Our perspective on this would characterize PM effort as being sequential and finite and and most concerned with the “when.”
Misuse of Project Management in Agile Frameworks
I commonly observe shops who claim to be agile, claim to be using Scrum or Lean Kanban, and then turn to EMs to commit to delivering by a certain time. The slippery slope that leads to this chasm most off begins with questions asked of EMs that begin with, “How hard would it be to…?” This conversation most often leads to a verbal estimate, which inevitably ends up as a hard delivery deadline that EMs have committed to. The act of managing against timelines is a feature often found in traditional approaches to project management.
Contrastingly, modern agile product frameworks in which EMs are supposed to be working are designed to negate the need for ad hoc estimates and commitments to deadlines in lieu of agile refinement and prioritization processes. These processes are designed to provide control around what gets developed in each sprint (i.e. timeboxed portion of effort) in a predictable way.
How Can We Use Agile to Maximize Predictability and Productivity?
It begins with executing your framework so that the teams in your organization have a measurable development velocity. This is done by measuring each functional unit of work (i.e. story, feature or epic) that has been articulated for development. This can only be done well if accomplished over time, and with a team that has been executing their agile framework ceremonies consistently and correctly. EMs have a role in driving their teams toward this consistency, with the goal being estimates that become more accurate over time.
Next, your shop must maintain a backlog that is larger than team velocity. This area exposes one of the most common mistakes I observe. Teams approach their work like a project, in which they limit efforts on articulating their backlog deck to the things that are about to be developed (in the near-term). This ends up limiting the scope of future predictability.
To achieve predictability and control, you need to develop discipline around agile that drives the functional operatives facilitating the articulation of discovery and functional scope (e.g. product managers and product owners) to always stay ahead of your current sprint. We recommend building an OKR to measure this and adopt a standard to continuously maintain a backlog that is 4x your velocity. This will allow you to have some delivery predictability. It will also prevent breaks in team productivity to stop and write Jira stories for the next sprint, and results in better decisions about what to develop in upcoming sprints.
Should My EMs Be Burdened With Predicting Delivery Times?
No.
If your teams maintain accurate velocities and extended backlogs, your product managers and product owners should collaborate during backlog grooming ceremonies to estimate delivery in terms of what fits into a sprint based on velocity. A mature agile shop will enjoy the ability to prioritize what goes into the next sprint and deliver it reliably. Future sprints can then be planned using the backlog and velocity, allowing product managers to control the delivery sequence and timing of stories and features per customer need.
Instead of making predictions, EMs should help instill the discipline to achieve this level of predictability by supporting the adherence to your agile processes and ceremonies.
Should EMs’ be Liberated so They Can Focus on the Tech Quality of Your Products?
Yes.
Liberate your EMs from project management so that they can focus on making sure the people on their teams are executing the “how” correctly. This means making sure code reviews are happening. It means making sure peer-programming and group solutioning are going on. It means intervening in solutions that their teams might be fashioning in a silo that may need to be connected to fundamental redesigns/fixes, new capabilities or transformational strategy going on in enterprise architecture, or in other areas of your organization.
Bottom line – you want to allow EMs to focus on these things rather than bog them down in delivery timelines and project management. EMs’ sustained focus in the right areas will maximize delivery speed as well as product quality.
Can PMs Further Liberate and Empower EMs?
Yes.
Above, I mentioned fundamental redesigns and fixes that may be connected to functional and technical debt. Attacking these things can benefit from a project-based approach where there is a plan with a beginning and an end. These are valuable opportunity spaces for your EMs to cross function with EMs from other domains and collaborate with enterprise architects to become informed. This empowers them to lead and align the solutions being developed in their teams’ current sprints with the direction the organization is going in the long-term.
These peripheral efforts can often be chartered projects, which should be managed by seasoned project managers. EMs should be allocated to these projects as role players and stakeholders. The right structure here can enable agile product teams to remain informed and connected to what is going on around them through the conduit of their EMs’ involvement in other areas of the organization, while minimizing interruptions of the dev team members and their agile sprints.
Closing
Is your shop in need of organizing your portfolio of effort to achieve these benefits? D’Mention Systems has over two decades of combined hands-on experience in portfolio management.
Please reach out – we would love to help determine the best approach, agile or project-based, to give you maximum control, predictability and sustained delivery speed.
Mike Liskow is a business development consultant, writer, artist, entrepreneur and thought leader in the business development space for tech startups.
D'Mention Systems was established in 2003 and provides business development consulting engagements for tech startups.
