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.

Implications of Self-Empowered Teams

We talk of teams being empowered, but in reality, most teams never reach any level of real empowerment because their focus is on activities over outcomes.

Activities that support the frameworks we implement in the name of Agile become the focus of our day-to-day life. The activity of building and having a backlog of ‘work’ is a metric we typically convey back to leadership on the ‘health’ of a team. So their focus is on creating a deep backlog instead of having a backlog that is filled with strategically aligned outcomes that deliver value.

If a team is truly empowered then they would know how their decisions of what to work align to outcomes that the organization seeks.

Unfortunately, in most organizations, the transparency and alignment of strategy to value is not well known or may not exist at all.

Empowerment is not just Leadership saying, you are empowered, it’s instead about laying a foundation of transparency about what they believe is the most important outcomes that teams can deliver and then providing them the runway to do that through experimentation and empiricism.

A truly empowered organization won’t look anything like the frameworks say it should, because empowerment implies a higher level of independence than the frameworks provide.

With great independence comes great responsibility for everyone involved in ‘Being Agile’.

Empowerment must build trust through the ability to show how you delivered value and that value then being positively leveraged by the organization to sustain and support growth.

Agile Planning in 3 SImple Questions

Should We Do It

Can We Do It

Will We Do It

Answer these three questions before you start on any large initiative

Asking Should we do it starts a conversation around whether this is strategically aligned with our goals and objectives.

Asking Can we do it then moves the conversation to whether or not it’s technically feasible, what types of architectural enablers might we have to invest to deliver on this idea?

Once we have answered the Can we do it then we need to move onto the important aspect that will drive the final decision do it — Cost.

Just because we CAN do something doesn’t mean we SHOULD. At one organization the business came to us with an awesome idea (no really it was) but when we told them that could take more than 20 sprints to accomplish (almost a year) the business said that it would be valuable to them if it was 4–6 sprints but not more than 20. This caused them to go back to the drawing board to refine their objective goals.

Once we evaluate the strategic alignment, technical feasibility, and the potential cost of initiatives, only then are we ready to pull the trigger to invest in this idea.

Asking the Will we do it, provides everyone an ability to confirm that this is the right decision and then make that investment decision transparent to the organization.

It may sound non-Agile in approach (it’s not Discovery is an important component) but before we invest our teams in large Initiatives we should take some time to assess whether that is a good idea to do it in the first place. Just because something can be done doesn’t mean it should.

Developing an Investment Mindset for Product Development

In general, when deciding what projects to work on during their annual planning cycles, most organizations use a cost-based approach to make those decisions.

Leaders in the organization know the project buzzwords that will move them above the line, the demarcation zone of approval they strive for. CapEx/Opex is often a key component in decision making, however, this focus on financial goals keeps us from aligning our ideas to long-term strategic goals and growth.

One of the reasons we fail to maximize our returns with software development is that we aren’t treating it as an investment, instead, it’s a cost center to be managed.

The difference between an investment and cost is both a mindset as well as an expectation. When we invest in something we do so with the express expectation that it will grow in value over time. Think of the investment you make in your 401k’s, you expect over time that the amount you put in will grow over time. Product investment needs to follow a similar approach. 

Every new feature or enhancement is an investment in the future returns we expect to receive from their development. But not every investment type is the same and we need a way to define what our Product Investment strategy is so that we are confident in receiving appropriate value from each incremental investment.

Portfolio money managers can approach building long-term value by leveraging what’s called Markowitz’s Efficient Frontier Model. This complex mathematical model has an implicit assumption that says each investment (Stock/Bond) and investor have a risk and return profile associated with them.

My risk and return profile will lay the foundation for my investment strategy. If I’m nearing retirement I’m going to be more conservative and risk-averse concerning my investment decisions. Conversely, if I’m young I’m likely to invest a certain percentage of my capital into higher levels of risk so that I grow my portfolio more quickly.

Organizations are no different and by developing a risk/return profile for your organization you can begin to understand, quantify and communicate your Product Investment strategy to your organization.

