No matter what are you working on: big project, start up, just some activity with defined deadline - you must always track it and know where you are at the specific point of time? As you all know following things are being tracked: Time and Cost; Resource Allocation; Progress and Efficiency; Risks, Changes, Issues; Project Health.
Sounds very easy and obvious, but when it comes to real life it occurs not so straightforward - as the result projects miss their deadlines and budgets, customers are not satisfied and so on. What i decided to do is to compare standard and lean (agile) approaches in context of project tracking. I am considering Scrum as an agile approach.
Time and Cost
Standard
Put an hour aside every week to determine if you are likely to complete the project on time. To do this, identify any tasks that are running late and determine whether they are likely to delay the overall project. Then look for ways that you can save time by; finishing tasks earlier, delaying non-critical tasks to after the project has been completed, or gaining approval from your Sponsor to remove tasks altogether.
You also need to review the total spend of the project to date against the original budget set. Identify ways to reduce costs by allocating cheaper resource, reducing the project scope, or boosting the efficiency of your team.
Lean/Agile
Each project must have a product backlog - a single list of features prioritized by business value delivered to the customer. The Team demonstrates to a customer potentially shippable peace of solution, with the most important features addressed first. It is not important how much time you spent on this; it is more important how much work is left. Simple product backlog burn down chart easily indicates if there is a risk of not making it on time and agreed budget. You can also address high technological (or others) risks during the first sprints and clearly communicate/demonstrate it to your customers and probably discuss potential trade off‘s (remove some features and etc). Theoretically customer can even decide that demonstrated functionality is enough and stop further development.
Summary: simple rule in scrum - demonstrate what you have done at the end of the sprint. It allows you to be more transparent to you customer and have more constructive discussion while choosing trade off‘s or making other decisions in tracking project’s schedule and budget.
Resource Allocation
Standard
You need to keep a constant watch on the percentage of time that your team is allocated to tasks. If you have one person allocated to tasks 50% of their time and another 150% of their time, then you may not be working efficiently. Instead, balance workload fairly so that your team is kept busy 80-100% of their time, without being overloaded. If you intend to overload resource, then only do it for a short period of time, to avoid “burnout”.
As you reallocate work among your resources, keep an eye on the overall resource level. It may be that everyone is under-allocated and you can take a person off the project, saving on cost. On the other hand, if everyone is over-allocated then you may need to quickly allocate more resources to the project as soon as possible.
Lean/Agile
The team in Scrum is typically five to ten people, although teams as large as 15 and as small as 3 commonly report benefits. The team should include all the expertise necessary to deliver the finished work and it is self organizing. Project managers can replace the time they previously spent “playing nanny” (assigning tasks, getting status reports, and other forms of micromanagement) with more time “playing guru” (mentoring, coaching, playing devil’s advocate, helping remove obstacles, helping problem-solve, providing creative input, and guiding the skills development of team members). So, in fact this shouldn‘t even be a problem anymore, team will handle it by themselves.
Summary: agile approach allows you to focus on other tasks rather than trying to allocate tasks to team members. (And this is not very effective in a lot of cases when being done by manager)
Progress and Efficiency
Standard
You also need to track the progress and efficiency of your team. ‘Progress’ means the percentage of tasks completed to date. ‘Efficiency’ means the number of tasks completed on time. You need to track these items to ensure that you are progressing according to plan and that your team is working efficiently in completing tasks assigned to them. There are a lot of software tools that provides you with progress and efficiency information, as well as the usual project planning and tracking features.
Lean/Agile
Progress is tracked, but a bit differently. As I mentioned above it is important how much work is left (either within the sprint or product backlog). Effectiveness of the team is measured in sprint velocity - how much work is done per sprint. (It is calculated from previous sprints in most cases) It is not so important to track if everything is being implemented according the plan; main thing is to make sure that current plan helps to achieve desired results, or should the plan needs to be changed?
Summary: agile approach is more focused about what features (not tasks) are already implemented and make sure that only high priority features are being implemented in first place.
Risks, Changes, Issues
Standard
Every project encounters risks, changes and issues at some point. It’s often impossible to prevent them from occurring, so the trick is to resolve them as quickly as possible when they do come up. Throughout the project life cycle, you need to watch them closely. For each item raised, set a ‘target resolution date’ and track these dates carefully to make sure that they are adhered to.
Lean/Agile
Benefits of agile approach are the most obvious here, since according product backlog only high priority (the most important, the most technically difficult, and the riskiest) features/tasks are being addressed first and presented to customers at the end of each sprint. If changes occur in the middle of the project they are always introduced during the sprint review to customers and prioritized along with other features. As the result better understanding and transparency between customers and developers is achieved.
Summary: with the help of agile approach risks are addressed much earlier and results/changes are communicated more often. As the result it allows to make better decisions.
Project Health
Standard
In addition to tracking the project at the micro level, you also need to stand back and take a look at the project from a helicopter level. You need to gain a clear view of the overall project health. You’ve already done most of the work by assessing the time, cost, resources, progress and efficiency of the project. By also taking a summarized view of the project each week, you can lead the project team towards success.
Lean/Agile
Sprint retrospectives help the team to review the progress of the project and agree on improvements for next sprints. Sprint retrospective is an opportunity for the team to discuss what’s working and what’s not working, and agree on changes to try.
Summary
The goal of all development approaches and practices is to finish projects on time, on budget and with agreed -upon scope. But it seems to be that agile approach is the most effective and transparent way to do that. Even though Scrum is the framework with a small number of rules, but there are common challenges in adopting it. Scrum tends to make visible a lot of issues that exist within the team, particularly at the
beginning. For example, most teams are not good at estimating how much they can get done in a
certain period, and so will fail to deliver what they committed to in the first Sprint. To the team,
this feels like failure. In reality, this experience is the necessary first step toward becoming better at estimating, and with the support of a scrum master, the team can be helped to see it this way. Another difficulty a team might have is around the Daily Standup Meeting - getting all team members to commit to gather at a specified time, on time and every day without fail, may require the team to operate at a higher level than it’s accustomed to, and some teams will be unable to do this. One very common mistake teams make, when presented with a Scrum practice that challenges
them, is to change the practice, not change themselves.
