Home > Articles > Software Development & Management > Agile

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.


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.


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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020