agile leadership

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.

Currency for Change – Transformation Needs and Roadblocks

change-1-1563676-640x480

Business leaders, those who run our organizations, continually look for strategies that deliver growth, synergy, profit and increased market share, to name a few.  They are judged and compensated based upon their ability to deliver results around financial or operational focal points.  Those leaders who manage a publicly traded company take on the added burden of providing predictable quarterly results year after year in order ensure a stable and growing stock price.

Many times new strategies require changes to your organization.  When attempting transformative organizational change, our focus is on changing the way that an organization operates at an organic level.  However our Leadership is rarely focused at this level, rather their focus is on the expected benefits of the desired change. They often fail to address the real organic element necessary for change, which are the very people who help manage and run their organization.  People will determine the final success or failure of any particular change management effort.

Change, the type that transforms an organization is often done so out of perceived need or stress event, such as new competitor or competitive products or disruptive technology.  Though the stress/threat may be very real to the survival of the organization.  Though the threat may be real the people working for the organization may not necessarily be motivated by changing how they work in order to respond to the perceived threat.  The reasons for this can be:

  • We may not be connected to the threat in a real way, we don’t see how the threat impacts our job.
  • We may not agree that the threat is real.
  • We may not agree with or believe that the requested changes are the right approach or strategy.
  • We simply may not care.

We are ultimately are creatures of habit, what worked in the past should work for us in the future, we come to expect outcomes based upon these past experiences.

Our natural world provides us with examples of how change is handled when stress is applied.  In nature change is a natural state and happens without negotiation, let me repeat that:

 Change happens without negotiation.

Trees don’t talk to hills to see if they are ok that more trees are grown, the change happens naturally based upon the need of the environment not the want of the trees.  Organic change happens in reaction to a stress event and then the system responds by initiating change that provides the appropriate reaction in order to bring the system back into a steady state.  In this example there is no currency for change between actors in the system as the system operates in a manner which brings the system back into a static or healthy state without applying change management techniques to encourage adoption of the change.

Large human systems are unlike our natural counterpart on multiple levels, primarily due to the people who are the actors of the system.  Natural systems form a comprehensive whole were all of the sub systems work in synergy on a grand scale.  Human systems however don’t share this synergistic behavior and as such operate independently of each other and the stress of one organization may not have any association or perceived dependency with another organization.

When human organizations inject change into their system in response to a perceived threat they trigger a broad set of activities at impact people in that system.  Change in both our natural world and our organizational world has the primary goal of keeping the system healthy and strong, but whereas the natural system accepts change without negotiation the human system involves potentially significant negotiation which has the negative effect of diluting the positive impacts the desired changes are expected to deliver.

Why is this?  Much of it surrounds not taking the time to communicate WHY the change is necessary and understanding the currency of our organization to accept the change.

What is Currency for ChangeIt is the perceived value that an individual will derive by participating in change.

Human systems require people to participate in change.  However in order to get them to fully engage in the change process we need to communicate WIIFME or What’s In It For ME?

Change requires that the people in your organization do some of the following:

  1. Learn new things (software, processes, tools, etc..)
  2. Take on new roles (Project Manager to Scrum Master)
  3. Report to new people
  4. Change the way that they manage
  5. Change the way that the project manage
  6. Change the way that you plan
  7. Change the way they are compensated

Currency then is what an organization is willing to ‘pay’ people in their currency in order get them to actively engage in change.  Currency is individual and ultimately relates to how an individual perceives their place, influence and power within the organization, this will drive what their specific currency will be.

Currency for change relates closely with the motivational needs of employees.  For example, though we may understand why we need to exercise and eat better for a longer life we may not be motivated sufficiently to do this consistently long term unless we identify the real currency we require to make the necessary changes.

There are many different needs based theories that can help define individual currency for change:

  1. Maslows’ hierarchy of needs:
    1. Physiological
    2. Safety
    3. Social
    4. Esteem
    5. Self-Actualization
  2. ERG Theory:
    1. Existence
    2. Relatedness
    3. Growth
  3. Acquired Needs Theory
    1. Need for Achievement
    2. Need for Affiliation
    3. Need for Power
  4. Three-Factor Theory for Employee Motivation
    1. Equity/Fairness
    2. Achievement
    3. Camaraderie

Parsing these different theories we come up with a few general themes:

  1. People need to feel safe
  2. People need to feel achievement
  3. People need to be acknowledged
  4. People need to feel connected to others
  5. People need to learn or challenged

When we begin to craft a change management plan for our organization we need to engage in conversation that explores the currency of the people who will be engaged in the change.

When beginning the process of change we must clearly identify the Why as part of understanding and leveraging an individuals’ currency for change.  If you can’t clearly identify the why people need to change you won’t be able to develop the What and the How in order to sufficiently engage people at their motivational level which we translate into currency.

Understanding what people require in order to be incented to change, translates into currency because change doesn’t come without investment and that relates to WIIFE, what am I going to receive if I change?  And unfortunately simply staying employed may not be enough, especially with highly skilled and sought after knowledge workers, you must engage them in a much different manner and their currency won’t be continued employment or more money (typically).

What does currency look like?

  1. Enagagement
    1. Allow more control and input with respect to the change to your entire organization, don’t make it a one way street with no negotiation. Unlike our natural world where change happens without negotiation, people in your organization are the source of successful change management.
    2. Benefit – It’s doubtful that your change management team has thought of everything that is required to make the change successful. Engaging your organization to participate in building the strategic direction of the change will create strong ownership of the change.
    3. Needs Met
      1. Need for Affiliation
      2. Social
      3. Esteem
      4. Camaraderie
  1. Failure
    1. We must understand that when we change our organization, the model by which we manage our organization also changes. Leaders and managers who have been successful in the organization are now faced with potentially dramatic changes with respect how they will manage and how they are perceived as successful.  Their very power base is threatened.  Encouraging a culture of failure as part of your change management efforts is essential for successful change.  Failure is not the goal, rather the mechanism that we use to encourage learning, because at its heart change is about learning and we all learn differently and we have different currency with respect to how we learn.
      1. Needs Met:
        1. Need to learn or be challenged.
        2. Safety
      2. Recognition
        1. There are people in your organization who have vast experience and domain knowledge which has been vital to the success of the organization. Though these people may be the most resistant to change, they can conversely be your biggest proponents for change if approached the correct way.  These individuals often want more recognition than material things such as more money.  They fall more along the needs matrix identified by Maslow, they are looking more for Social and Physiological needs to be met but also need to feel safe during the change.
          1. Needs Met:
            1. Safety
            2. Acknowledgement

As you think of taking on transformational change you need to start the conversation around the needs and currencies of the people who are going to make your change management successful.

Change is hard and when not engaged properly is destined to under deliver or worse fail completely.

Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out