digital transformation

Business Agility Requires Transforming Your PMO and Annual Planning Cycles

As a leader as you think about everything that needs to happen for your organization to be and remain competitive in a world that now has the ability to change direction in a moment’s notice, you likely aren’t thinking that Agile is what you need.

You are however thinking about things that equate to Agility.
One of the primary places you need and want to have Agility is in your Technology investment. Yet, that is one area that rarely changes when we think about being agile or developing agility.

To build a foundation for business agility you MUST change several things:
1. Annual Planning cycles must be replaced by continuous planning that does not focus on large project funding for long periods of time.
2. Funding must move from projects to supporting stable long-standing teams. Work must flow to your teams.
3. Plan by Value not by Cost by developing a Portfolio Valuation Model that forms the basis for your Intake model.
4. Develop an Investment mindset.
5. Develop an Innovation mindset that focuses on identifying ideas that can be developed in smaller value components allowing for better management of costs and risks associated with your technology investments.

You can’t develop a high level of business agility by maintaining the status quo on your funding and annual planning cycles.

Agility requires that we work in smaller increments of work that is strategically aligned to value and flows to teams in a consistent manner.

Expecting to develop Agility with large projects funded by annual planning cycles is an approach that many organizations still take, leading to frustration across the entire organization as your planning and delivery capabilities are mis-aligned.

If you want to learn more about how SoundAgile can help you transform the way that you flow work to your teams then connect with us at www.soundagile.com

Changing Your Funding Model is a Requirement for Success in Agile

When you are considering moving your organization to Agile the single most important decision and change you will make has nothing to do with the frameworks that you will select for your teams to operate under.

The change that provides the foundational support for these frameworks is about how you fund the work that these teams will do. 

Agile frameworks are not designed to support fixed budget, date, and scoped projects, yet that is exactly what happens when most organizations ‘Go Agile’. Teams start working differently but Management and Finance stay aligned to annual funding cycles and weekly project plan read-outs.

To lay a foundation for success in Agile, you need to change your funding model, moving away from funding projects in annual planning cycles to one that funds dedicated teams where work will flow to teams continuously. 

Much of the resistance in making this change comes from the fear that Finance will never change and this is just the way that they have to manage the books. The reality is far from that, organizations can and do make the shift from funding projects to funding teams, and when they do the entire dynamic of how work is managed and delivered changes dramatically.

For Finance this shift simplifies financial management because instead of having to manage the P/L for hundreds to thousands of projects, you will have a single entry for each team, which on average costs (blended rates) around $1 million annually. So if your organization has 40 Product teams you can expect the cost of delivering software to be $40 million.

By changing the funding model from projects to teams you can then shift your focus to Value, building a value-based Portfolio approach that identifies a risk/return profile for your organization and products which will allow for the appropriate investments to be made.

The shift to funding teams requires a change in decision-making that ensures that we are balancing what is identified as the most valuable against the cost because not everything we do can or want to should be done.   Moving to funded teams does not remove the fiduciary responsibility everyone has to make sound investment decisions.  

This change to delivering features in a continuous fashion allows for capitalizing on a more frequent basis which has its own benefits from a financial reporting perspective.


Why Do We Need to Scale Agile?

That is a question I have been grappling with over the past few weeks because even though I’m an Enterprise Agile Coach, who is typically brought in to support scaling Agile, usually via SAFe, I struggle with the whole concept.

Scaling Agile on its surface sounds anti-Agile as it implies a level of structure and conformity that will kill creativity, which is what Agile is really about.

However, ever since Agile had success in small settings, there has been a rush to sell Agile to large organizations as the cure to solve all of their issues.

Scaling frameworks sprung up to support this desire to move to Agile and with it came everything that will kill real Agility.

Here’s the thing, those initial successes you had were with small teams, working on things that could be isolated from the rest of the organization, and were provided a space to try new ways of working, without the pressure to conform operationally to a fixed date and scope project.

That was my experience, working in a completely Waterfall world I became the Scrum Master for a team that was going to build an entirely new product. We were very successful and in about six months we had a market-ready product. Though everyone was impressed that was the end of the organization’s experiment with Agile but was the beginning of my journey towards it.

It was many more years before I worked at an organization that needed to change everything about how they worked and it was the first time I had a view of what the needs of a larger organization might be related to working in Agile.

Though we were provided space to work differently and to make mistakes, we also as a group kept ourselves informed as to what other teams were doing and if something was working we’d look into whether that made sense to adopt.

We become more structured in how we worked through months of trial and error, while engaging our leadership to gauge what they needed so that we moved towards a common goal and outcome.

Though we worked in projects (note the Agile Manifesto has the word project in it so it’s not something that goes away) we helped our business and PMO partners understand that by moving to Agile we were providing them much greater transparency as to how we were progressing and more importantly it gave the business a greater understanding of the complexity of the work we did on their behalf.

Over the next 18 months, we went from a poorly performing development group to one that had gained the trust of the business and was given ever-larger initiatives to work on, ones that transformed an entire organization.

The key thing you need to understand with Agile at scale is that the primary thing you are trying to do is to unleash the creativity of your people. You hire tons of very smart people and then turn around and tell them exactly how they have to work, we don’t like that.

