Why Working Software is a Key Agile Principle

Why is working software one of the primary principles of Agile?

Because when we deliver something that was asked for we may or may not have gotten it right.

I know from my experiences the vision that someone has in their mind about how something should work doesn’t always align with what the development team has delivered.

Working software provides value to the development process by providing feedback – you asked for this now I delivered it.  Now you provide feedback – I asked for this but it isn’t working exactly the way I wanted to.

Agile accepts changing requirements as part of continual interaction between the customer(end-user) and the development team.  This is what we mean by accepting change as part of Agile.

Instead, this mindset is often I think taken as, I provided a large business requirements document that you must work from and commit to upfront, but at any time late in the project, I can change my mind about what I want and no matter the impact it causes you told me Agile accepts change. 

If that is your idea of accepting changing requirements late in the game, then you are playing the wrong game.

If your organization isn’t changing their engagement model to support these continual interactions between your users (or their proxy PO and business leadership) and development team and instead saves any interaction until near the end of the project, then all you have successfully done is shorten the cycles by which you are working in Waterfall, delivering your large project in 2-week increments and waiting until the end to review what the team has delivered and at that point telling us we didn’t get it right.

There is a reason that most of the Agile frameworks provide varying levels of engagement, from the team up to leadership.  The Agile Manifesto Principles expressly identify the value that can be delivered by having a high level of engagement – ‘Business people and developers must work together daily throughout the project.’

So if you are already working in Agile or considering adopting Agile as your delivery model then you must change the way you engage with the process if you want to have real success in your Agile adoption.

I still see too many organizations that have very little engagement with reviewing the work that their teams are delivering which means that we end up having a disconnect between the requesting and delivery process, which will cause lower productivity and quality while delivering lower levels of value.

The Neuroscience of Agile

Over the past year, my interest in neuroscience has grown and one of the interesting things that have come out of my learning is that the brain, as it turns out, spends quite a bit of energy thinking (subconsciously) about what might happen in the next moments in time. 

Historically it had been thought that the brain reacted to stimuli and then formulated a response (think fight or flight).  But the brain is much more active in its planning whether or not we will need that type of response. Our brain is constantly evaluating what we are doing at the moment and trying to predict what our response will need to be in the upcoming moments.

That implies that our brains are tuned to short-range planning, so it should not be surprising that humans are not all that good at predicting what will happen further in the future. 

That’s not to say our brain doesn’t look at what has transpired historically and provides us an ability to guess what the future of something might be, but ultimately we simply aren’t wired for success in long-term predictive planning.

So given our brain is good at predicting what will happen in the very near term, I find it interesting that software development processes evolved over the years to encourage long-term planning, asking people to say today what they will do 6 months from now, especially given all of the unknown variables that exist in complex software development work.

At best we are guessing about what we will need to do 6 months into a 12-month project.  The brain simply isn’t set up for the successful long-range planning that Waterfall requires because we can’t anticipate what might happen as it is too far out into the future.

I suppose all of the Waterfall gates and approvals are designed to provide us some level of comfort or false confidence against the unknowns we accept as a risk to our projects.

Software development is a complex thing, you are asking people to develop in or on top of a complex environment where everything can’t be known upfront and the human brain no matter how much you try to plan for the future, really must be focused mostly on the more current aspects of their project, eg - what am I doing today and tomorrow and at most next week.  Sound familiar?  Short incremental development cycles followed with an inspect and adapt check-in?

So if our brains have developed to be very good at short-term planning why would we not want to adopt Agile as a way to deliver our software development efforts?

Agile aligns to a natural strength, short-term planning with fast feedback loops, which provide us an ability to react and respond to what we are seeing and learning. 

Those fast feedback loops inform everyone as to what just happened and what is about to happen so that if needed, we can react and change our course.  Our brains are set up for this type of behavior. Asking us to plan tasks months in advance is asking for failure on multiple levels, be it productivity, quality, context, or value.

As you either consider adopting Agile or making your current effort more successful, spend a good amount of time redesigning your planning process top to bottom, to support a short-term planning cycle.  You will find everyone more supportive (and happy) of working this way and you will see more value being delivered.

