Auspicious Agile - Agile Finance

This week's Auspicious Agile video blog takes a broad look at the area of Agile Finance. We will be covering Agile Finance Mindset, Beyond Budgeting approach to Agile Financial Leadership & Management, along with the Eco-System associated with Agile Finance. Join us for a look at this key area of Business and Organization Agility. hashtag#budgeting hashtag#AgileFinance hashtag#BeyondBudgeting hashtag#BusinessAgility hashtag#Agile

SAFe Agile Contracts

This week's Auspicious Agile video blog takes a look at the Scaled Agile Framework (SAFe) approach to Agile contracts.  This blog is a continuation of the series on Agile contracts.

The first blog post in this series can be found here - https://auspiciousagile.com/2014/11/08/agile-contracts/

The related Scaled Agile Framework Blog post can be found here - http://www.scaledagileframework.com/agile-contracts-and-safe/

Nuances for Agile Budgeting

Hi All,

This week I would like to revisit Agile budgeting.  In the last Auspicious Agile video blog post we discussed some approaches that can be used to budget for Agile projects.  This week we will look at some nuances that are helpful to consider when budgeting for Agile projects. 

Velocity:

First let's start with how we calculate velocity.  In the last blog post I talked about a method that can be used to derive a best case, worst case and most likely case for budgeting an Agile project or initiative.  The foundation is calculating velocity (velocity = distance / time).  We represent distance as the amount of work to be done (points), and time as the length of the iterations (sprints).  Now we can calculate our budget based on an average velocity, which is a velocity that is derived over time by looking at several sprints done by a team(s) over time.  For example if we have 5 sprints of history to look at and the velocities were 25, 50, 30, 40, and 10 points the average velocity would be 31.

However, it isn't necessary to use average velocity to make budget projections.  You could assume a velocity (maybe because you don't have the iteration history to calculate average velocity, or maybe because the historic data is not representative.  For example in the example above one of the sprints only had 10 points.  That may be because there was a holiday, or team members sick or for some other reason.  So in some cases it may be desireable to make budget projections based on an assumed velocity, maybe in our previous case assuming 40 would make more sense than using the actual average velocity of 31.  Of course if your team has no historical information to base velocity projections on, your team would also want to make an assumption about what the velocity might be (an approach used by the Scaled Agile Framework) and refine that number later.  Maybe you start by assuming 5 points per day for a two week sprint, or 50 points per sprint as the team velocity (make sure to factor in the number of team members when you make your assumption).  

T-Shirt Sizing:

Another consideration is for using the T-Shirt sizing "Price per story" method of budgeting for Agile initiatives.  Some teams may not be familiar with how to T-Shirt size or use relative estimating.  The key is not to focus on getting too detailed on estimates, rather the focus should be to group things in groups that are relatively of the same size.  For example, if you have a coffee cup and you have a bottled water and I ask you to tell me exactly how tall each one is, you will have a very hard time doing this without an accurate measuring device (i.e. ruler).  Again if there is a pile of rocks and I ask you to tell me the exact weight of each rock, it will be a difficult task (without an exact measure like a scale, and the time and ability to move and weigh every rock).

Now if instead I ask you to tell me whether the previously mentioned coffee cup of water bottle is taller, that will likely be relatively easy for you to do.  In the same way if I ask you to group the pile of rocks as either small medium or large that should be relatively easy to do.  So "relative" estimating by comparing things is much easier to do than estimating by coming up with exact measures.  This is a key difference between traditional project / initiative budgeting and Agile budgeting.  In Agile we use a relative measure that is far less time consuming, but still good enough for a budget projection.  So using T-Shirt sizing takes advantage of the relative estimating approach in Agile and helps to identify a reasonable budget estimate for the work (while still maintaining flexibility / agility).  For the rest of how we apply T-Shirt sizing to Agile budgeting please see the video blog in my previous post "Budgeting for Agile Projects and Initiatives".

Thanks for reading, and until next time, Stay Agile!

John.

Budgeting for Agile Projects and Initiatives

