Why Your Organization Needs an Agilitst as Your Coach

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.

Lean/Agile - The Art of Doing Less

Our traditional ways of managing software development projects center around generating ideas that are deemed valuable and then attempting to estimate at a detailed level the effort involved by having a team of people work to document ‘all’ of the requirements up front before the project even begins. These projects often will take many months to complete before anything of value can be delivered to the business.

Agile focuses on delivering value as quickly as possible, often within 2 weeks to 2 months. Lean focuses on maximizing work not done, which combined with Agile speaks to doing less as a part of our delivery process.

But what do we mean by less when looking at taking on a large feature/product development effort? 

There are couple of ways that this comes into play:

1.   Software is often littered with features that someone thought would be important to the customer, yet fails to deliver the value (need) to the customer. Worse still this code becomes part of our legacy application, stuff we have to code around and test against regardless if the feature is being used or not.

2.     Often the perceived value of something changes once the project begins, causing the business to pull the plug on work before it is complete and anything of value can be derived by your software development team. This is costly both in terms if financing and employee happiness.

In both cases the business has expended money to have software developed with the end result being the business received reduced or no value.

When looking at Agile Product/Project Management we are asking the business to act not just as the agent of funding but as the consumer of the work as well. Too often the business is a distant or non-existent participant with respect to how their product is unfolding. Instead they rely on project plan updates that speak solely to progress against the agreed upon scope of the project at its inception over viewing what has actually been developed and delivered to date.

In an Agile setting business needs to review the work at regular touch points, often the Sprint review and actually see what is being developed. There is often a great difference between what the business ‘thinks’ they want and what they actually need. Seeing working software lets them see their idea in action, often with enlightening results. What they envisioned may not in fact be what they are seeing and more importantly not what they need (the value). They funded a Ferrari but maybe only needed a good old family sedan.

Business is typically missing in this very powerful process in Agile, a process which allows them to make course corrections and even stop working on features as soon as they reach their maximum value. 

At one large entertainment organization I worked for several years ago, the business had us working on a large rewrite of a heavily used widget that resided on hundreds of thousands of pages. After performing a Discovery and Story mapping session we determined that the work should be done in three releases. At the end of the first release the business reviewed what we had completed and decided that this was actually good enough and then pivoted us to working on an even more valuable redesign of a key customer facing web app.

In the waterfall days the work that we did for that first release would have been put on the shelf, the money invested would have delivered no value to the business. With Agile we were able to complete the work and deploy to production, providing the business real value for their investment. They made the decision to stop this work and move on to more valuable work.

The Art of Doing less is about developing more mature approaches to how your organization funds and manages work. Instead of funding projects fund your teams, allowing for work to flow to them over having them focus on managing project scope to the bitter end of the project.

Move away from believing you have to have fixed scope to one that understands that Agile is about powerful flexibility and maximizing the value of the work that we do, while minimizing the amount of legacy code we leave behind. 

A legacy system that is littered with large amounts of un-needed or under-utilized capabilities is code that is harder to scale, develop in and test against. When your teams talk to you about Tech Debt, this is what they are referring to and as a business you are both a direct owner and contributor to this reality.

The Art of Doing less brings with it a greater ability to maximize an organizations investment in its software and product development.

The focus for business should be on what is needed not what is wanted. Project funding models encourage asking for more than is needed so one of the first things you need to do is to move to a team based funding model. Develop a framework to assess value and risk so you can appropriately prioritize work as it flows through your teams.

Understand that each of your Scrum teams has a fixed cost (~40k per sprint), this should guide you further in questioning what you want your teams to work on.  At some point in time in most projects there comes a point where there is a diminishing value relative to the investment.  

Lean and the Art of Doing less requires changing your organizational mindset to understand there is also value in work NOT done.

Launching SoundAgile Consulting

I've been involved with Agile with many different organizations now for over 12 years. In these years I've primarily been involved with being a contributing individual over a being an Agile coach.

The business of Agile has grown to a significant size and has now become a product that is sold to businesses who want to move their organization to Agile.  The very people who started Agile off as a movement have splintered off into several factions, each having their own opinion or approach in how to help organizations adopt Agile as a capability within their organization.  We now have Scrum, SAFe, DAD and LeSS to name a few in our acronym vocabulary.

Agile can indeed bring about valuable changes to an organizations ability to deliver software product more quickly.  These areas of Agile are fairly thought out, User Stories, Continuous Integration, Automation and Scrum.  You can move your development teams to a faster pace with some focus on specific team and development techniques that require some time to learn with some level of ease.

What Agile is struggling with is at the organizational level.  The Agile manifesto is specifically focused on building software better with a goal of delivering high value and quality software to our organizations.  A noble cause for sure and one that was sorely needed, given the changes in our software capabilities over the past 20 years.

Sr. Leadership however hasn't changed much, still managing in a large up front analysis budgeting process which creates a painful friction between fast moving product delivery teams and slow moving hierarchical management structures .

For those organizations who are being sold Agile as a product that will deliver 'x' benefits know this about what is occurring.  These organizations are finding people who have done 'some' to 'no' real Agile, meaning they haven't actually worked on an Agile team. Getting people who have the 'right' certifications doesn't provide those people with the ability to coach teams in the reality of Agile, only the theory of Agile and their current frameworks.

They are also focused only on the product development area of your business, letting you believe that you will receive huge benefits from moving to Agile without the corresponding changes necessary throughout your entire organization to support a fast paced product delivery teams.

Agile is not a small change management effort, rather it is a multi-year impact to your organization, that if done well will lead you to great success.  If done poorly will provide you with significant pain without any corresponding benefits.

I've spent many years thinking about what I might offer from an Agile consulting perspective and I've come to the conclusion that any Agile 'consulting' work that I would want to engage in must include both Sr. Leadership down and the team level.

Another thing I have concluded is that successful organizations that want to become Agile, must do so with a much smaller footprint of coaching.  You don't need full-time coaches for a long period of time.  In relying on full time coaches you are asking them to be your organizational Agile cop over owning the change within your organization.  The most successful Agile organizations I've worked in never had an Agile coach. Let me repeat that, never had an Agile a coach.  Instead they owned the move to Agile from the top down.  They provided the opportunity for teams to be empowered and fail and were not afraid to change organizational processes when they became impediments to improving Agilty.

SoundAgile will provide two levels of support and coaching for your organization.

1. Team Level - Coaching and training will be accomplished through a combination of online training videos, 1:1 coaching and targeted onsite sessions for specific techniques such as Discovery/User Story Mapping, User Story Writing and Behavior Driven Development.
2. Management Level - This will cover every management level in your organization, especially focusing in on your most impacted people, your technology managers.  Coaching and training will again be accomplished utilizing videos, 1:1 coaching and probably most importantly, targeted 1-2 day sessions that will continue for a multi-year time period. These sessions will provide for a longer term inspect and adapt change management process.

I'm really excited to be launching SoundAgile and am looking forward to working with people and organizations as they engage and encounter this thing called Agile.

SoundAgile will be live within the next two weeks.  I look forward to working with people who are motivated to move to Agile and make it work for them and their organizations.