Showing posts with label finance. Show all posts
Showing posts with label finance. Show all posts

Sunday, 23 October 2016

The Culture Change of DevOps (Video Blog)

This week's Auspicious Agile Video Blog takes a look at the culture change of DevOps. DevOps requires more than just adopting tools, it also requires changes in culture and the way we work. Here we look at several culture aspects in DevOps to consider.



Here are some of the links and resources mentioned in the video blog:
- Xebia Labs periodic table of DevOps - https://xebialabs.com/periodic-table-of-devops-tools/
- Phoenix Project by Gene Kim - http://www.realgenekim.me/
- Dan Pink Drive - https://www.youtube.com/watch?v=u6XAPnuFjJc
- Auspicious Agile first blog on culture change of DevOps - https://auspiciousagile.com/2016/02/20/the-culture-change-of-devops-and-your-career/
- Mirco Herring, DevOps Leadership Culture - https://notafactoryanymore.com/tag/devops-culture/

Saturday, 27 August 2016

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/

Saturday, 23 April 2016

SAFe Agile Portfolio - CapEx and OpEx

This week's Auspicious Agile video blog looks at the Scaled Agile Framework (SAFe4) Portfolio Level - CapEx & OpEx.  A practitioner's perspective on the recent SAFe and Dean Leffingwell article on the topic.  CapEx & OpEx are accounting and financial terms, but they are very relevant for the enterprise Agile practitioner.  Find out how in this week's video blog.



Thursday, 23 October 2014

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).
Water Bottlecoffee_cup_003sky-on-rocks
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.

Saturday, 18 October 2014

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.

Saturday, 6 September 2014

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.

Saturday, 12 July 2014

Is making money the most important thing for an Agile team?

In the last few weeks in meetings in Malaysia and Singapore the topic of whether making money should be top priority for an Agile Team has come up.  For purposes of this discussion we will assume that the Agile team is a part of a larger business or organisation, and is not a stand-alone group.  So the larger question would be is making money the most important thing for the business or organisation that the Agile team is a part of.

From an Agile perspective we always focus on delivering value for the business or organisation (http://agilemanifesto.org/principles.html).  So let's define value.  In most cases if the business is a for-profit company or organisation value takes the form of producing better bottom line results.  This could be reducing costs, increasing revenue, increasing customer satisfaction, or improving employee morale in the company.  These may also apply to a non-profit organisation that seeks to break even, but not necessarily make a profit.  There are of course other areas where a team could deliver value, such as increasing market share, or improving company image.

So in order for an Agile team to deliver value to the business and organisation one of these areas should be improved by the team's work.  Now the question is which of these or other ways of delivering value to the organisation is most important.  Let's start with reducing costs, and proceed through the others.  If the team develops a productivity improvement that reduces costs for the company, then the organisation should be more profitable, and this will show as better bottom line results (i.e. company keeps more of the revenue it generates).  So reducing costs is directly related to making money.

Next we have increasing revenue.  This also is directly making more money for the company.  So work by the Agile team that increases revenue is also focused on the organisation making more money.  Increasing customer satisfaction means that likely more customers will use the organisations product or service.  Satisfied customers are happy spending their money on the company's products and services.  So customer satisfaction, while initially measured potentially by a survey or some other measure, in the end also results in the company making more money.

Now let's look at improving employee morale.  It can be said that if employee morale improves that happy employees will create better products and take pride and ownership in the work that they produce.  Now better products, and happy employees likely will lead to the company making more money, but it can be argued that improved employee morale does not always lead to the company making more money.  Happy employees also tend to be more likely to stay with the company, and attract others to the company.  This saves money for the company in its recruiting and related costs of finding and retaining talented people.  However, let's say for now that employee morale is not always measurable in bottom line results.

Increased market share, likely will result directly in the company making more money from more people buying its products or services.  An Agile team contributes to increased market share by creating great features and services that are valuable in the market place.  So again increased market share (in a well run company) should lead to the company making more money.  Lastly I mentioned improving company image.  This could take the form of better brand position in the market, or better brand recognition.  When more people know your company (hopefully for the right reasons) the company is again likely to make more money, through more people choosing to do business with the organisation.

Now, this is certainly not an exhaustive list of value producing activities in a company or organisation, but does touch on some of the most important for a for-profit company.  In addition there are non-profits, but most of these still apply, as a non-profit generally needs to break even to continue operating (this may take the form of attracting more money donations, which again would be value producing for the non-profit - take Wikipedia as an example).

So of our entire list just about every value producing activity for the Agile team ends up with the company or organisation making money.  Arguably we could say employee morale is not directly measurable in dollars and cents, but ties to money outcomes in many ways as well.  So if an Agile team is seeking to produce value for the organisation that it belongs to, it seems very likely that the value produced will have a financial or money measure.  This would point to making money for the organisation being the most important activity for an Agile team.

I would add to this one final point.  Even if an Agile team does not choose to focus on producing money for its organisation, the organisation will only be able to continue to operate as long as there are finances (money) to support the business as a going concern.  So if an Agile team does not support the monetary success of its organisation, the team may not be able to continue as a team if the organisation it belongs to is not profitable or at least able to break-even (in the case of a non-profit).

Until next time, keep thinking about Agility,
John.