To learn how you can be better at Agile contact me at Michael@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.

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.

Managing the Risk for your Agile Transformation

Agile coaches often lament that the Transformations they are brought on to support are treated as a Project. I had one coach outright tell me recently, that because I suggested that we needed some dates to focus on that I was keeping the organization mired in Waterfall.

The reality is that an Agile Transformation is a change management project with many moving parts all of which need to work together. If you miss one area it will negatively impact another.

A typical set of Agile Transformation workstreams might include some of the following:

· Establishing your Guiding Coalition

· Establishing your Enablement team

· Forming your Communication team

· Developing your Product Capability Maps

· Identify new roles and responsibilities

· Develop a Training plan

· Identify tools needed to support Agile Delivery

· Changes to your funding model (moving from Project to Team-based funding)

· Creating Product Teams

Each one of these workstreams is significant in terms of breadth of work and importance to the success of your transformation plans.

For example,

· If you don’t define Product Capabilities then your ability to create Product teams that support those capabilities is at risk.

· If you don’t have clearly defined Product teams then you are at risk of not being able to move to a Product team-based funding approach.

· If you don’t have Product teams defined, then your roles and responsibilities defined for dedicated teams will be at risk.

· You get the picture. Dependencies and risk abound in a transformation.

The frameworks that we leverage for moving to Agile have a whole host of assumptions, the most basic of which is that all of the work above has been completed and you can adopt the framework in an ‘as-is’ state.

The reality for a majority of organizations is that they don’t put in place much of any of the foundations that will provide the real support for whatever framework you decide to use.

If you are approaching a Transformation from the perspective that it’s the framework that will make you Agile you are already at a failure point in your project.

If you are considering starting a transformation understand that you need to build a project around all of the areas of the organization that must change, hint that isn’t just Technology.

You must create a set of milestones that provide the tipping points to change and then organize around the inflection points where your new normal will take hold.

Managing Resistance to Change

Stress in life is inevitable and to quote Agent K from Men in Black - "There's always an Arquillian Battle Cruiser, or a Corillian Death Ray, or an intergalactic plague that is about to wipe out all life on this miserable little planet, and the only way these people can get on with their happy lives is that they do not know about it!"

And this is how most people in organizations view change, so long as I don’t know about the real threats my organization is facing, then I'm comfortable with the way things are. 

As you consider an organizational transformation of any kind there are a few core aspects you need to understand:

1. Belief Preservance – Your organization has a set of beliefs and mindsets that have over time evolved, and when you want to change the organization you need to address how the organization ‘thinks’ today. These beliefs have typically resulted in a successful company and people having successful careers, attempting to change that belief is not easy and is the first place you will receive resistance to your transformation. 

2. Transparency – You need to be transparent about why the organization needs to change. Transformations often create an information vacuum that will be quickly filled by the people who perceive they have the most to lose with any change in the status quo. Take great care in explaining the challenges the organization is facing and what the outcomes will be with this change and more importantly the outcomes if the change isn’t successful.

3. Engagement – Along with high levels of transparency you also need to engage the organization from top to bottom so that everyone feels as if they have ownership of the change that is coming. Leadership needs to meet with everyone, do more listening less talking. Be sure people are heard and their engagement is meaningful.

4.  Communication – Communicate, communicate and communicate more. Many transformations are started with no formal communication, the first people hear of change is when the people who are trying to transform start acting and talking differently. Those not aware of the transformation will be left confused and frustrated, which leads us back to the formation of resistance to change. You need to create a comprehensive communication plan along with an effective feedback loop.

Change is difficult, but with knowledge, support and focus we can remove a large part of the stress associated with it.  As leaders, you set the tone for the success of your transformation, be mindful with your plans.

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 Aligning Value and Strategy is Important

Value is often in the eye of the beholder and because we attach ourselves to the perception of that value we can’t often differentiate between what we want and what we need.

As leaders, we often follow a similar approach when deciding what projects we should take on for the w\organization.  For instance, we may read about something interesting that another company is doing and think that we should be doing the same thing, this becomes your want.

Unfortunately what that other company is doing may not be what your organization either needs right now or worse is not even strategically aligned to its strategies.

