An Agile Start to the New Year

Hello and Happy New Year!  In looking forward to the New Year, setting goals, and making resolutions here are some thoughts to keep you Agile, flexible, and successful:

1.  Flexibility in your goals

As you set your goals for the New Year, start by building in some flexibility in your goal setting. Let’s consider a case where you may be considering expanding your business into a new market.  While it makes sense to set some milestones this year to achieve market entry, it also makes sense to leave room to be flexible in your market entry approach.

For example:  It may make sense to set up a new business entity in the market, but it may also make more sense to work with local partners already in the market.  Leaving yourself some flexibility in achieving your milestones and goals for this year increases your likelihood of achieving your goals and resolutions.

2.  Adapting and adjusting your personal backlog

Just like the way we set up a Scrum Product Backlog or in a SAFe scaling context a Program Backlog in planning to meet your New Year’s goals and resolutions create a personal backlog. This builds on the first point as it helps you to visualise your goals and prioritise them.  Having a personal backlog in place also allows you to prioritise your goals and make trade-offs if you aren’t able to achieve everything according to your initial plan (and of course plans do change).

For example maybe you want to gain a new professional certification, start exercising again, and travel more to a new region.  Two month’s into the new year you may realise that you won’t be able to maintain your exercise routine and increase your travel to the new region.  In that case you may need to update your backlog to incorporate a new type of exercise that you haven’t done in the past.  Or you may need to look at the priorities in your personal backlog and decide whether travel to the new region is as important to you as being able to continue your exercise program.  Having a personal backlog enables you to be flexible.

3.  Limit your WIP

Limiting Work in Process (WIP) is a Lean principle that we see in Agile in the form of the sprint backlog (which limits the work in process every 2 – 4 week time box / sprint).  Limiting your personal WIP this New Year will help you to focus on what is really important. Do you have new family commitments, broader responsibilities in the work place, and want to continue your education. These are all great resolutions and goals, but trying to do everything at the same time makes it unlikely you will do anything very well.

So you may choose to focus on those new family commitments during the first month or first quarter (we can think of this as a sprint goal or in SAFe a Program Increment Objective).  During the second month or second quarter you may increase your focus on executing on those new workplace responsibilities (of course you will have probably done some initial planning during the first month or quarter).  Finally you may tackle that goal of continuing your education by enrolling in a Masters Programme in the second half of the year.

By limiting WIP you are able to focus on a limited set of things (stories) in your backlog.  By doing this you can benefit from reduced task switching and achieve some early wins in key personal areas that will help to encourage you to continue in other areas.  Limiting WIP is a key approach to help you to achieve your goals and resolutions in the New Year!

In Summary

Applying a few Agile principles to your planning for the New Year can help you to be more successful in achieving your goals.  Namely, by maintaining flexibility in your goals, creating and adapting your personal backlog, and limiting WIP you will be well on your way to a successful and Happy New Year.

Have a Happy and Prosperous New Year, and Stay Agile!

1357600133

Tagged with: , , , , , ,
Posted in Agile, agile enterprise, agile methodology, Business Agility, personal Agility, SAFe, Scrum

Patterns in Scaling to Business Agility

Tagged with: , , , , , , ,
Posted in Agile, Agile Adoption, agile enterprise, agile methodology, Agile Scaling, Business Agility, Flow, lean, SAFe, Scrum

Agile Contracts

Tagged with: , , , , , , , , ,
Posted in Agile, Agile Adoption, Agile Project Manager, Business Agility, contracts, Fixed Price, Legal, SAFe, T-Shirt Sizing

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.

Tagged with: , , , ,
Posted in Agile, Agile Adoption, agile methodology, Agile Project Manager, Budget, contracts, Scrum, Uncategorized, Velocity

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.

Tagged with: , , , , ,
Posted in Agile, Agile Adoption, agile methodology, Agile Project Manager, Budget, Fixed Price, Incremental, SAFe, Scrum, T-Shirt Sizing

Agile Beyond the IT Department

auspicious blockchain and agile

If You enjoy Auspicious Agile you can support us on Patreon –https://www.patreon.com/AuspiciousAgile

Also support the Auspicious Agile blog by shopping on Amazon using the links below!

https://www.amazon.com/?tag=auspiagile-20

LifeProof waterproof iPhone 7 phone case (Affiliate)

 The Phoenix Project (Affiliate)

 The DevOps Handbook (Affiliate)

Tagged with: , , , , ,
Posted in Agile, Agile Adoption, agile enterprise, agile methodology, Business Agility, lean, Scrum

The Agile Project Manager?

——-
A useful resource on Agile Project Management by Jim Highsmith

(Affiliate)

Tagged with: , , , , , , , , ,
Posted in Agile, Agile Adoption, agile enterprise, agile methodology, Agile Project Manager, Agile Scaling, Budget, contracts, Legal, Scrum, Servant Leadership

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.

 

Tagged with: , , , , , ,
Posted in Agile, Agile Adoption, agile enterprise, agile methodology, Agile Project Manager, Agile Scaling, Budget, Release Plan, Roadmap Plan, Servant Leadership, T-Shirt Sizing

Is it Really that Hard to Scale Agile?

Tagged with: , , , , , , ,
Posted in Agile, Agile Adoption, agile methodology, Agile Scaling, Business Agility, Distributed Teams, Scrum

The Company That Went Agile With a Big Bang!

Tagged with: , , , , ,
Posted in Agile, agile enterprise, agile methodology, Agile Project Manager, Business Agility, Uncategorized
Categories