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:

We think it’s the only way to show the cost of the work that we are asking to be delivered.

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.

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

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.

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.

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.

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.

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:

Learn new things (software, processes, tools, etc..)

Take on new roles (Project Manager to Scrum Master)

Report to new people

Change the way that they manage

Change the way that the project manage

Change the way that you plan

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:

Maslows’ hierarchy of needs:

Physiological

Safety

Social

Esteem

Self-Actualization

ERG Theory:

Existence

Relatedness

Growth

Acquired Needs Theory

Need for Achievement

Need for Affiliation

Need for Power

Three-Factor Theory for Employee Motivation

Equity/Fairness

Achievement

Camaraderie

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

People need to feel safe

People need to feel achievement

People need to be acknowledged

People need to feel connected to others

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?

Enagagement–

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.

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.

Needs Met –

Need for Affiliation

Social

Esteem

Camaraderie

Failure –

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.

Needs Met:

Need to learn or be challenged.

Safety

Recognition –

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.

Needs Met:

Safety

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.

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.

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.

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:

Growth – This is often related to sales, market and revenue.

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.

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?

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.

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.

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.

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.

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.

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.

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:

The Given/When/Then test setup

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.

As more and more larger organizations look to Agile as a means of delivering software to their customers the one thing that keeps coming back to me is that for any of this to work there has to be transparency and acceptance that a move to Agile will change your organization, not understanding this will court almost inevitable failure.

Agile in itself is an aspirational desire to change the way that we deliver software, one that does away with the project processes that evolved over the years from Waterfall. I know that waterfall feels sound and safe with all of its up front business analysis, project planning, Steering Committees and that all important Change Management process, but in reality it really is more of a facade than foundation.

Having managed work and projects in both worlds I have seen how it all works. Recently I was told (in an Agile organization) that Project Managers are responsible for delivery and it was at that point that my thoughts crystallized around my own journey, Project Managers don’t deliver, Teams do.

At it’s heart Agile is about everyone doing their part to make our product delivery better, whatever that looks like for your organization in that moment in time. Agile by itself is not prescriptive, the Scrum/Lean techniques and processes that have evolved from our Agile journey may be a bit more prescriptive and become more so when we add things like Scrum certifications to people’s palmares. We need remember that one of the key reasons that the manifesto came into being was an intense desire to find better ways to deliver software, which means the journey has no end and certifications and such are merely ways for us to have a shared language. Let me repeat, once you commence on your Agile ‘journey’ it doesn’t have an end, you will always be evaluating what you can do better.

So back to the question at hand, to succeed or not to succeed in Agile, what needs to happen?

Trust – First and foremost we need to begin to build trust between Sr. Management and our Product Delivery teams. If we have a history of delivering late, with fewer features and cost overruns it is really hard for that same management team to flip the switch once you say you are Agile and trust the very teams who haven’t delivered in the past. Trust is a two-way street and the great thing about Agile is that once you begin to master the techniques and methods that successful teams utilize trust is almost a by-product of that.

Commitments – In Waterfall we are making a ‘commitment’ to deliver a set of value/features in a specified period of time based upon a business requirements document as guidance for what the business/customer is asking for. When we make a commitment farther out into the future we become less and less accurate with our plans, it is the nature of the unknown unknowns in life. Things change, they always do, so to expect that our business and software development teams, in today’s ever-changing world, can predict 9-12 months in the future exactly what they are going to deliver is simply living in delusion. Manage reality or it will manage you. Commitments in Agile are much shorter in time, basically every 2 weeks. These commitments however are based upon the Vision that YOU management need to provide. You say you can’t plan for the future every two weeks I would argue you can’t plan much further out. By planning and committing in shorter delivery increments, management get an opportunity to change direction without causing massive pain from already planned out work. We need to be able to change direction or refocus efforts on the things that are most valuable to our business, not what we made big plans for last year that we thought we needed. Locking in feature development that doesn’t meet customer needs, simply wastes money and loses market share. When teams make and keep their commitments to you, they gain confidence and you gain trust.

Context – In most waterfall projects we end up asking for absolutely everything we think we might need, when in reality sometimes 70% of what we asked for (or even less) is more than enough to meet the needs we were trying to address. Focus on the most Valuable things your customer wants and move on to the next highest value work, not diminishing returns on things customers may not value as much as we might. Teams want to work on what brings the most value to the organization, development teams when provided the transparency of why we need to do something can do amazing things.