As a Product Manager/Owner I need to understand the risk/return profile of the organization and incorporate that into my Product Investment strategy. For example, if I work for a highly regulated organization in a mature industry, my goals may different than a start-up seeking to grab market share or differentiate themselves in the market. 

Each organization has different approaches to risk and return, however, this concept does not readily exist in most organizations, the reason is that we look at software development as a cost to the organization, which explains our primary focus on the cost of a project. 

Yes, we pay lip service to what the value the project is supposed to deliver, but let’s be honest we don’t typically have metrics in place to track the value the project is supposed to deliver, and in the end, we are happy to deliver something and declare victory.

Where I have implemented this model before I’ve seen that it changes the conversation across the organization, from leadership down to the team level. Combining a Product Investment approach to our Product Development initiatives with the generation of a value score that is tied to strategy, we begin to discuss more deeply why something should move forward from a place of value and investment over budget and timeline.

If you are serious about developing an Agile Delivery model, you must create a value-based investment approach to your Product Development.

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.

TAP2 Change - Building an Agile Organization via the Pillars of Transparency, Accountability and Predictability

I’ve been involved with Agile for almost 15 years in all manner of roles and organizations. Some of the Agile efforts I’ve been involved with could be counted as a success, some not so much. 

The organizations that I’ve been involved with, which had successful transformations, had a few key behaviors they exhibited, which included:

1.     A willingness to be vulnerable regarding what wasn’t right about how the organization. These organizations weren't afraid to discuss what wasn't working and make decisions about what needed to be done at the Leadership level.

2.     Active engagement from the organization’s leadership and a willingness to experiment and fail along the way towards mature and effective agile processes.

3.     An ability to provide people and teams the space to become self-organizing and empowered to define how best to work within in the context of being Agile.

As I've moved through the Agile experience I've identified a way to approach an 'Agile Transformation' from a different perspective. Too often our focus is only on the frameworks that have grown up to support the implementation of Agile, such as Scrum, Kanban, SAFe, xP and a myriad of others. These frameworks focus on how teams operate and are concerned mostly about the flow of work to teams. This is only part of the equation.

Based upon my experiences I've created a framework that is holistically focused on changing the entire organization not just the software development capability.

I call the approach TAP2 Change

TAP2 Change focuses on developing three key pillars necessary for a successful Agile transformation:

1.     Transparency

2.     Accountability

3.     Predictability

Transparency –

This pillar is about defining many of the missing pieces of most Agile Transformations, most importantly identifying why the organization wants to move too Agile.

Agile shines a light on all of your organization’s inefficiencies and asks one simple question – What you are going to do about it? 

Something we don’t tell organizations trying to be Agile is that Agile doesn’t fix anything, it’s not a framework, or a process, so it can't 'deliver' anything for you. What it is, is a mindset which asks you to challenge your current belief structures held within your organization and then start the process of re-envisioning your organization.

Transparency starts at the top where we challenge Leadership to:

1.     Define a clear vision and strategy conveying to the organization why you want to do this and what you expect to have as an outcome as you transition to Agile. Tell people the important part of change - ‘What’s In It For Me’

2.     Reassess how they view their value streams or develop them if they don’t exist. This will challenge long-held beliefs about what is valuable to the organization and will result in a brand new way of thinking about your business.

3.     Redefine your products and capabilities within the context of your value streams. This again will challenge beliefs about where your organizational value resides. 

4.     Engage people from all levels of the organization as you build out your Agile Transformation strategy, ivory tower approaches need not apply. Agile is a ground game that needs input from everyone in the organization so it doesn’t appear that this is being something done to them but with them.

5.     Completely change the way you look at how you finance your software development projects, moving from Project to Team-based funding.

Your Transparency Pillar will be the most difficult and will take the most time because if you can’t be transparent about what outcomes you are seeking and the ways that your organization must change to get them, then you will not realize the full value of going Agile.

Instead, you’ll be like the myriad of organizations who reach the state of Doing Agile and never move past this state or worse regress when leadership declares they are Agile and stops supporting it.