How do we budget for Agile Projects?  This Auspicious Agile (www.auspiciousagile.com) video blog entry talks about some techniques that can be used to plan and budget for Agile projects.


Please note that in the first video example the "most likely case" is only for concept demonstration purposes.  If we used the average velocity of the team (as 50 points per sprint) to calculate the most likely case it would actually take 5 sprints (for a backlog of 250 points) to complete.

Pointers on Enterprise Agile Transformation

Hi All,

This week I want to discuss some pointers to being successful with Enterprise Agile from my experience:

Program and Portfolio Planning

First when it comes to Agile Program and Portfolio planning it can be very valuable to align program milestones with team level iterations and releases.  This can be particularly valuable when a company or organisation is working with a vendor that uses Agile iterations and needs to align this to their internal program and project milestones.  By aligning with Agile iterations and releases communication between the management team and the development team(s) or vendors can be made much clearer.

For example if a vendor will release a mobile user interface in its next iteration, the program and portfolio management teams can align their milestones for delivering mobile access to the upcoming vendor iteration or release.  This also allows an organisation to still have their Agile development teams and vendors responsible to certain delivery goals and milestones.  This approach also maximises visibility by allowing management teams to track how iterations required for their upcoming milestones are progressing, and increases predictability as a result.

Budgetary Tracking and Estimates

That said, the second pointer I would like to discuss is how to budget and estimate for an enterprise Agile program.  Traditional budgeting provides a set amount of money for the delivery of set features in a set timeframe.  However, with an Agile program and Agile teams there needs to be flexibility in the creation of product backlogs of user stories, and backlogs of features.  If the Agile teams are required to fix all of their features at the start of the project for budgetary purposes, the organisation loses one of the key benefits of Agile which is the ability to respond to the market quickly and flexibly.

In order to respond to the market and retain flexibility a good approach is to budget based on a certain set of features of a certain size (when I mention size I am referring to the Agile practice of T-Shirt sizing to facilitate relative estimating), but not to fix the exact features in advance.  For example a company may budget for 5 large features over the next 6 months.  From experience (understanding team velocities and hours spent working on large features) they may know it takes roughly $100k to deliver one large feature.  So to deliver 5 large features in the next 6 months they may budget $500k.  Or if planning out for the year they may budget $1m for 10 large features over the next 12 months.  By planning this way if the company needs to swap a key large security feature for a large mobile feature 3 months into the project their budgeting still remains accurate, while their teams and Product Owners have the flexibility to respond to the market.

Organisational Change

The third pointer is in how to lead an Enterprise Agile program.  I have often heard the advice that when an organisation moves to Enterprise Agile, that they should just make all of their Project Managers into ScrumMasters and magically they will have Agile teams.  The problem with this is that traditional project management and leading Agile Programs requires an entirely different approach to leadership. While Agile programs require a servant leadership approach (serve through leadership, and lead through serving the teams) traditional project management is generally more command and control.

When a command and control project manager is made into a ScrumMaster, or Agile Program Manager the results are generally not healthy.  Instead of empowering teams the ScrumMaster or Agile Program Manager assigns all of the teams’ work and demands that it be finished on an assigned schedule.  This takes away any empowerment the team may have enjoyed as a result of becoming an Agile team in an Agile Enterprise (as well as taking away flexibility and agility).  A key pointer here is to assess each traditional project manager, and leader in the organisation.  Some may adapt well to a servant leadership approach.   Others, may not and may need to find different roles, or may simply be more comfortable in a non-Agile organisation.  Identifying this early on and shifting people to roles where they will be successful is a key organisational change factor to enable successful Enterprise Agile.

I hope some of these pointers and points have been useful.  These are only a few that come to the top of my mind in thinking about avoiding pitfalls in transitioning to an Enterprise Agile organisation.  Hopefully food for thought, and useful advice for avoiding common Enterprise Agile adoption pitfalls.

Until next time, Stay Agile!

John.

Is it Really that Hard to Scale Agile?