All too often organizations have an annual planning cycle where individual leaders pitch their ideas for new projects and request funding.  And all too often these projects are disjointed, competing with other projects seeking opposite outcomes, or are even duplicate efforts leveraging different technologies, all because their focus is more on wants over needs for their capability.

So how do we move from thinking in wants to acting on needs?  It starts with transparency and alignment to the organizations' strategies.

How many people in your organization know and understand the strategies that are key to delivering value to your customers?  How many more define their initiatives around those strategies?  Unfortunately, the answer is very few. 

To start you need to create a Portfolio Valuation scoring model that is tied to your strategies and then provides a scoring mechanism that is aligned to Objectives and Key Results.  The key results form the basis of the value factors that will generate a score for each initiative.

By aligning the scoring engine to strategies and having the value factors aligned to metric outcomes, we can apply the scoring model across the organization holistically.  This is key to moving from a wants to needs conversation in the organization.

Having implemented this model in several organizations what happens at the leader level is that they have a harder time justifying investments that they want if they have low scores associated with them.  How do you convince leadership that it’s a good idea to invest a million dollars in a project with a value score of .5?  The answer is it’s not easy.

At one organization that had been trying to make the case to invest in a new ERP system with no success, we were able to tell the story better when leadership saw that they were investing large sums of money into low-value returns.   So the scoring model isn’t just to stop you from working on the wrong things, it also informs future investments to support fact-based decisions.

Value needs to be the driving focus of any organization as you have a limited amount of investment capital for software development.  Adding useless features that don’t align to strategy and have low-value returns is a waste of money

Additionally building things you don’t need adds bloat to your tech stacks as this code still has to be maintained and supported long-term.  The cost of any feature is never just related to its development cost. 

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.

Agile Your Way

My experience with Agile stretches back almost 20 years when a healthcare organization I worked for asked me to take on a new product development effort that was languishing. When meeting with the developers they asked me if I’d support them doing the project in Scrum. Not being familiar with it I did some reading and came back and said I’d do it.

And this was how many of us started in Agile, people taking the leap and then figuring it out. Funny thing, during this time there were no coaches.

Instead, we were forced to work with each other to figure out what our ‘Agile’ was going to look like. And here’s the thing, there is no ONE way to do Agile. You did what worked and if it worked then you were Agile enough and kept changing when needed.

Coaching came later and with it the industry that we have now. Lost in all of the talk involving frameworks has been the concept that each organization is different and what Agile will become for them needs to adjust or adapt to the organization and not vice versa.

Instead, Agile Transformations rely almost entirely on the implementation of specific frameworks and then telling the organization they have to adapt to what the framework expects. The frameworks assume that your organization perfectly fits into their framework and no company I’ve worked for yet has that been the case. 

You have to apply the framework based upon the intended outcomes the framework seeks and not implement it ‘out of the box’ in my experience.

Don’t get me wrong I’ve been involved with many organizations where we have implemented something out of the box and it’s not that we can’t deliver value, but the inherent imbalance of where the organization is at and what the framework expects keeps us from reaching higher levels of matutity.

Another reality not talked about much, is that is possible to be successful in managing a transformation on your own. Two of the most successful Agile organizations I’ve worked in (not as a coach) were led by the people in the organization, we just started and got to work asking a simple question – Is what we are doing Agile? If not what needs to change? 

Was it easy? No, but what change is? Could we have used some help? Sure, but we couldn’t afford a multi-million dollar transformation led by coaches.

It was these experiences in mind that I helped create the Agile Learning Journey, a complete package of E-learning content, developed based upon my years of experience in working in Agile. 

Agile Learning Journey provides coaching for your leadership down to the teams that will be working in Agile but does so in a way that points you lays a foundation of knowledge that would have been helpful all those years ago when I started working in Agile.

In addition to the reach experience you will find in our learning modules, we also provide you with boot camp training material, templates, and a myriad of other support elements to help you launch your Transformation successfully.

We can help you move to an Agile operating model at a fraction of the cost of bringing on full-time coaches, who often have little of that real-world experience I’ve developed over the years.

