SAFe 4.5

SAFe 4.5 is out! Checkout the new look at: http://www.scaledagileframework.com

Quick visible differences -

• Program Portfolio Mgmt is now Lean Portfolio Mgmt
• Lean budget makes an interesting read!
• Configurable SAFe (FULL, LARGE SOLUTION, PORTFOLIO and ESSENTIAL)
• Could not find VSE, found STE instead, stands for Solution Train Engineer
• Solution Train.. earlier we use to just call it as ART at Value stream
• Continuous delivery Pipeline at Program level with Continuous Exploration, Integration and Deployment
• Special place for SPC... makes "base" for the framework along with implementation roadmap
• Palette is vertical... yes this makes sense
• System Team is on palette but DevOps at Program level

Do you see any other differences?

Now that SAFe is configurable, enterprises will have less "guilt" in answering the question if they are following SAFe "fully" or "partially" as they have more options now (Full, Large solution, Portfolio and Essential)

Fixed Price Agile projects

Now a days, I hear that more and more Agile projects are being offered at fixed price, which client is considering a sort of "Stop-loss" option for them. 
Reason could be anywhere from - technology partners are not able to deliver value on time .... to "stringent" budget constraints.

Here are my thoughts on Fixed Price Agile projects – 

• As a technology partner might not directly go for fixed price, instead observe the rate at which you are delivering value and velocity for 2-3 PIs and consider the “normalized” velocity at which you are delivering value for the fixed pricing. So it is T&M to start with and later switching to FP.

• Another option is fixed price per PI. Technology partner would provide the team(s) say 3-5 teams, with optimal pyramid and that team (fixed team) will continue working in PI over PI to deliver the value. From customer point of view, the price will be fixed (for a team), however customer can reap the benefit over time as the team become more mature and starts increasing their velocity and deliver value. Here time is fixed (per PI), Price is fixed (onsite/offshore blended rate) however scope is what customer defines. This option would work great for customers who is looking for long term tie-ups with a technology partner. (it won’t work in short terms for obvious reasons)

• Have a combination of both fixed and variable price. Clearly define what all services will be offered as FP. E.g. Quality, governance etc. and things that would be offered as T&M.

• Assume a minimum velocity based on your historical data – have a cap on fixed price and then if the technology partner achieve more PI over PI, the technology partner gets incentives or if performance is lower than the minimum it is penalty for the technology partner. For this to happen both the side needs to be mature enough to understand the factors that affects the high/low performance. 

• Have a higher level price limit as well as lower limit – E.g tell the clients the clients that you (as a technology partner) cannot come down lower than this price per team pyramid and at times the cost might serge up to specific high limit because of certain situations/reasons (say more resources, adding few architect/ SME/ specialist to the team to resolve certain issues etc)

• You can also offer fixed price and fixed scope bid, but then it just takes away the gist of being Agile. Agility can be restored by allowing them to come-up with the change request that are based on T&M. So, upto certain level say 10-20% scope variation is allowed (this needs to be really worked out carefully) and beyond that say any scope change over 20% it should be T&M. Many things to consider here.. e.g. how to manage change request, can I spin—off a new work order by bundling n number of change requests. How am I delivering, How my delivery is being measured and I do I report my progress. Ownership of risks/impediments etc.

• Fixed price based on the features category – Critical Value features / Arch features / High Value feature / Moderate features / trivial changes / GUI changes.
For this to work well, technology partner must have very good understanding of the systems they are about to work and there should be clear roadmap (2-3 PIs ahead) of what a portfolio/ART is trying to achieve over time. However as all of us knows that requirements changes quite often, so we should have outline of the requirement and assume the variability(may be limit it to +-15% to 20%) and inherent risks. I would says this would be little uncomfortable contract to have.

Your thoughts and comments are welcome!