Self Organizing Teams – This one really causes I think the most concern for management. You in essence are saying that the teams that you currently manage are better able to make decisions about how to delivery our products. Guess what, they are. These are people who work in the trenches every single day, know every single issue, impediment, risk, etc… associated with your current product delivery processes. And every one of them has probably said something to the effect of, ‘If I was in charge I’d to do X to fix this’. I’ve been a Sr. Manager for many years and have built several high performing teams and one of the best things I can do for them is to provide guidance and vision for what I’m looking for and letting them solve the issues that deliver the solution. I’m a smart guy but I don’t have all of the answers and if you are the type of manager who believes that in order to be ‘respected’ you have to be the one to manage how Agile will change your product delivery processes you will fail personally and the organization will suffer as a whole. Teams of people can solve major problems much more easily than one person can, so let them have the ability to self organize and empower them with making the necessary changes to improve your product delivery.

Context – With great power comes great responsibility. By ceding some level of daily control to your teams you are also doing so with the expectation that they deliver on what they commit to.. If they don’t then they must provide a game plan based upon the Retrospective on how they will solve their inability to hit their commitments.

Investment – Agile won’t come without an investment cost associated with it. If like many large organizations you have a mess of legacy code mixed with attempts at migrating to newer technology stacks, business requirements and rules imbedded in code with tribal knowledge scattered through the organization. Agile requires speed in your product development processes which translates into several investment areas:

Automation – When we say automate we mean across the entire spectrum of the organization, if it can be automated you should probably evaluate whether it can/should be. More specifically we want to automate:

Unit Tests – Developers should be writing unit tests for everything they build, preferably using XP techniques such as TDD (Test Driven Development). These are not really hard processes but if you are starting from scratch there is both discipline and framework that needs to be built-in order to get to a mature state for test automation. Unit tests need to be executed with every build, because with that comes fast feedback if something broke, fix it early and you increase speed and profitability.

Integration Tests – Probably one of the harder areas to get high levels of automation in, primarily because the organization hasn’t invested in the appropriate product like test environments. Be prepared in your Agile journey to spend heavily on getting the right environments in place and highly available. Testing the performance of your system right before you deliver is a recipe for disaster and delays (remember time is money).

Functional Tests – These are the tests management is probably most familiar with and may even have reviewed at one point or another. These are typically the manual tests that QA will execute at the end of your waterfall project, where we are not baking in Quality but testing out defects. Building high levels of automated testing at the functional level gets to what I call, Progressive Regression. Instead of running a final full regression at the end of a 6-9 month project, why not do it every single night? You will need to again invest in physical environments but also in people training as many in the QA world are not equipped to handle the new role of a Software Engineer in Test.

Word of Caution – Don’t rely only on Test Automation in your functional testing efforts, you still need real people with hands on testing capabilities because at the end of the day automated testing cannot always tell you when something is bad from an experience or product flow perspective.

Deployments – One of the hardest things that teams fail at is planning for deployments to their environments. Making your deployment process as frictionless as possible is a high value target for your organization. Many organizations don’t have a fully functional DevOps org and many in this field are still struggling to figure out how to operate in an Agile world. Let them figure it out and provide them with the tools that will support automation of critical deployment processes and hold them accountable to doing it. To many times we purchase tools and then never make the time to actually use them, invest and utilize, that is the key to your ROI.

None of the above work comes without an investment in both hardware and people. Current requirements processes will change substantially as you move to an Agile cadence. People will struggle to find their way, some level of productivity reduction is expected in the beginning of an Agile transformation. You as a Leader need to set a clear vision of why the organization needs to change, make it clear that the teams have accountability to deliver the work that they commit to and that you as a leader have accountability to provide them with space to learn, fail and finally improve. Successful Agile includes failure because without it we aren’t really learning from our mistakes, rather hiding the truth. Agile done right makes everything visible, especially who is accountable for what.

Patience – Nothing great was ever built-in a day or a week. Odds are good that this will take more time than you thought it would, but also make it clear to the organization that an Agile death march is not something that you are taking on either. Agile is about accountability and commitment, use these values to your benefit and identify those that simply can’t or won’t work in an Agile environment.

From a management perspective you need to understand your role in the success of any Agile transformation, it must also change the way you look at and manage your business.

Over the years I have seen many teams and organizations who start on their journey towards Agile product delivery make the mistake of thinking that Agile is easy, promotes freely changing direction and worse will fix all of your issues and make everything better quickly and easily. The truth couldn’t be further from the reality.

