When Agile meets yearly IT budget

There is a well-known problem when Agile projects meet a client’s yearly IT budgets. The problem with the yearly budget is that

1. It is largely incorrect as it has been planned with minimal information

Most big organizations have a budget review only once a year where a CIO and his team have to decide what their future looks like for the year. This is the time when everyone looks into their magic crystal ball to estimate the amount of funding required for their projects in the financial year.

These numbers are largely incorrect purely due to the scale at which they are done and with the limited amount of information available upfront.

2. Fosters project thinking and deliver under budget than building the right product.

Once a ballpark yearly budget figure is reached after minimal planning by project teams, the teams are encouraged to plan in more detail to secure their exact funding required.

Project teams then start building their detailed product backlog of stories with estimates and break it down into releases through the major part of the year to come up with their funding numbers which are then secured.

This not only results in a lot of upfront planning even in Agile, but also focuses the team on delivering that huge backlog of stories under the project budget, than focusing on building the right product fit for the market. Needless to say that these big backlog of stories often get outdated within the first few iterations and so does the estimates and hence the budget plan.

So is there an alternative?

The good news is that a lot of companies are beginning to recognize this problem. And these are companies who view their products as “Strategic IT” investments and not an operational overhead. The solution requires changes in 2 key areas, budgeting and project planning and tracking.

Rolling wave or Quarterly budgeting

A year is clearly too long to forecast and budget for upfront. One option is to budget for the first couple of iterations and then budget the third and fourth just before the completion of the second iteration based on real data. This ensures that at any point in time you have budget for the next couple of iterations.

If a couple of iterations are too less for long-term visibility, the other option is to do it quarterly.

The advantages of this approach are

1. More informed hence accurate budgeting based on actual data on the ground.
2. Encourages people who own the high level budget to engage with the team on the ground at least once every quarter.

Track projects to measurable goals and not to a product backlog.

Not having to forecast a yearlong budget is a boon to an Agile team. The team can then focus on building just enough of the backlog for their product to be able to validate it with end users and then pivot or preserve as necessary.

This is a mindset shift to the traditional Agile/Scrum technique of doing discovery workshops and then building a backlog of user story phrases that are then elaborated every sprint.

Instead, the team needs to come up with clear and measurable goals on how they measure the success of the product. This could be things like increasing user uptake of the product by releasing some new features, improved customer service, launching a new brand / service etc.… As some of these goals might be long term, it is important to break them further down to a level that can be measured every month or a quarter. An example would be to validate an idea for a web page with 5 users before building 3 similar web pages in the subsequent iterations and validating with 50 users.

The owners of the budget in this case can decide based on the progress towards goals of the first few iterations to fund / invest in the next few iterations. This also gives them on option to pivot or preserve based on what they see built so far.

To summarise, the advantages of this approach are

1. Less of time spend in estimation of effort and more time thinking how to build something valuable
2. Keeps stakeholders who make budgetary decisions more engaged in the product.
3. Makes product owner more responsible to think and show results building the right product than forcing the team do deliver a backlog

References

The Budgeting Black Hole - Johanna Rothman

Annual Budgeting and Agile IT - Ross Petit

Lean Startup – Eric Ries

Implementing Beyond Budgeting – Bjarte Bogsnes

The problem with Continuous Delivery & DevOps as an IT investment

In Thoughtworks we have a lot of experience in implementing Continuous Delivery , and we have done it project after project under some name or the other. In fact we did it long before Jez even wrote his book on the subject. (Jez talks about one of those projects here). I remember roles which we used to call Build Masters/Engineers, even Build Monkeys and teams such as Build and Environments team which practiced the same principle. These teams or roles used to be specialised and sat outside the group of people who delivered functional user stories.

Today we call the people DevOps and the practice Continuous Delivery, but largely we have the same problem as 10 years ago. DevOps is seen as a separate team and Continuous Delivery is seen as an IT initiative. In fact organisations have gone a step further in this direction to appoint IT heads for continuous delivery who are in charge of such teams.

The reason Continuous Delivery becomes an IT initiative

1. Business sees it as an IT investment

In most big organisations business teams are still keep a safe distance from the gory IT details and more so from IT Operations and Support teams. (Business teams have more to worry about in their lines of business). In their view Continuous Delivery is an IT Operations issue solely as it will minimize the operation spend for IT. They see the key driver being within IT and the impact only on the IT operational cost and hence believe that Continuous Delivery should largely be an IT investment and if an organisation wants to do it, the IT budget should cover the cost and not the business.

2. The practice is seen as a mighty legacy systems/operations overhaul

In most large (> 1000 people ) organisations such as banks and insurance firms there are a whole lot of legacy infrastructure lying around. These are systems on which no one has ever attempted writing a single automated test. Deployment is a humongous tight coupled multi-step process which no one has ever imagined being done with a batch job.

In such places an IT organisation has to start somewhere and that cannot happen without a focused initiative. This results in a new department whose sole job is to focus on bringing in the continuous delivery practices into the organisation.

Problem with a separate DevOps team with an IT budget