Accountability –

Accountability is an important element in any Agile Transformation however much of our efforts in rolling out Agile to the organization avoid organizational and team accountability.

When we talk about Accountability we are talking about several elements:

1.     Organizational Accountability – Leadership is accountable for defining an Agile Transformation strategy and roadmap and ensuring that they both communicate and regularly update the organization on how they are doing. Leadership is also accountable for ensuring that they support the change and don’t simply fund the initiative and forget about their part in this significant culture change that they must lead.

2.     Team Accountability – As Product Development teams begin operating in whatever framework that they will be using, they are accountable to the organization to engage positively and seek to continually grow in the maturity and capability of that framework. Too often Leadership views Agile as a way for software development teams to not be accountable for their work and show progress in delivering on important features and functionality. This is not the case, but how we view accountability is not about hitting fixed dates and scope but rather being accountable with respect to our Transparency so that Leadership is informed with facts about how we are progressing and can then more clearly understand the issues with attempting to create features in a highly complex environment.

Leadership is accountable to teams to be engaged in assessing what value we they are delivering and making fact based decisions on what is needed not what was wanted.

Predictability –

Predictability is ultimately what Leaders are looking for, they have to make commitments to customers and shareholders with respect to value that they expect to deliver. Not all organizations have the luxury to continually develop and deliver new features and enhancements such as Amazon or Google can, the reasons are many but they are real.

This pillar however, just as with the Accountability Pillar, is not about a team marching towards a fixed date/fixed scope effort. Rather Predictability is about understanding the capacity of individual teams and the entire organization and identifying the minimal amount of work that will deliver the most value in the shortest time.

We view Predictability not within the context of scope but with cadence, be it story points, # of stories, or whatever metric you use to identify how much work can be completed within a specified amount of time.

To ignore our need to show progress, even if the progress shows that we are hitting challenges, provides important fast feedback to Leadership so that they can make informed decisions and manage expectations of customers earlier than waterfall would ever allow.

You can build out one or more of the Pillars, but it is the strength of all three that will provide you with a strong foundation for building a successful Agile Transformation.

To learn more about our process you can reach me at michael@soundagile.com or go to www.soundagile.com

Also - Coming Soon - Look for my book - TAP2 Change Building an Agile Organization via the Pillars of Transparency, Accountability, and Predictability.

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 Change?  It 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

   6. ERG Theory:

      1. Existence

      2. Relatedness

      3. Growth

      4. 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

         3. 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.

Agile - The Ugly Truth

If you are an organization that is considering moving to Agile, especially a larger one, there is an Ugly Truth that Agile consulting firms don't want you to know: You don't need coaches to come in full-time to help you on your journey......

Sure you can spend a ton of money on people who will come in and tell you how you should be doing standup, scrum, retrospectives, etc....Try to get everyone to do the same thing across your organization.  The Truth? In successful Agile organizations everyone can be different, that's ok.  Yes you want some consistency but doing things by rote doesn't get you where you want to go.

In the coaching world we talk about organizations Doing Agile who never get to Being Agile.  What's the difference??  Everything.

Yes the basics of Agile include things such as standup, retros, sprint planning and release planning, but those are the basics that can make you feel like you are Agile, but that's about it.

Agile IS transformative process and one that if you as an organization buy into, will receive great value from in the form of valued delivered in a more consistent manner.

I remember years ago when I was managing a technical project that required that I purchase some hardware and though I had found a better deal with a different vendor, my boss told me to buy the IBM hardware (at a much higher price) with the advice - 'You don't get fired for buying IBM'.

I think that many large organizations fall into this mindset and when trying to move to Agile  They fall into the mistaken belief that if you hire one of the large Agile coaching groups or hire Agile consultants, that you will ensure success or at the very least not get fired because you hired 'Agile professionals'.

Yes you do need people who can provide support in the important areas that Agile truly needs to have in order to bring the value you desire from it:

