The Money Files

We all know that in agile methods, time is time-boxed. Iterations are the way work is managed. Time is fixed. But does that mean you don’t need to spend any effort thinking about time management? Not at all.

There are a number of different agile artifacts that influence and shape the project team’s approach to managing time on the project. They start with the product roadmap and get progressively more and more granular until you end up at the sprint backlog. If we’re talking sprints, we’re talking Scrum, but you can see how this approach is relevant for other agile methods too.

While there is a lot of flexibility in the ‘what’ in agile, the ‘when’ is pretty strictly controlled.

What are your top tips for managing time on agile projects? Do you use any other artifacts to help the team stay on track? Share them in the comments below!

Given the type of work that normally happens in an agile project – yes, we’re talking IT development – it’s common that the largest overhead is normally the team. People cost money because we have to pay their salaries. All the while they are tied up on a project they aren’t doing other projects. Those other projects could be more valuable to the organization. So it does matter how people spend their time.

If you are asked to cut the time of an agile deployment, how can you do it? If we’re focusing on staff costs, there are two main ways: increasing velocity (i.e. working more efficiently and doing more in less time) or decreasing scope (i.e. doing less so you finish earlier).

The infographic below shares a bit more about these two options.

What are your top tips for cutting costs in an agile project without cutting quality? Are there other techniques you use? Share them in the comments below!

You know I’m interested in the financial aspects of project management – I’m even thinking of teaching a workshop on project budgeting and accounting later this year. I feel like I’ve got quite a good understanding of the topic, but I’m constantly learning.

Having only done a very small amount of work in a team I would say is using agile practices, I am by no means an expert in the practical ways of making agile approaches work on project teams. However, there is a lot of guidance out there for people like me who want to learn more.

The Agile Practice Guide, in particular, has some interesting information about how to apply information from the PMBOK® Guide Knowledge Areas to agile work processes. From a financial perspective, here’s my interpretation of how this would work.

Project Cost Management in Agile Environments

Typically, on predictive projects you would do a lot of costing and estimating in advance. For projects with a high degree of uncertainty, or those where you don’t have a fully-fleshed out scope (hello, agile projects), then obviously you don’t have the data to do this level of cost analysis.

Instead, the recommendation is to use “lightweight estimation methods” (although no detail is given as to what these might be) to come up with fast, high level cost forecasts for resource costs. I can see this working when you are forecasting the general length of a particular engagement – even if you simply plan out the resource costs for the next financial period as a basic benchmark.

Detailed costs for things that aren’t people costs do still need to be done. You can’t run a successful business if you aren’t aware of what project work is costing you. It is OK, however, to do those detailed analyses on a more just-in-time and rolling basis.

To be honest, on some of the long programmes I’ve been involved with we’ve taken the same approach. The business case costs might have been fixed from the start, but frankly they were only ever our best estimate at the time. I then worked out detailed forecasts for the actual year we were in, so the Finance team could manage cash flow and we could accurately account for the capital outlay in the current financial year.

Where your budget is fixed, but you still need to be agile in other respects, then your choice is simply to flex scope and schedule to stay within the cost constraints.

Project Procurement Management in Agile Environments

Procurement management is another area where we incur costs, and as project managers, we need to be aware of how to manage that – in all environments.

Typically, procurements I have been involved with have had a protracted contract negotiation at the beginning to come up with a Master Services Agreement, and then you define the current engagement with a Statement of Work. As we needed suppliers to do extra things, we created new SoWs detailing that engagement. This is also how change control worked: the change control process generated either a credit note (when something was being changed and the end result was the development cost less) or a purchase order and an addendum to the current SoW.

It turns out that, according to the Agile Practice Guide, this is a pretty agile way of working.

There probably are projects where it is prudent and necessary to sign a massive contract upfront (ERP deployments spring to mind, from experience!) but generally, staying small with the engagement and working in a flexible way will suit both parties on the majority of projects.

Either way, something that is the same regardless of the project management approach you are taking is the need to document contractual arrangements and file them somewhere you can easily find them again. I have had a few moments in my career where I have sheepishly rung a vendor and asked for a copy of the executed contracts because – whisper it – it wasn’t possible to find our version of the same document.

Don’t make that mistake! Be agile. Be tidy!

Pin for later reading:

At Øredev, the software development conference in Malmö, Sweden earlier this month, Catherine Powell, principal at Boston-based software engineering firm Abakas, talked about the core structures the agile teams.

She described six core concepts for agile teams. Provided you have these six things then your team can be considered agile. So, let’s look at those six things.

1. Team

Catherine defined a team as a group of people who together are going to accomplish something. "You're trying to structure team with lots of disparate roles," she said. She advised that we define who needs to be in the team by role or function and then allocate these to people - people can have several roles. It’s the roles and the common goal that make people a team.

2. Backlog

An agile team needs a concept of backlog – the work that is still outstanding and that forms the requirements log. Without a backlog, you can’t structure the upcoming project work, so you need to store the backlog somehow so that it can be prioritised and incorporated into future releases.

3. Customer

An agile team needs the idea of a customer. In real terms, this is unlikely to be a ‘real’ customer who will buy the end product, so your team will have to find someone who can represent the interests of the customer. This could be someone from a business team, a tester or a product manager.

4. Done

You have to define what ‘done’ means to you. Catherine pointed out that you have to have a way of saying when you have arrived. For some teams this might be that a product is ready to ship and for others it might mean that testing is complete. However you define it, you can’t be an agile team unless you have agreed on what ‘done’ looks like.

5. Process

"Agile is not really about running around like chickens with our heads cut-off," Catherine said. She said that despite what some people think, Agile does not mean that there is no process. On the contrary, process is important to ensure that there are no bottlenecks and that work flows through the team adequately and moves from idea through to development, testing and release.

6. Heartbeat

The heartbeat of the team is the way in which they work. It’s “time-based predictability,” according to Catherine. It is not necessarily about how fast you work or how productive you are. For example a team of space scientists may work quickly, but still only have products to release or milestones achieved over the period of several months. On the other hand, a team of software developers working on a web software project may be making releases into production several times a week, or more frequently. The heartbeat of an agile team is this regularity. "It is extremely important to team morale," said Catherine.

These are the six things that Catherine said were essential to be a truly Agile team. "For me, everything else is negotiable," she concluded.

Which of these tenets do you apply to your Agile project teams? And do you think she missed anything? What else defines an Agile team?

In this video Keith Richards explains Agile project management and DSDM. He talks about how Agile helps organisations save money, and he shares a random fact about Arctic Terns.