The problem with a DevOps team funded by an IT budget is that it results in another glorified Operations/Support team, only this time balanced with application developers and sys admins. Being centralised to project teams, this team ends up doing any work classified as "Infrastructure" such as provisioning and configuring virtual machines, optimising and maintaining the build environments, production server monitoring etc...

Product owners, on the other hand, push their teams to deliver more functional stories and encourage them to delegate any "technical/infrastructure" work to the DevOps team. This results in product owners distancing themselves from the benefits of DevOps which is contrary to the whole principle of Continuous Delivery, which is to demonstrate rapid responsiveness to change and hence create a strategic impact for the business.

Moreover some DevOps teams work with a goal to make themselves redundant and merge themselves with functional product lines. This goal often remains an aspirational one with their ever growing backlog of work.On the contrary DevOps teams end up creating their own silo with specialised skills which developers on project teams struggle to keep up with.

There are enough reasons for business to cheer about Continuous Delivery in the longer term. An investment from a business unit will only result in business teams working closely with IT, which is at the heart of Agile and Continuous Delivery. Business teams will be able to find new ways of creating a bigger strategic impact and have an edge over their competition. Hence for the right alignment within the organisation, funding for Continuous Delivery should come from a Business budget.

Why you should care about experience design and continuous delivery as a project manager ?

I had written earlier about how a good project manager in a mature Agile team needs to go beyond managing scope, time and budget to be really effective in his/her role. The key is to understand the product and the tools and techniques used by the team to build it.

But there is more a project manager should do, which is, to provide the right direction to the team. The focus shifts from "building the thing right" (i.e delivering within scope , time and budget) to "building the right thing" (a product that fits the purpose the business and its users).

Building a delivery engine that can react quickly to market feedback and adapt needs focus in a few different areas than traditional project management. And this is where project managers should have a good understanding of experience design and continuous delivery.

From a continuous delivery perspective a PM should have a good understanding of

* The level of automated testing required to certify almost production quality builds in no time.

* The value of using a production like environment for testing and feedback.

* How automated deployments can help speed up time required to deploy to multiple environments and rollback quickly if the need arises.

* The need for real time monitoring of production systems for the team to quickly respond and fix production issues.

* How one can benefit from feature toggles v/s branching.

* The advantage of releasing quickly and minimising work in progress to shorten the feedback loop.

The main advantage of continuous delivery is not so much in reduction of deployment and maintenance costs. Instead it is in the capability it provides to validate and adapt the product being buit quickly based on end user testing and research.

It is important , as a PM to know

* If we are doing enough user testing to validate what we are building at regular intervals ?

* Are we doing enough user research to provide critical user context data in the form of personas etc...?

* Do we have good analytics capability built in the product to profile usage patterns which can help us make informed decisions about the product?

An insight into some of these aspects can really help a project manager steer the team towards building the right product which is way more valuable than someone who ensures the team is tracking to an outdated plan.

How much does IT matter to clients (or businesses) ?

As a consultant I have the privilege of working with a variety of clients. I try and help them build good quality software by applying Lean and Agile methods. I ask teams to embrace changing requirements and to deliver as frequently to a production like environment, solicit feedback from end users and feed them back into the next build. I always believed this to be a recipe to keep every client happy until a client came and told me that

“I don’t think I need so much automated testing. I am also not sure if I need all the flexibility of having a production ready system with me all the time to deploy at one click.”

“I also think this is an overhead and costing us some unnecessary extra time.”

My first reaction to this was

“Maybe he does not really understand the essence of having a Continuous Delivery cadence yet!”

But then I had a long after thought

“Does my client really need the level of automation my team is putting in?”

“Does the organization really need the level of flexibility and value add which my team is providing?”

“Am I providing the right level of service which my client organization needs?”

To get answers to these questions, I tried to understand more about how the client organization views IT. Do they view it as their core competency, a differentiator in the market or just another utility overhead?

IT - Utility, Enabler or Strategic

Martin Fowler talked earlier about Utility V/S Strategic Dichotomy. He quotes a prospect drawing an analogy of IT and Sewage pipes “software is like sewage pipes, I want it to work reliably and I don't want to know about the details”. This is thinking of IT as a pure utility. It is like electricity in your house. You will pay the bills and you just want it so that you can do your work under a working AC and a light bulb. You won’t care any more about it

My view of IT has 3 main categories

Utility – A lot of IT applications that merely provide a utility such as payroll or timesheets fall into this category. An organization will just want them to work within the business and will only care about cutting costs around these systems. (Just like you would look at cutting your electricity bills). There is no encouragement or even necessity to innovate. They deal with well-known problems where a package solution can fit in well.

Enabler – IT is an enabler for businesses that use software solutions to manage core internal business needs. For example a marriage registry will use custom software to maintain its records so that it is in good searchable format. The solution is also customized to the business needs (e.g. a marriage registry might have different legal requirements for allowed marriages in a jurisdiction). Organizations care a bit more when IT is an enabler than when it is a mere utility.

Strategic – This is where IT is viewed as the organisation's core competency. It is so blended into the business that it can provide a strategic advantage over competitors. The products in the market are IT products and services such as an online bookstore or an online ticket retail site. The organization needs to care about their online user experience and also be quick in bringing new features to market. They will also need to test and adapt their features based on market validation.