1. Automation - Develop, implement and improve your test automation frameworks.  This includes unit, integration and functional areas.  You MUST make this investment and you need to get to high levels of automation, because without it you cannot go fast, time for testing will hold you back.
2. Planning and Estimation - An area that is very much overlooked when moving your product development teams to Agile is the need for these teams to form a strong working relationship and learn how to plan in estimate in Agile.  The notion, especially for larger organizations, that you don't need to do some level of up front planning is a sure way to fail and fast.
3. Organizational change - Probably more than anything you need to understand that your organization will change, significantly in many ways, when you move to Agile.  You need to prepare your managers to let go and let their teams own their deliverables (trust me if you give this to people they will own it).  You as an organization need to understand that your management group will change, you will need fewer managers (sorry folks that is a reality).  Though in reality many of your current managers were placed in these roles as more as a retention means over a true management track that the organization has defined.  These people need to move into your Tech Lead roles, they run their scrum teams, own the technical and architectural elements of their product code.  Managers will oversee several Scrum Teams and will be focused on larger concepts such as technical roadmaps, cross organizational planning and staff development.

So the Ugly Truth is that you don't need to spend hundreds of thousands of dollars on coaches who will tell your teams what to do.  Instead hire people who have been on the ground, who can help your teams learn the skills they need such as TDD, BDD, User Story Mapping and Estimating.

Start small and grow the process into the organization.  You need to get your processes working on a small-scale and then move outwards into the organization.  The people who are successful in your pilot groups become your sales people for the next groups.  Trust me, I listen to the people who actually do the work more than I ever do people who try to provide me basic information that I can find anywhere online.

The Myth of Rockstars - Teams Deliver Not Individuals

Over the years I've had the opportunity to work with numerous software development teams in both large and small organizations many of whom have a singular focus of hiring technical rock stars. Though it sounds like something we should all aspire to, I think that we often lose sight of how great a team is when everyone works together over the individual rock star mentality

Point in case the 2014 Chicago Bulls.  They yet again lost their rock star (Derrick Rose) due to injury and the team could have just thrown in the towel, but they didn't.  They weren't considered 'rock stars' by how people in the NBA view talent , but they had something that rock stars don't always have, commitment to the team.  A selfless focus on what they had to do to win a game in the NBA and for several months they had the best record in the NBA from January through March.

Another Bulls analogy would be the championship Bulls of the 1990's.  Until Coach Jackson was able to get Michael Jordan to work as a team member and not be the rock star that he obviously was, the Bulls didn't win a championship.  Only when Michael began to work within the team structure were the Bulls able to win six championships.

The point here is that rock stars often can't/don't deliver for a team, rather they achieve greatness within the context of themselves.  Many technical rock stars are singularly focused on achieving technical dominance based upon this mythical rock star status we give to them.  This leads all to often to these individuals climbing into leadership roles for which they have no real skills to succeed with.

Teams that deliver understand that we all must sacrifice something of ourselves for the betterment of the team.  Rock stars don't see it that way and those that never see it that way are destined to be winners to themselves and not to a greater good.

Sports unfortunately is often the best analogy to teams and in Agile our Scrum concepts come from a team formation from Rugby, so perhaps the sports analogies are appropriate in most cases when talking about technical teams that deliver.

Agile is all about delivery, and fast.  But with speed comes the need for discipline, multiple disciplines in a Scrum team.  Everyone, and I mean everyone, has to pitch in.  If you are a Java developer and you have legacy C++ code, guess what??  You need to learn from C++ so that when time is tight and the delivery important you can step in and help out.  That's teamwork, no rock star needed, just a willingness to put yourself out for your team.  If you are a developer and there needs to be testing in order to close out the Sprint, guess what?? You need to test.  It's amazing what you will learn when you test your own code from another perspective.

When I'm hiring I look for people who have had broad level of experiences.  People who have done just one thing but are considered a Rock Star for it, aren't really my interest.  Great products and high quality come from those with well rounded backgrounds, who see the edges as places that we need to explore.

Great teams have that, broad level's of experience.

So when you are thinking about building a team remember that an organization, any part of it, is a sum of the total parts, not just the rock stars.