The problem with this? Your organization isn’t typically set up to support this and the scaling frameworks don’t even address people and creativity as important elements of Aglie.

By unleashing creativity you are allowing your people to figure out best how to work as a team, across the organization, and deliver increasing amounts of productivity, quality, and value.

I believe what has been the focus of scaling Agile is to provide Sr. Leadership an allusion that Agile is a thing we implement, like Salesforce, and then turn on. If everyone follows the same processes, attends the same ceremonies, and acts in the same manner, then the entire organization must be Agile, right?

If you are on an Agile journey already or are thinking about starting one, don’t start with a scaling framework first. If you need one later, consider it.

Instead, start by changing your organization structure so that it supports letting people who do the work figure out best how to do the work. What is required from Leadership is to establish guidance focused on:

o How the organization makes decisions — What is our mindset for them? We’ll align our decision-making around those expectations, ensuring we are all on the same page.

o How the organization decides what is valuable — This one is the hardest, look to your strategies first. By providing understanding to both what is value and how we can derive it, your teams will make good decisions on what work will bring the best value in the moment.

o How we will empower you — Allow failure to be part of the journey. No framework will expunge the need for failure, what frameworks do is focus on activity over outcomes more often than not. Celebrate failure for the learning it provides.

As you consider Agility in the organization know that there are foundational aspects of your operations that must change, from HR, Finance, Sales, Marketing, and Technology, everyone must be engaged in the journey, it’s not just a technology thing. This is what scaling is about, allowing people to make the necessary changes to enable Agility, not laying a rule-based structure over another rule-based structure, and hoping things will get better.

Why Your Organization Needs an Agilitst as Your Coach

Agilist Image.png

I’ve been working through some things in my recent engagements, one where I worked with some awesome coaches and another where coaches were not deeply experienced with Agile.

The differences in the success of implementation were fairly stark, with one having highly engaged coaches working collaboratively to refine the challenges with the organization’s framework, making thoughtful changes that moved the organization forward while keeping the intent and outcomes in place.

The other was disjointed and fragmented with the focus on the framework being right and attempting to fit the framework into the organization over the other way around. The coaches in this situation were rigid in their belief that the framework is implemented as defined by the framework, which is a circularly blind logic that completely leaves out the organization in the approach.

This got me thinking about Agile and how I view it based upon almost 20 years of working in Agile, primarily as someone involved in developing and delivering software products and more recently in the past 7 years as an Enterprise coach.

From my perspective, I see 3 aspects of what many think of when they hear the word Agile.

1. Agile Manifesto — This is the base for the Agile movement across the world. It laid the foundation for how we want to approach working via its 4 Values and 12 Principles. Within these, we find the foundations for how we want to work which has resulted in the development of a myriad of frameworks designed to take the Manifesto and ‘operationalize’ it for people to work within.

2. Agile Frameworks — These come in all flavors and often have ardent followers who often believe that the Framework rules everything we do. Where the Manifesto was not prescriptive the frameworks often are or are implemented from that perspective. This rigidity of implementation stems I think primarily from the certification factories that have been turning out certified Scrum Master, Product Owners, Release Train Engineers, so on and so on….

The danger with the certification process is that implies to unsuspecting hiring companies that these people have some deep understanding of ‘x’ framework and this couldn’t be further from the truth.

Worse many coaches in our industry have gone out and paid for a bunch of certifications yet have zero experience working in Agile and can not provide any supportive coaching regarding implementation of the framework due to this glaring knowledge gap.

Unfortunately, the demand for Agile coaches to support Agile Transformations is high and continues that way, in order to hire coaches organizations will check the box for certifications and move forward, with often disastrous results.

A critical danger that organizations who want to move to Agile face are that if you get it wrong by hiring people with no Agile experience you are not likely to be successful resulting in leadership blaming Agile but in reality, it is the people hired to help you be Agile who are at fault. You often have one shot at gaining confidence in Agile.

3. Agilist — These are the more rare individual in the Agile world, those who have both worked in Agile in often many different roles and then have gone on to coaching. My background includes having been a Scrum Master (before certifications were a thing), Product Owner, Tester, Agile Evangelist within the organization to leading a Transformation organization.

It is these real-world experiences that you want your coach to have as they take the approach of understanding your organization and then applying the appropriate approach for that moment in time.

Agilsts are not tied to a specific framework and we look at them as things we can leverage as part of the overarching goal of helping the entire organization become Agile, not just adopt Scrum, which is focused solely at the development team level.

I often describe my approach as that of being a chef with lots of spices (frameworks) and picking the parts of each that make the most sense for where the organization is at. Trying to implement SAFe into a free-spirited startup will likely fail, but if you hire SAFe certified coaches they will come in and implement SAFe. Their hammer is SAFe and every organization looks like a nail to them.

Agilsts question everything and seek new ways of working that provide the right context and direction for the organization to be successful.

If you are thinking about starting an Agile Transformation these are things you need to consider. Seek Agile coaches who can provide real-world examples of how they both challenged the organization in their thinking and helped them see new ways of working that lead to successful outcomes.

Coaches who are Agilists will often have the certifications as they open doors for us, but they are not the driver of how we think of how an organization can become truly Agile. Simply selecting a Framework and adopting that gets you only so far in the goal of changing the organization to a new normal.