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.
- We also positively impact ROI via higher levels of productivity gained with dedicated teams.
- 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.
