Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Agile/Scrum Velocity for Non-Agile Teams

4.00/5 (1 vote)
9 Oct 2012CPOL6 min read 15.9K   194  
Agile concepts for teams not using Agile.

Introduction

In this article I attempt an approach to apply Agile flavor to SDLC even if the team doesn't claim to use Agile (e.g., Scrum). I extend and refine the concept of velocity so that a Non-Agile team can use it on projects e.g. because if you are Non-Agile (Non-Scrum) you may not use sprints. If this looks like not related to Agile it is because I target Non-Agile teams. It is not an coding article but one about creating the environment for better coding. You can go directly and play with the attached Excel's formulas and imagine how you manage a team, then if you want the Excel example explained just read further. 

I worked in both Agile and Non-Agile teams and whenever I got back to Non-Agile I missed, e.g., Agile/Scrum aspects; so from here the idea to try and apply Agile concepts without claiming to be "Agile", maybe as a hybrid SDLC or as an intermediary step or experiment to become Agile, or for whatever other reason you may think of. 

Background

The Non-Agile teams may have few points of struggle: estimation, prioritization and reporting back to the business. If Non-Agile teams can calculate velocity that may add valuable metrics to help with the above. 

Sometimes businesses and IT can't understand each other because of the terminology barrier; ideally Agile should simplify that, unless we start only "delivering points" sprint after sprint.

However Agile values like: morale, respect, having team members involved in decision making, etc. may simply not work in "real life" where the SDLC is deeply affected by anti-patterns and conservatism. In such cases Agile velocity is all about how much disclosure we are ready to allow when the velocity starts looking inevitably bad.

Points of Interest  

Velocity is a simple and robust model that could make any SDLC to rely less on assumptions and more on metrics: specific, measurable, achievable. 

So let's start by using the "Non-Agile team weekly time sheet" as input to calculate velocity. I included screenshots and a simple Excel example (see attachment and screenshots) to show what I mean. In the first  screenshot below we have - let's say - the weekly time-sheet that is "task centric" and not team "member centric" for simplicity and because you don't always need to see each team member explicit contribution but you surely want to focus on delivery and task % completion. Also you don't even need everyone to fill time-sheets, you reduce the "paperwork" and just let coders code; maybe this is only for the PM - imagine you have projects instead of tasks so we extend velocity from sprints to projects. Please don't take velocity "ad litteram" as matching or not some Agile definition that you know, but you are right to think of it as speed because it is exactly that. 

So for velocity we maintain the black [%] column (in the sheet screenshot below): 

  • maintain the black [%] column as often as you want with the percentage of how much work got done;
  • the blue column will calculate the delivered effort in hours from the above percents;
  • the red column will calculate what's left to do - also in hours; 
  • the green column is how long the team (or the PM) estimated it will take to deliver. 

For now I named the columns only by color. Let's start to describe the names like "Delivered Value Time" - how can you deliver "time", but why would you deliver "points" instead?

Image 1

Agile / Scrum theory seems to consider "points" appealing (we know why): tasks are estimated in points, sprints deliver points, velocity is number of points delivered in the sprint. I've seen "points" confusing especially the business representatives - they talk costs and deadlines, now imagine that when nobody uses e.g. Agile/Scrum in the company. Why should the business learn another concept complicating initially the adoption of Agile? Let's use "time", everybody knows what time is and can directly calculate costs out of it, it is straightforward. So let's consider "Value Time", measured in hours, Task Value Time would be the ideal task duration (or we can talk entire projects) that we estimate e.g. if everything goes perfect and we deliver 100% in time. In reality we will do it slower or faster but with the goal to meet that ideal Task Value Time as close as possible with the Delivered Value Time that is our recorded progress / delivery up to date. We aim Task Value Time and we Deliver Value Time as it is the raw value added to the business, the "investment", don't think about any return to investment, it is purely a model to plan the "investment" and calculate how much you achieved.

The reports to the business will be in 100% known language as below - just an estimated vs. delivered graph - up to date as soon as we gather the time sheet information from the PM or team members.

Image 2

One more step to XVelocity as below. Even if we don't split the work in sprints - we only relate to projects - we can still maintain velocity, sprint after sprint or project after project. The XVelocity percentages show e.g. how much can you under-commit or over-estimate e.g. to cover unexpected time loss or under-estimation.

Image 3

The Sprint Time (or project time if we don't use sprints) is the sum of all paid hours for all the involved team members related to the sprint or project, in reality you won't deliver this value 100% but you can aim it as optimization criteria. All this values on the columns can change as we progress e.g. one team member has an personal emergency that blows CST down 40 hours or we find an unexpected system dependency that turns TVT from green to red; the related XVelocity will show all this variations and require attention and corrective measures in real time if you fill DVT % daily for tasks or at least weekly for projects.  

The Commit Sprint Time is the above Sprint Time without the time off like public holidays, vacations, seek leave, team members moved to other projects, etc. We can call it Commitment Loss, so this model provides the metrics to closely manage time: if you have low commitment, e.g., during Christmas you can push up Task Value Time to minimize the value time loss. Play with the attached Excel example!

What I find interesting about velocity is XVelocity that can show interesting aspects like: how much business process and technology the team knows (Delivery / Estimation), how much the team knows about itself - the bond - (Delivery / Commitment) and how effective the management may be knowing the team and the environment (Delivery / Sprint Time). 

The attached Excel file is a simple implementation of the above, I hope it helps. 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)