This chapter is from the book
This chapter is from the book
This chapter is from the book
An Executive’s Viewpoint
Executives play a critical role in an Agile transformation, because they hold the power in terms of budget and personnel resources to either back the Agile transformation or reinforce the ways of the past. They also have the opportunity (and obligation) to lead by example, because others in the organization are surely watching to see if situations are handled differently, now that they are an “Agile” organization.
What Is Different?
How an executive’s role changes within Agile is interesting. Many executives are the sponsors of the Agile transformation without a deep realization that their role will also be altered. Outlined next are several examples of how executives are asked to stretch and evolve in an Agile environment.
Embracing Evolving Requirements
Executives are tasked with budgets, milestones, and reporting progress to the board of directors, shareholders, and others who have invested in the success of the company. The executives need to be wise stewards of the financial resources that they control to ensure company success; that is a heavy responsibility, which makes many executives want to chart a clear path before a dime is spent. This type of thinking works well in a Waterfall environment, where we complete our requirements before we utilize our often expensive development resources. However, the ever-increasing pace of change in the marketplace makes it increasingly difficult to map out an entire project before we even begin. Agile asks executives to shift from operating capital budgets with robust (though often inaccurate) business cases to an environment of rapid delivery and inspection. For example, a company wants to replace its mainframe system with a more modern, scalable architecture. In the past, a project would be kicked off to assess every application on the mainframe and what it would take to move that application elsewhere. What are the integration points? the risk factors? the expense? the required resources? the schedule? And much more. The project management team would pore over documentation, create massive spreadsheets, and make thousands of assumptions to present a plan to the executive team. It would likely be a multimillion-dollar project with a lengthy timeline. This type of activity provides security to the executives because they can see the entire project laid out, and they believe they can anticipate the cost to completion. The problem with this approach is that assumptions have been layered onto assumptions within the business plan because there is no way to answer all of the complex questions before beginning an effort of this size.
Agile advocates for a different approach. Let’s just try to replace one minor application in the mainframe. We will keep the scope very small, we will deliver frequently, and we will inspect our results often, allowing us to course-correct if necessary. With the learning gained from the first effort, we will embark on the next effort, and so on. The organization gains much more predictability in the incremental deliverables, and the wise Agile executives are courageous enough to present this new philosophy and information flow to their investors.
Respecting the Priorities
Executives in all organizations participate in different conversations than the developers and managers, and this leads to slightly different perspectives. If an executive has just been grilled by an existing customer over a problem in the product, or by a high-margin prospect who will sign the contract only if a specific feature is added, it is common for the executive to place high priority on that immediate feedback. Keeping customers happy and gaining new business are critical to the organization and its longevity, so executives are justified in their sense of urgency. This becomes detrimental in an Agile organization when the executive priority disrupts the current work that has been fully groomed, as described in Chapter 6, and has been committed to by the development team. Stopping their work in progress is hazardous and often unnecessary. What an experienced Agile executive will do is understand and respect the current priority projects being delivered and will send the request to the appropriate product owner to begin exploring all of the details of the new request. The executive that says “stop everything and work on this” when “this” is likely ill-defined and not fully understood creates a chaotic environment where the teams are not able to deliver on their commitments.
Executives came to be in their positions because they are decisive, action-oriented and results-driven, so their first impulse is to mandate an immediate response. However, respecting the existing priorities, providing the team with an opportunity to clarify the details and examine the best solution, and allowing the team to finish the work currently in flight will lead to much more consistent and predictable results.
Staying the Course
An Agile transformation is challenging for most organizations. Some command and control managers will fight the change, offering dire predictions of failed projects as examples of why this is a bad idea. Developers may not embrace the increased accountability and transparency, and some may choose to leave the organization. There are new expenses in the form of seating arrangements, training, and Agile tools that may stress the budget. Agile transformations also have a history of bringing chronic issues that the organization has ignored for years to the surface where they must be confronted. All of these are reasons why an executive might abandon the effort and simply revert to what is comfortable (but ineffective). Any change worth making is going to require effort, and Agile is no different. The strong Agile executive will work through these issues without wavering on the commitment to Agile.
Let’s examine these instances individually to identify the best reaction by a truly Agile executive.
- The command and control manager is uncomfortable. This often takes the form of bringing up the multitude of ways that Agile could fail—the teams cannot self-organize, our clients are too demanding, our software is too complex, we are impeded by government regulations, our business partners are too inexperienced, and so on. Each of these hurdles, and many others, has been overcome by organizations with Agile. The Agile executive needs to resist the urge to slow down the implementation and carefully think through every possible scenario. Instead, he or she should embrace the “inspect and adapt” mantra of Agile by moving rapidly and carefully forward and learn from every decision. Constantly inspect the implementation and make course corrections as necessary. Do not let fear of what could happen delay the positive outcomes of what will happen.
- Developers self-select out of the organization. There are certainly people in every organization that we believe we cannot live without; their domain expertise or years of experience make them assets to the organization. Agile supports these experts and provides them with opportunities to contribute in ways they may never have before. The employees that see and desire the collaboration and accountability associated with Agile are critical to the longevity of the organization. Those that are threatened by Agile and want to withhold their expertise or refuse to try new alternatives will ultimately hold the organization back. Certainly, their departure is disruptive, but it can and should be managed by an Agile executive. Creating an environment of continuous learning involves identifying and rewarding those who want to join the transformation.
- New expenses. Agile does not break a budget, nor does it come for free. If you are truly committed to changing an organization’s culture, then spending money on training and tools and possibly even new hires is an investment—not an expense. Asking an organization to convert to Agile without any additional budget is not demonstrating the necessary commitment to the change. Agile executives need to “put their money where their mouth is” and authorize the appropriate expenditures to ensure success.
An Agile executive will stay the course when confronted with issues and concerns. Making an Agile transformation cannot be optional to the organization: Either the executives are committed or they are not. There can be no wavering, because the minute an executive indicates that it is acceptable to continue with the old ways of doing business, many people will fall back into their old, comfortable patterns that will not deliver the desired results.
Successes
Agile executives that are committed to the transformation can chart a meaningful path for their teams by focusing on the right things that will drive true culture change.
Focus on Sustainability
One of the 12 Agile principles states that “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Promoting this is a critical success factor for Agile executives.
We need to avoid burnout amongst the teams. When organizations adopt Agile, there is typically a good deal of enthusiasm and a desire to work hard and deliver compelling results. Then as the Agile implementation continues, some teams can suffer from long hours, which can create an unsustainable environment. Bob Hartman wrote about this in a July 2009 blog:
If the pace of the team is not sustainable several undesirable effects are likely to occur:
Defects will increase. Tired teams let more defects through.
Work output will decrease. Tired teams do less work in more time!
Morale will drastically decrease. This may lead to employee turnover at a most unfortunate time in the project.
The blame game will become common. (Not our fault you didn’t say X. I said X. Did not. Did so . . .)
The team starts to abandon good practices for those that “seem” faster. Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA! (Hartman 2009)
The responsibility for sustainability often lies with executives because they can control the resources and, to some extent, the expectations of the organization. If executives make commitments to customers that are unreasonable or fail to provide teams with the tools and training that they need, then the executives are contributing to an unsustainable environment where good people can become frustrated, which either affects the quality of their work or may even encourage them to leave the organization. Most employees want to work hard and accomplish significant goals, but they require an environment that facilitates their success.
Focus on Technical Excellence
Another of the 12 Agile principles focuses on technical excellence by stating: “Continuous attention to technical excellence and good design enhances agility.” A strong Agile executive can have a tremendously positive impact on this idea by making sure the teams have both the time and the resources to make wise architecture decisions that will allow the application to scale and perform. Executives who want teams to rush to designs or build point solutions are not allowing them to do their best work. Technical excellence pays dividends not just today but into the future, because a well-designed platform can handle evolving requirements and additional features. A poorly architected solution will result in convoluted designs to accomplish future goals. Jeff Sutherland, a signer of the Agile Manifesto and a creator of these principles, finds that one of the biggest remaining problems for Agile teams is that they do not demand technical excellence (Sutherland 2011).
An Agile executive has an opportunity to influence this, just as a university professor does. By forcing team members to slow down enough to think things through—and giving them the time and latitude to do so—both professors and executives encourage thoughtfulness and deliberate decision making. Rushing and setting unrealistic expectations compromise technical excellence.
Focus on Simplicity
There are many wonderful quotes about the value of simplicity and how hard it is to achieve, including one by Leonardo da Vinci: “Simplicity is the ultimate sophistication” (Goodreads 2013).
An Agile executive that understands and values simplicity can propel the organization forward. Simplicity can be utilized in an Agile implementation in several ways. The first is with the implementation itself. Being flexible in an Agile implementation means embracing the unknown and trying new things. If an organization tries to overplan an Agile transformation and think of every possible roadblock that could be encountered, they will strive for perfection and get stuck in a lengthy (and Waterfall-like) planning stage.
The Agile organization that understands simplicity will try different small steps to learn what will work best for the organization. Continuous learning by inspecting and adapting allows for a simple approach to Agile.
The second way that an Agile executive can embrace simplicity is with the corporate or product objectives. When goals are too ambitious or expectations are too varied, it leads to an organization that is fragmented and chasing too many disparate deliverables.
Steve Jobs once said, “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are” (Griggs 2012).
An Agile executive knows that simplicity and precise focus enable the teams to deliver great work.
Failures/Risks
How can Agile executives fail when it comes to an Agile implementation? There are many things that even well-meaning executives do that sabotage the Agile efforts of their teams.
Not Honoring Commitments
One of the most common mistakes that executives make is not allowing the teams to honor their commitments. Looking at Scrum as our example, executives need to adhere to the sacredness of the sprint. What does this mean? It means that once a sprint goal is committed to, there should be no changes to that goal. This is especially difficult for executives because there is always some crisis or customer request or great idea that an executive wants the team to investigate immediately, and there is a tendency for executives to pull the team off their sprint commitment to work on the latest critical task. The executives that refrain from allowing their urgent requests to disrupt the team are more successful in their Agile adoptions. Truly, it is a sign of executive commitment to the process and the methodology if they honor this one aspect. Mike Cohn (2010) is very firm on this issue: “Nothing is allowed to change within the sprint. The team commits to a set of work on the first day and then expects its priorities to remain unchanged for the length of the sprint” (p. 279).
Are there instances where the sprint must be interrupted? Absolutely. If one of your production servers goes down and your developers need to restore the system, then that is clearly a priority over new development. If you are under attack from hackers (such as a DDoS attack), then the developers may need to work on an immediate patch. Those situations notwithstanding, there are many more instances where the “crises” can and should wait while the team works on their current sprint commitment.
A strong Agile executive should have the power and conviction to keep fellow executives in line so the sacredness of the sprint can remain intact. Executives who have not fully embraced Agile or do not appreciate the impacts of their decisions on the organization can create chaos and confusion by not honoring the teams’ commitments.
Not Engaging the Rest of the Organization
Another common failure of an Agile executive is not enlisting the support of the other departments within the company. Often the Agile executive sponsor is the chief information officer (CIO) or another leader in the IT organization, which is where most Agile implementations start. It is imperative that the CIO or Agile sponsor capture the attention and support of the other department leaders to ensure the success of the implementation. This is particularly critical with “the business”: If the Agile implementation is viewed as an IT-only endeavor, then the organizations that need to contribute clarity regarding business value and priority may not actively participate, which can doom the Agile efforts. The people in marketing or product management or various customer-facing departments have the best sense of the marketplace, competitive environment, and customer behavior, and therefore are the best people to make the prioritization decisions so the most important and valuable efforts are worked on first. If those organizations do not participate in the Agile transformation, then the opportunity for success is greatly diminished. The Agile executive sponsor needs to illustrate to peers the importance of their involvement and the value that they will derive from participating. Gaining their commitment often requires executive alignment and usually cannot be accomplished by those lower in the organization. The time commitment and the changes to the way that work progresses through to completion will affect many organizations, and their buy-in is absolutely critical. An ineffective Agile executive may ask the team to solicit the necessary involvement from the other organizations, but this passive approach typically does not deliver the appropriate visibility and alignment. The Agile executive sponsor needs to convince his or her peers that Agile is right for the whole organization.
Valuing the Wrong Metrics
Executives play such a critical role in an Agile transformation, and often they may not realize the messages that are sent to the organization when decisions are made, even with the best intentions; metrics are a perfect example of this concept. A well-meaning executive can completely derail an Agile implementation by trying to measure the wrong things. Let’s look at a few examples.
- Actual time taken to complete a task vs. estimated time
- Velocity of Team A vs. Team B
- Number of stories with acceptance criteria vs. those without
Each of these metrics may sound reasonable, but they could drive the wrong behavior. With the first example, one might wonder: What does the organization value, working software? or precise estimates? Of course, Agile would like the estimates to be relevant and close to the level of effort required, but we want our developers to spend their time writing great software, not doing extensive research to ensure accuracy in their estimates. Defining the wrong metric could force developers and testers to spend time in unproductive efforts.
In the second example, velocity, or the amount of work that a team can accomplish during a sprint (described in detail in Chapter 6), is a tool used to predict the amount of work that a team can commit to, not as a measure of productivity. First, two teams could use different measures of effort—a medium-sized task or an eight-point story (also described in Chapter 6) might mean very different things to different teams. Second, a dip in velocity might have nothing to do with productivity: If Team B has three developers at a training class, then the amount of work they can accomplish is reduced, but not because the team is less productive.
Finally, with the third example, the premise behind Agile requirements gathering is that we are learning and negotiating on the best way to deliver maximum business value. If we are measuring the performance of how stories are written, we may unknowingly reduce the conversation about that story.
Agile executives need to be very careful about the metrics they choose to ensure that incentives are provided for the correct behaviors. Measuring success in an Agile environment is different from traditional metrics, as we now place a heavy emphasis on customer satisfaction, frequent delivery of working software, and continuous learning.