Your transition to "Agile" (aka iterative or adaptive development) seems like a great idea, but what about time-tracking, schedules, and budget?
If you are a project manager or product manager, this article is for you!
MS Project Time-Tracking
When shifting to Agile or Iterative Development, it is common to focus on the development team; after all, they are the ones doing the work to deliver the functionality. However, agilists as a whole tend to keep agile out of project management or their intake process.
The result is an unintended direct conflict between project managers and agile teams.
Project managers plan their schedules, budget, and plans based on traditional project management and continue in the "command and control" mindset, causing frustration and confusion in indicating if a project is on-time and on budget.
Even the very inception of a project is rooted in the waterfall as they ask for "resource allocation" and attempt to predict the completion dates by creating a schedule that is based on the length of project activities. This leads to constantly asking, "How long did this take?" "What are individuals working on?" "How do we know if people are being fully utilized unless we track their time?"
Mixing methodologies is not good practice, and before I give you the solution, it is probably a good idea to take a brief dive into time-tracking.
Time Tracking: Where did it come from?
It is said that Benjamin Franklin coined the phrase "time is money."
In 1888 Willard Bundy is credited with creating the mechanical time device to help keep track of employees' time. This worked well in manufacturing, but those in the service industries preferred a per-project fee. Billable hours paved the way for charging for services based on the time it took to perform them.
As this practice evolved, it found its way into project management.
Projects have a defined start and end date, so to effectively plan the budget and project plan, project managers need to track planned time and actual time spent completing a project activity.
Time tracking is challenging because it is based on gut feelings rather than data. (Have you ever attended a project status meeting where someone said they are 50% complete, and the next status meeting, they say again they are 50% complete? This is a gut feeling. There's nothing definitive to prove it is truly the percent complete.)
Professionals who work on many different projects at once are encumbered with entering project numbers, cost centers, and hours spent on multiple project activities, and it is difficult to input accurate numbers.
Think about the day of a developer who is not on a dedicated team. They do not consciously allocate an hour to a task that belongs to a single project and then an hour on another task for a different project.
Throughout the day, they constantly shift focus, and unless they are jotting down 5 minutes here and 30 minutes there, it's impossible to know exactly how long a project activity took.
I was a business analyst working on three different projects many years ago. I certainly did not write down the time it took for every task for each project, so I simply put my allocation in the form of hours on the time sheet. If I were allocated 25% to each project, I would put 2 hours into the timesheet for each project code, regardless of how long it took.
Though my intent is to be accurate, it would take too much time to jot down the start and end times for each task I performed throughout the day.
The lack of accuracy is one reason projects do not meet schedules and go over budget.
Exceeding schedule and budget is frequent with traditional project management, and diving into the reasons requires a different blog post!
Why is it difficult for Project managers to embrace agility?
Project managers do not intentionally reject agility. Most of those I have talked with or coached think it is great for development teams. However, they find it difficult to see how their process fits the new working method.
Unfortunately, many agile coaches and scrum masters do not have the experience or enough understanding of the "whole" to bring change further than the development team, leaving intake, project prioritization, and project management processes to continue in a traditional waterfall style.
It is said that Agile is simple, easy to understand, but hard to master.
This is because changing how we work requires a change in mindset. Mindset is difficult to change.
Project Management Institute teaches that project managers are solely responsible for the project's success. (check out the PMBoK for more information)
They define project success as:
On schedule
Within or below budget
High quality
In other words, sticking to the plan. Once the plan and schedule are set, the goal is not to deviate from the plan. Regardless of the customer's need. (Ever experienced a change request log?)
They are taught to "command and control."
Shifting to a customer-centered or product mindset shifts the responsibility from one person (the project manager) to the product team.
It's important to understand the responsibilities of a project manager and how those shift to the team to better understand why this shift is difficult for those in project management.
The below graphic came directly from the PMBok (Project Management Body of Knowledge). It illustrates the process and responsibilities of a project manager.
The illustration is taken from the Project Management Body of Knowledge.
The below graphic illustrates how the responsibilities shift from the project managers to shared ownership of responsibilities.
There's much to say about how project management changes with Agile Frameworks; I will dive deeper into this in another article.
The Product Mindset: How is it different?
Product management shifts the focus from following a plan to delivering value to the customer and to the business.
Agile focuses on simplifying complexity, adapting quickly, shortening feedback loops, and working collaboratively with dedicated cross-functional teams. Features are directly tied to business goals and objectives, ensuring we deliver the highest value. Lean has a focus on efficiency, removing waste, and a concentration on only doing those things that are value-added.
Winston Walker Royce was an American computer scientist who worked for Lockheed and is known for his paper (from the 1970s) "Managing the Development of Large Software Systems" He is often credited with endorsing and promoting waterfall.
However, in this paper, Mr. Royce specifically notes the approach, which we call waterfall, is flawed. (I wonder how many folks who use his waterfall graphic actually read his paper that includes comments on the traditional process).
The below was captured from his paper, with some added notes (the red is not from the original graphic).
For those who continued to read his paper, he describes a better way of developing software by integrating often, documenting, and testing throughout the process. (Does this look familiar?)
Software development is complex, and waterfall is not suited for complex environments as it is impossible to define and plan everything upfront.
Knowledge is uncovered and shared as the teams work.
The product mindset shifts the focus from the "plan" to value delivery.
Projects are temporary; the members of the project team work together temporarily. Hence the reason to find resources and allocation (50%, 25%, etc.) of resources.
Product teams are persistent. They stay together for the life of the product. They work on new development, maintenance, tech debt, and "keep the lights on" activities.
Instead of funding the "project," we can shift to funding the product team or value stream.
Projects will still exist from a bird's eye view, but from a team view, they are just supporting the product.
Because product teams or value stream teams are persistent, it's easy to budget.
You may ask yourself how in the world I budget something without knowing the work breakdown structure and how long activities take. Keep reading!
Traditional Project Management: Budgeting and Schedule
Let's touch on how traditional projects are budgeted before diving into how we can budget and predict agile teams' schedules.
For the sake of time, I have oversimplified the explanation.
Project management has three main constraints (known as the iron triangle). They are:
Cost.
Time
Scope
The scope is fixed at the time the project starts. Any deviation or significant change is logged on a change request log to be analyzed and budgeted. If approved, it is scheduled based on cost.
Cost and Time are variants; once the project starts, the focus of the project is constantly communicating status, monitoring, and controlling cost and schedule.
This is why project managers spend 90% of their time in status meetings, asking or communicating what has been done and what is left to compare it to the plan to determine if the project is on schedule and within budget.
The project manager breaks the project activities (not the work, but the activities needed to complete the work) into the smallest logical form to create a Work Breakdown Structure, and then, based on experience and gut feel, the members provide individual estimates on how long they think it will take to complete their individual activities.
Cost is then calculated by taking the average market rate of each role and the sum of the time. Most organizations have standard hourly rate sheets for each role (front-end engineering, back-end engineering, contract workers, quality testers, and UX design)
Actual time spent is gathered via a timekeeping tool, and each member enters their actual time spent on each. This data is compared to the estimated time to determine if the project is red, amber, or green. (RAG status).
If the project is not green, corrective action is immediately taken to align and get the project back to green. This can drive bad behavior.
Corrective action results in things like:
Overtime
Micromanaging
Cutting down time for testing.
Changing the delivery date
Undue stress and lower morale for the project team. Such stress will impact performance.
Start cutting corners to get it done faster, increasing tech debt and negatively impacting quality. (Ever heard of workarounds?)
Example of a Work Breakdown for a website with estimates
Software development or engineering is complex. It is impossible to accurately plan and estimate everything upfront. Traditional project management works best when environments are not complex, and requirements are fully known and not apt to change. This is why adaptive or iterative development works best.
Adaptive or Iterative Development: How Agile teams work
Traditional project management isn't a good fit for an agile environment for many reasons:
The landscape is complex
We learn and discover as we work
High-collaboration is needed
Agile breaks down the customer need not the activity to do the work
Teams work as a team, estimate as a team, and work in sprints.
Testing is built-in and not done solely at the end
Characteristics of an Agile Team
Small and cross-functional
User stories instead of Business Requirement Documents (BRDs)
Estimate as a team rather than individually
Testing happens frequently and is integrated into the process
Works in short iterations (2 weeks- 4 weeks)
Shortened feedback loops to adapt to a change in "requirements."
In adaptive development, the scope is flexible while time and cost are fixed. How can this be?
Teams are dedicated and persistent.
No need to find resources are partial allocation to projects
Teams work in sprints (most common is two weeks)
They commit to what they can finish within the two weeks
Work isn't broken down by activity but by customer need or functionality.
Using the WBS example from the graphic earlier, this is how a team would breakdown the work
You may immediately notice the lack of estimates. How would one determine the completion date or if we are within the budget?
Doing this is in direct conflict to project management, and you may observe or experience project managers constantly asking, "how long did this take?" "Can we add a due date to stories and tasks, so I know if we are on schedule?". They are not trying to be difficult; they are simply trying to reconcile performance against the project schedule. No one has taught them how to do so with agile teams.
So now, let's dive into a few ways a project manager can budget and know if a team is on schedule.
The Good Stuff: How to budget and Predict an Agile Team or Initiative
If you jumped directly to this section, I urge you to go back and read through the previous paragraphs for overall context.
Now for the good stuff!
Scenario: Building a new web application
The Team
Eight members
Two front-end developers
Two back-end developers
Two business analysts
Two QA testers
They are 100% dedicated to this work.
Sprints
The team is working 2-week sprints
They have worked together for approximately one year as a dedicated team.
A full day is 6 hours, meaning we can expect the team can focus on this work 6 hours a day.
The rate sheets for the team members.
Even if the team is salary, it is common to establish an hourly rate for each role to determine the cost "of labor" for the functionality or project. That is why you see an hourly rate column.
These are not actual rates for the employees since compensation is confidential.
The rates are typically an average of entry-level, intermediate, and senior roles, or an organization may use average market rates. Each organization's project rate sheets are unique.
*The below table represents rate sheets I have seen within organizations. This is not taken directly from any one corporation.
Role | Average Hourly Rate |
Front-End Developer | $100 |
Back-End Developer | $125 |
Business Analyst | $85 |
QA Analyst | $95 |
What is the cost?
We can calculate the sprint, quarter, or year cost based on the members and average hourly rate sheets.
Calculating the daily cost of a team
I typically use 6 hours as focused hours on sprint work. It is common for traditional project management to use 6.2 hours as a full-time "resource" for a project. Below, you can see how to calculate the cost of a sprint.
If you have someone who is partially allocated (a big no-no), you may adjust the daily hours for your estimate. However, base the allocation on 6 or 6.2 hours.
For example, if someone is 50% allocated, their daily hours are 3 hours.
Role | Avg. Hourly Rate x | Daily Hours | = Daily Cost |
Front-end dev | $100 | 6 | $600 |
Front-end dev | $100 | 6 | $600 |
Back-end dev | $125 | 6 | $750 |
Back-end dev | $125 | 6 | $750 |
BA | $85 | 6 | $510 |
BA | $85 | 6 | $510 |
QA | $95 | 6 | $570 |
QA | $95 | 6 | $570 |
Total Daily Cost | | | $4,860 |
$4,860 is the estimated daily cost for this team. Since a two-week sprint is ten days, the below illustrates the calculation.
Total Daily Cost x | Sprint Working Days = | Sprint Cost |
$4,860 | 10 | $48,600 |
The sprint costs $48,600.
This is why I said time and cost are fixed in Agile. The team is persistent; they work in 2-week sprints, so the sprint cost is always the same. Exceptions would be when sprints are less than two weeks due to holidays etc. For the most part, we always know the cost of the sprint.
The narrative becomes, what value is or can be delivered for $48,600?
You can carry on this calculation to find the cost of a quarter
Cost of a Sprint | Sprints in a Quarter | Quarter Cost |
$48,600 | 6 | $291,600 |
Budgeting the cost of a feature or the cost of the entire initiative
So how do we figure the cost of a feature? Features should fit within a quarter; a quarter is about six sprints worth of work. If you know the cost of the sprint, you can multiply it by 6 for the cost of a feature. Remember, this is an estimated cost.
An initiative spans sprints and quarters. We should confer with our engineering teams or leads when estimating an initiative for greater accuracy. If an initiative is estimated to take a year, we can figure the total estimated cost.
Cost of a Quarter x | Quarters in a Year = | Total Estimated Cost |
$291,600 | 4 | $1,046,400 |
What about estimating the initiative or feature cost when a team has not been established? There are several ways to do this, and one simplified way is to estimate based on the max allowable team members (let's say 10) and the average rate of all roles.
Start by averaging the hourly rate for the roles on the rate sheet.
100+125+85+95 divided by 4 = $101.25
Multiply by the maximum allowed for a scrum team (we will use 10)
Team Members x | Average Rate x | Daily Hours= | Estimated Daily Rate |
10 | $101.25 | 6 | $6,075 |
Now we can calculate the sprint and quarter estimated costs. However, how do we proceed if we don't know how many people or teams we need? That is a topic that requires more explanation and I will tackle that another time.
Funding Teams for a Quarter vs. Funding a Project
As a project manager, how often have you gone to finance to get funding for a project only to have to go back for additional funds? It happens frequently. I have been in this position more than once in my "old project management days". Quite the uncomfortable conversation.
Traditional projects typically last about three years and could cost hundreds of thousands or even millions of dollars. We have no idea if we are building what is expected or if it will be profitable until the entire project is delivered.
Funding teams by quarter significantly reduces risk, especially if teams are demoing their work for feedback.
Imagine doing a 3-year project that costs 5 million dollars vs. delivering the MVP in 12 weeks. The customer need could change in the three years and by the time we deliver what they asked for (3 years ago) they may need something different. The result is we wasted $5 million. But, if we deliver an MVP after 12 weeks and they need changes, we can easily adapt, and we only spent $291,600.
I was helping a team transition to Agile, but the PMO still followed traditional project management. I sat down with the project manager and showed him how to go to finance and ask for only a quarter's worth of funding. He did, and he was approved. The best part is that the team delivered it under the estimated cost! Follow or bookmark my blog if you would like to know more! I will deep-dive more in a later article.
What About the Schedule?
The most common contract within project management is the fixed-term contract. These state the customer or buyer gets exactly what they want and are willing to pay for. We get requirements, estimate the time and deliver by a date based on gut-feel estimates.
This seems logical but it also assumes the customer's needs are well understood far in advance of implementation. The beginning of a project is when the least amount of knowledge is known and buyers don't always know how to effectively communicate every detail, they just know what they want to do.
These types of contracts are based on win-lose scenarios.
These types of contracts usually have aggressive dates.
A date that is committed to before discussing with engineering, resulting in project teams rushing and stressing about meeting the date.
There is a more collaborative approach to contracts.
Instead of saying, "we will deliver this on MM/DD/YYYY," say, "we can potentially deliver this late quarter three, we will know more once the team starts working, and we will keep you updated. "
You may think clients will never accept date ranges over dates. They will if the development teams deliver quickly, are predictable and the quality is high.
Roadmaps should be quarterly and not include actual dates.
So how do we know what date ranges to communicate? We can figure it out the same way we calculate the cost.
For example, if an initiative has two features and a feature typically takes six sprints or 12 weeks, then we multiply two by 12 weeks to estimate when it will be done.
Scaling down to the MVP is important in road mapping. The purpose of the MVP is to prove the original hypothesis, and if we prove it, the team keeps building out the product.
Agile Teams can Forgo Time Tracking.
If we make the shift to dedicated value stream teams (it is possible, I can show you how), we will always know how much the team costs. If we know that, we no longer need to burden teams to input time into a tool. We no longer need someone asking teams, "how long did this take?" and the topic of resources needed or resource allocations becomes obsolete.
Your plan should be based on features and quarters to track if we are on target. More than that, the team determines what they can do per sprint, which should not be dictated to them. We base our date-range commitments on the historical performance of the team.
If I have piqued your interest and you would like one-on-one coaching to learn more, please contact me; I am happy to help!