Why businesses differ in the way they measure success of IT?

When IT is viewed as a utility or enabler business will view success to be the project delivering on time and under budget. Businesses will largely look at cutting costs on such projects. How adaptive the delivery process is and how quickly we can take a feature to market is of no concern to the business. They don’t have any competitors. (e.g. No one is going to compete on writing a marriage registry software than the state registry themselves who need it).

In cases where an existing legacy system is being replaced by a new one, delivery on schedule may also become a major success measure. This is mainly due to the frustration and overhead of working with the legacy system, that the business might get desperate to replace it quickly.

In a strategic IT centric business however, success will be measured differently. Time to market, adaptation and ability to quickly reposition the products become critical to business. This is when the product is more important than the project. And this is where strategic methods of Agile, Continuous Delivery and techniques from the Lean Startup add value.

But for utility and enabler projects, it does not matter much. Quoting Martin Fowler from his post

“Most agilists tend to come from a strategic mindset, and the flexibility and rapid time-to-market that characterizes agile is crucial for strategic projects. For utility projects, however, the advantages of agile don't matter that much. I'm not sure whether using an agile approach for a utility project would be the wrong choice, but I am sure that it doesn't matter that much.”

Choosing the right IT governance model

Mary Poppendieck identifies 3 main IT archetypes in her Leadership workshop. Borrowing from her, here is a suggested IT governance model that can match the client based on their view of IT.

Utility (for Utility) - Provide cost effective utility like reliability (as described earlier)

Governance model: Minimize cost/ Minimize maintenance overhead

Supplier (for Enabler) – Deliver business internal applications on time and on budget

Governance model: Manage variance to plan on the project

Partner (for Strategic) - Create differentiating competitive solutions

Governance model: Software can create differentiated product and services. Measure success by measuring business results.

Conclusion

As an IT consultant it is important to understand the client or the business’s view of IT. There are times when investment in Continuous Delivery is not best suited for a client. As Jez Humble talks about it in his post “In fact, the most important criterion for using continuous delivery isn’t concerned with the technical nature of system you deliver or even the market you work in – it’s whether the system is strategically important to your organisation.”

Try not to be yet another project management overhead

Context

Most of our teams in Thoughtworks India work for clients outside India, which results in an “All Thoughtworks team” which is quite high in the Agile maturity scale.

When I used to interview Project Managers in Thoughtworks India, I often struggled to find people who would sound reasonable to call in for an interview after a preliminary conversation.

Something I often end up asking is “Can you tell me about a difficult or puzzling issue you had to handle on the last project  or so ? “ and the answer to this would typically be

“I had to manage dependencies across multiple vendors which was really painful”

“I had people with performance issues on my team, and we could never deliver”

“Vendors did not deliver on time”

“Scope kept changing”

“Ran out of budget”

“No one was convinced about Agile in my organization”

While these were legitimate problems, no one would actually come up and say

“There were too many defects every iteration and I had a tough time figuring out the root cause”

“Our velocity was low and we did not know how to handle a particular new technology”

“We did not know how to write automated tests around a few legacy systems”

“Our build times were quite high and we had no good solution “

“We had to coach a really difficult product owner”

This made me conclude that even though it has been so many years since Agile, XP, Scrum have been around, project managers still try and manage the golden triangle of Scope, Time and Budget. And when you are a bit more senior in the organization, you are given the responsibility of managing vendors, and be christened as a program manager. There were a few people who had at least good people management skills which was a sign of hope.

What should you know as a Project Manager to be useful ?

The reality is that in a highly collaborative and self organized environment like an agile team, a project manager is considered an overhead. And a project manager who does not take interest in the product the team is building , the way the team is collaborating and some of the technical challenges on the ground, is downright useless for a team.

Solving some of the project issues in an Agile team needs a deeper understanding of the engineering practices that are used to build the product as well as an understanding of the domain and the business in which the product fits in.

If you need to be an effective project manager, you should at least have a good handle of a few things in your project such as

* What is a good User Story in your project  or are we slicing stories correctly ?

* How good is the Continuous Integration on your project and how can it be improved ?

* What is your functional automation strategy and how can you achieve the maximum benefit from it ?

* How much technical debt are you carrying on the project and what is the impact ?

* What are the difficult areas in the codebase to test, and how can you increase coverage in those areas ?

* What does the production deployment infrastructure look like and how you best utilize that information within the project to create more similar environments ?

* If you are in a stand-up meeting where a QA calls out a defect, you should be in a position to question why no test actually caught that defect before hand in the continuous integration ?

For the typical project manager who worry only about the golden triangle of Scope, Time and Cost at a high level this might seem weird. Some of them might even want to delegate it other people in the team.

In a matured agile team, the case for a project manager can be made only when he/she has a handle on some of the things mentioned above. Estimating using points, putting it in a release plan based on velocity can be done by anyone in the team.

The crux lies in understanding the product the team is building , the tools and techniques they employ to do it and the collaboration required to yield the best results !