This is an important distinction because coaches who haven’t been involved in working in Agile will in the end tell you how the framework is supposed to work, but have little real experience making it work. 

This is where my experience brings life to our product. I’ve worked through the challenges of how to align change to action for people and organizations.

If you are interested in learning more please visit us at agileprocoaching.com or connect with me directly at michael@agileprocoaching.com. 

Organizational Zones of Antagonism

Recently my family and I were watching a worldwide bio-diversity seminar online and during one of the segments on Lichen’s (yes it was fascinating) the presenter talked about how Lichens grow and they formed what she called Zones of Antagonism as they looked for more food which allowed them to grow bigger.

The Zone of Antagonism formed a barrier around their space and would ward off any encroachment from another competing Lichen organism for their food source.

This concept immediately got me thinking about how organizations often operate with zones of antagonism as well.  We see and deal with them all of the time though we often refer to it as the politics of an organization.

People, due to the siloed design of their organizations' processes, often form what might look like zones of antagonism around their functional area.  These manifest themselves in many ways but are often revealed when an organization goes through any type of change management, such as an Agile Transformation.

Change forms a threat to the status quo, to the power bases built up with the current structure of the organization.  Power influences outcomes and outcomes drive behaviors.  Tell me how someone is incented and we can tell you how you are likely to behave.

We reward success, but which also means that there is a loser.  Much like the Lichen looking to compete for food, people often look to influence or consolidate power as much as they can when working within an organization.  We have been taught that to move up in an organization implies high levels of authority, influence, and compensation, so these are the drivers for what we see when we pull on the levers of change.

What we as change agents might refer to as resistance might also be called zones of antagonism instead.  It’s not that people are resisting as much as they are protecting against either something they know to be a real threat to their current state or something they fear due to a high level of unknowns.

As an Agile coach, we need to put ourselves in the place of the individuals we are coaching and ask if the organization has made clear the vision of why Agile is the way to go and what the organization and the people within it will get out of supporting the move to it?

If leadership for an organization has not made clear the game plan for engaging in change, Agile or otherwise, then people, much like Lichen will respond by establishing their zones of antagonism as a way to delay, thwart or even kill the transformation overall. 

We know resistance to change is real, however before condemning the resistance seek to understand it first.  It’s this step that starts the real work to remove the zones of antagonism in an organization that will cause the value you seek.

Too often as coaches, we are transactionally hired to come in and teach Scrum, SAFe, or any of the other myriad of frameworks used to ‘implement’ Agile. 

The problem is that the frameworks won’t make you Agile, only the mindset of change combined with the vehicle (frameworks) can move you from simply going through the motions and ‘Doing Agile’ to the place we want to be of ‘Being Agile’, where operate in 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.

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.

Moving from Project to Team based Funding in Agile

When we move to Agile we typically form our teams and then happily keep our waterfall project based funding structure in place.

We do this for a few reasons:

1. We think it’s the only way to show the cost of the work that we are asking to be delivered.
2. Projects are easily understood from an operational standpoint as they have a defined start and end date which is tightly aligned with the cost of the project.
3. It’s the way we’ve always done it.

As part of our project based funding model we have an annual project funding request process, where we  spend weeks/months identifying the things that we think are important (note I’m not using the word valuable here) so that we can obtain funding.  Things move above or below the approval line and when the dust settles we have a book of work that is committed to, with freshly minted project plans and a cadre of project managers to manage the money we just gave to these projects.

An annual project funding request process also means that we ask for what we need and then everything else we may or may not need.  We ask for a Ferrari when perhaps all we need is a good dependable family sedan.

There is power in money, who has it and who controls it typically drives what gets funded and what doesn’t.  It’s not uncommon for Sr. Leadership to commit to work even though their team doesn’t have any experience in the product solely to get the money to keep their teams funded and employed.

If you see a lot of potential waste here then you are correct.  We see waste just in the amount of people and money needed to manage our project money.  If a money market fund had as much overhead associated with it, I and everyone else would leave because that overhead just cuts into profitability. 