There is no such thing as a perfect software development delivery process. Unlike production lines for things such as automobiles where you have the same pieces going to together each and every time and each piece has a specific functionality, tolerance and timing, software development is the exact opposite.

Software development is about meeting changing needs across the dynamic nature of business For example – You wouldn’t see an automobile company add anew feature to a car on their assembly line over a 2-4 week time period. They need time to design the entire process and ensure that the production line is capable of accepting the new change.

Traditional software development tends to align a bit more to the automobile example and in fact there are times where this type of rigid, pragmatic approach to product delivery is actually the correct process (Agile isn’t for everyone nor for every situation).

However for those that are going to move to Agile you need understand that the type of discipline that you might use in the automobile example actually needs to exist in your Agile processes, seriously you ask? Yes – You need to be able to deliver high quality, well-tested and fully functional pieces of software every two weeks. Now are you seeing how difficult Agile can be?

If you think Agile is easy, then you are already on the path to failure and unmet expectations.

It is very common for teams who are moving to Agile to take their interpretation of the Agile Manifesto to the unhealthy extremes, for example:

Working Software Over Comprehensive Documentation

Many teams I’ve worked with take this to mean NO documentation and that couldn’t be further from the truth. We value working software over the need for documentation but I’ve never believed that you can have long-term success with your product without delivering some levels of documentation. Without documentation your software knowledge becomes tribal and when your tribe leaves the team or your organization, well so does their knowledge.

There are way for teams to build documentation as part of their daily Sprint development work. Using the combination of user stories and Behavior Driven Development (BDD) acceptance criteria as the foundational elements of your work you are creating your documentation as part of the work needed to deliver quickly. The great value in BDD is that the acceptance criteria is written in English syntax and then translated into test automation.

This process of writing stories with BDD is supported by Gojko Adzics book, Specification by Example and allows us to deliver light weight documentation during our sprints. I often see teams adding a story to a future sprint to handle their ‘documentation’ requirements of their previous work but I haven’t seen this work long-term. Functional development, dealing with bugs, etc… will ultimately push these stories down into the backlog, never to be seen again.

The process described above is not easy, but it can be done and the teams that can get to this level of capability will succeed in driving value to your organization every two weeks.

One of the things that I consistently tell organizations moving to Agile is that it will highlight every current weakness of your product/software delivery methods. Agile is a game changer, it requires a mind shift in how you look at your product, the work that supports it and how you see the visualize the value your product delivers. If you are a leader who is going to be uncomfortable finding out truths about your organizations inefficient manner of product delivery then you need to think twice about moving to Agile.

Do you have TITL (To Important to Lose) people in your organization? If you do, then you need to really look at how they influence any changes in your organization. Do you need to get their approval, gain their support, etc….? If so you will find more often than not that Agile will scare the hell out of them. Successful Agile teams/organizations understand that self organizing teams take away the need for many of the day-to-day management decisions our middle management layer makes. Agile speed comes when you remove the friction of management layers and provide teams with a clear vision of what you want them to deliver.

You must be prepared for the resistance that you will face from your product delivery teams, not everyone wants to go to Agile We become comfortable with what we know and do in our daily work life and in that comfort comes stasis. If you are not prepared to lose people, especially your TITL people, then you need to question if Agile is really for you.

I know it sounds heartless, but I’ve been working for over 30 years and one of the first things I learned right out of college was that technology was disruptive and if you weren’t on board with how it changes how you work you would be left behind. At one company I worked for many years ago, I saw Regional sales managers who had been with the company for over 30 years and when we rolled out a sales force tracking/marketing tool (which I led) there were several who refused to even turn on the computer, they were all let go within months. As employees we have the obligation to continue to grow and learn and continue to make ourselves valuable to our organization and if we don’t, then you as a leader have an obligation to make tough decisions that ensure that the organization is continuing to grow and not stagnate with old processes. It’s not personal it’s business.

As you move to Agile you also need to understand the investment that needs to be made in your technology stack. Many organizations have decades old technology stacks which have been shoe horned into the future and though you get by you won’t be able to become Agile until you have a strong Continuous Integration framework, high levels of Unit, Integration and Functional test automation. Getting to this will take time (and using the stories and BDD disciplines mentioned above will help you get there). You simply can’t go fast if you don’t have the technology backbone that supports it.

Agile isn’t easy by any stretch of the imagination, it requires thoughtful introspection, focus on continuous improvement, disciplined delivery and a tenacity for value and quality that is never satisfied.