Next let’s more waste related to developing the stuff we didn’t need and may not actually use.  All of this extra stuff we develop has an expense associated with it and this is a long term expense.  We have it built into our architecture negatively impacting our systems scalability, performance and security.  We have to test it every time we build new stuff.  Bet you didn’t take that into account when you did your Cost/Benefit analysis for the project.

When we move to Agile we have an ability to really simplify our IT funding function.  It’s really quite simple – it’s the cost of your team. 

In most organizations this cost typically hovers around ~$40k per sprint or over ~2 million annually.  So as a financial manager trying to manage things like cash flow, depreciation and the like, this makes financial reporting much simpler.  Each team becomes a fixed line item cost on my balance sheet and operating statements.  I don’t have to worry about cost overruns from project funding since the team is a fixed cost.  Product Owners ensure our teams work on the most valuable things in a consistent manner and at the end of the year we should/can be able to gauge the value of that work to some accuracy.

So here’s a challenge that we face, how do we actually assess value?  How do we value things like reducing technical debt to make applications technically better?  How do we value writing an input validation security framework that makes our application safer for the user and ourselves?  How do we value things that our customers aren’t asking for, but in the end benefit from?  That is the core element of software development, there is significant value in the things that the customer never sees yet we place little effort or priority in delivering these elements.  Instead we focus on the visual functionality and throw quality and architecture down the drain in favor of meeting project timelines.

If you get the fact that you have a fixed development cost it actually should foster better conversations regarding what is really valuable for the entire organization to be working on.  Not your pet projects, not the projects you agree to only to get funding to keep your people employed, that’s not how real value and efficiency happens and it’s time we stop thinking that it does.

Agile highlights very quickly that an organizations planning and funding functions are broken. It also typically becomes clear that we don’t have a real grasp on what our real value streams are and finding them often means removing political barriers that have built up over years.  Agile requires that we redefine what value is and organize our delivery across these streams over organizational silos.

The traditional PMO also goes under a dramatic shift, moving from managing projects and funding to ensuring that programs align to the organizations value streams, are well understood and organizational impediments are removed for the teams.

So if you are looking to move your organization to Agile you must understand that your funding and planning functions must change to align to a new mindset and paradigm.  Funding is easy in Agile, really it is (remember it’s the cost of your team), uncovering your value streams and maximizing the work that flows to your teams that delivers that value, now that’s harder (but not impossible).

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

Top Down or Bottom Up - Large Scale Agile Adoption

So I've worked in both large and small organizations where we have gone through an Agile adoption or the phrase of the day, Transformation. Having seen both sides of the coin I started realizing that you have two paths to take when considering moving your organization to an Agile delivery methodology.

I use the phrase delivery, because I think at the end of the day that is what we are talking about.  Strip away the manifesto's goals of conversation over documentation, accepting change, etc...What are are really talking about is moving an organization from a Project delivery methodology to one that is Product delivery oriented.

What is the difference?  From a Management perspective actually quite large.

1. Project Delivery - These have very strong controls which move people to a new project.  Budgets are set up for the specific time period of the project and then up front requirements and design are completed in order to ensure that the project is fully ready to be engaged.  Project Managers manage all facets of the project via extensive project planning and plans.  Management receives up dates as to the project progress on a regular schedule, usually weekly. Resources are assigned either in full or in part, yet no one actually monitors nor can they really manage whether or not someone is working 25% on a particular project.  Projects tend to focus on reporting and there is high pressure to ensure that individual projects are green, which drives teams to deliver on the easiest and often less valuable parts of the project first and only at the end of the project is the hard work tackled, which reveals itself as budget overruns or timeline delays (or worse delivery of reduced scope).  Project reporting is elaborate and management receives project reports that are often sanitized.  Value is typically not delivered to the organization until the end of the project.
2. Product Delivery - The work that is done for a Product is centered around a value stream it delivers and the work is ongoing.  Teams are funded as a whole and are kept together long-term in order to maximize their productivity.  Work is planned out in short increments called Release Plans that span anywhere from 6-12 weeks, with 2 week sprints.  Management receives regular updates (2 weeks) but can access information radiators at anytime, transparency is the key and goal with Agile Product Delivery.  Teams commit to work in 2 week sprints and their commitment is key to building trust with Management.  As time goes by management can trust that both a teams abilities and productivity can be counted on.  Teams are focused on delivering high quality code to production every two weeks which brings value to the organizations investment in them along with the increased value in terms of new sales, reduced costs, etc...Feedback loops via Product Demonstrations provides management the ability to assess where they are going with the product and deliver not what was asked for up front (Project Delivery) but rather what is actually needed (Product Delivery).

So what does the difference between Project and Product delivery approaches have to do with Agile adoption, well everything.

Most Agile adoptions begin at the bottom of the organization with the teams tasked with developing new software.  These efforts are borne, as the Agile manifesto was, out of frustration with how software was being developed in their respective organizations.  Often management is aware of the issues these teams face but are unable or unwilling to make any changes to how things are currently working and why would they?  You learn very early in your career that rocking the boat is not something that goes over well with organizations, my first boss told me I couldn't by computers that weren't from IBM because you don't get fired if you buy IBM. The message is that if anything goes wrong you need to point to well-known names, processes, etc.. with which to blame or use as support.  To think that this doesn't go on today is to place your head in the proverbial sand.

Though we can have great success with bottom up Agile adoptions with respect to improved productivity within small groups/teams, the overall Project oriented organization is typically still in place.  Management still wants to see project plans, have things 'planned' out for up to an entire year, they aren't comfortable with the fuzzy feel of product roadmaps.  They want commitments, even false ones, so that when things fail they can point to the fact that they had all of their planning in place.

For Agile to really take hold, Sr. Leaders need to change the way that they manage both their people and the work.  It starts first I think in understanding that we have not learned how to speak to management very well yet from an Agile/Scrum perspective.

We need to understand what management is really concerned about and then center our product delivery efforts around that.  One of the problems that we face with some of our leaders is that they themselves don't always know what to be focused on, they are looking at multiple balls in the air but at the end of the day as a Sr. Leader I think I have just a few things I should be focused on:

1. Growth - This is often related to sales, market and revenue.
2. Profits - Tightly aligned with the first item, our ability to make a consistent profit is what helps us continue to reinvest in our company.  Ever increasing revenue or sales without corresponding profits will eventually lead a company into bankruptcy, money isn't free and it is not endlessly available, in spite of what we think we see with new technology organizations.
3. Organizational Excellence - Because none of the above can happen unless you have a great organization.

Agile actually addresses all of the above, yet we spend more time talking about how we will improve our individual work efforts which causes us to  fail to tie this to the needs of management.  Management on the other hand often views the improvements that come from the bottom up approach as more of an anomaly rather than an organizational improvement worth adopting.

Trust is the missing component when it comes to conveying how Agile will make the entire organization better.

Agile isn't easy and it requires skills that frankly many of our Sr. Leaders lack or don't fully utilize and the politics of most organizations reward behavior that doesn't align with Agile principles such as transparency, open honest conversation and openly questioning the status quo.  We have people in power who got there by way of the non-Agile status quo and changing that means they have to learn how the new game is played in order to stay on top, it's much easier to keep things they way they are over learning how to navigate the new.

So how do we speak to our Sr. Leaders with respect to Agile?

1. Better ROI - Talk to any Finance executive about what they look at when purchasing a piece of equipment that will deliver revenue and you will hear them talk about Net Present Value of the investment, Positive Cash Flow and Depreciation costs.
   1. We improve ROI in Agile due to our focus on only the most valuable items.  In non-Agile project work often are working on features/functionality that may be important to someone inside the organization yet will bring little or no value to the organization.
   2. When we are able to start talking about the value streams of our organization, be they revenue, cost reduction or improving our brand image we begin to be able to have a better ROI conversation with management.
   3. We also positively impact ROI via higher levels of productivity gained with dedicated teams.
2. Flexibility - One of the most important elements that 21st century organizations require is the ability to be flexible enough to react to market forces or reactions.  Financing large projects far out into the future with the expectation of some level of return and no we don't really have great track records of predicting future ROI out very far into the future.  With Agile we provide the framework to identify the most valuable work for the business in small planning windows.
   1. Sr. Management needs to understand that this flexibility comes with an obligation to have consistent short term review windows as the team progresses so that we deliver what is actually needed and not what we thought we wanted.  You may have thought you needed a Ferrari when in fact what you needed was a mini-van, we provide the framework to course correct via Sprint reviews every two weeks.  If you plan all of your project up front for the Ferrari, we'll certainly try to make that happen, but in reality as the end of the project nears you will probably get the car but with a lawnmower engine and no brakes, it may look like a Ferrari but it won't operate like one nor will it provide the value the organization really needed.
3. Predictability - Another key element that we deliver with Agile is predictability and accountability.  Your teams will be much more accurate in planning and delivering in short-term 2 week sprints with a planning horizon of 6-8 weeks.  What management needs to look for is consistent delivery of the committed work that the team makes, commitment is everything.  What Wall Street analysts look for is a business that can provide a solid ROI, react responsibly to their competitors or even better be a market leaders and provide predictable results year in and year out.

So the question at hand is what is better a Top Down or Bottom Up adoption?  My money for long-term success is on the organization that can consume what Agile really means, not just to their development teams but the organization as a whole.  You can't BE Agile if you don't make the paradigm shift from command and control to one of collaborative and collective delivery.

BDD Adoption - Taking time to get it right

Recently I've had the opportunity to speak with a broad range of Agile coaches and consultants who have consistently told me that they have not seen any organization successfully adopt BDD as part of their standard process of elaborating their User Stories. Luckily I have had the opportunity to work with several organizations that were able to successful adopt BDD and believe strongly in how this process can transform how you build and bake quality into your products.

I think most people hear the word BDD and they immediately think that it is an automation centric effort, though that is a great value add for BDD, leveraging BDD without automation can also lead to improved testing and quality.

Adopting BDD is so much more than automation (which I wrote about here) it's really about clearly defining the expected behavior of your system.

Why is this so important? Because as humans we all interact differently with the systems that we encounter.  As people who develop these systems we deliver based upon our experiences and understanding of the system we are building.

Language (Business Requirements) has been the manner and method that we have used to convey what we want a system to do to.  However with an international work force we don't all have a shared language.  In addition to this constraint we also interpret what we read differently based upon our primary language, life experiences and culture.  Given this, it's not surprising that when we build a system, it has many different interpretations attached to it, which negatively impacts both the functionality AND quality of our system.

BDD is a way to talk about how your system should behave not what it should do.  Yes we want our systems to have specific functions and features, but talking about how each of these will behave brings about a much richer conversation of what can happen in many functional situations the system and the people will encounter, not just the happy path.

There are two primary components of BDD:

1. The Given/When/Then test setup
2. The Example Table

Getting the first part of your BDD is the most important component because it defines the size and scope of what the User Story.  We do that by decomposing an individual user story into Test Scenarios.  One quick way to determine if your user story is perhaps to large or complicated is to evaluate the number of Test Scenarios you can define.  Keep your Test Scenarios to under 4 per each individual User Story so that you can more easily understand the expected behavior for that part of your feature or functionality.

Keeping the number of test scenarios small is also important once you translate your BDD into test automation which will keep your tests small so when something breaks it is much easier to find out where you need to address a fix.  Remember development teams should be consistently refactoring their code to improve code quality.  With high levels of automation we can quickly catch when refactoring unexpectedly changes the underlying behavior of our system.  This is where Quality is kept front and center in our organization.

The second part of building effective BDD is the Example table.  My training focuses on getting the first part clear and clean because the example table is an easier effort of filling in the expected results in each of your parameter columns.  As with the first section you can use the number of parameter columns as a means of determining if your test scenario is too large.  Try to keep the number of parameters to between 4-8, anymore will result in more brittle tests and more time debugging your automation code.

Adopting BDD as your primary means of decomposing stories may on the surface seem like a lot of work, but remember that you are only doing this level of detail for each 2 week sprint so the number of stories that you build out context driven BDD is relatively small.  Doing it every sprint means you get better at it every time and you will refine your ability to generate BDD much more quickly.

We should also remember that this is a TEAM oriented approach, don't relegate this to your QA team, you will miss getting all of the context needed to delivery high quality code and functionality.