CEO Guide to Agile

What is Agile?

Agile has different meanings to different audiences. For the majority of customers, Agile applies to the development of digital products or services. To help our clients, we identify a few clear definitions and outcomes.

Agile is typically used to describe the software development methodology for SaaS companies, eCommerce companies, and digital teams.

Agile is usually contrasted with Waterfall.

Waterfall has distinct phases such as Requirements, Design, Build, Test, Deploy/Go-Live, and Support. The output of one phase ‘falls’ into the next phase.

These Waterfall phases typically take months to years. The V model is helpful to illustrate the purpose of each phase and why waterfall typically takes months to years in duration. The V model shows which phases validate a prior phase.

Waterfall is perfectly acceptable if the scope is known and will not change from what was known at the beginning. Waterfall is also acceptable and usually required where there are long supply chains and/or dependencies on other teams or 3rd parties. Waterfall is also typically used when the product or service that is designed is unlikely or unable to change with the first 2 years or more after the completion or launch.

Agile, in contrast to Waterfall, is iterative and collapses the Waterfall phases by re-organizing work activities, eliminating unnecessary steps, and automating steps that was not viable until the early 2000s.

Comparing the two approaches, Agile is designed to accommodate changes in scope without penalizing business stakeholders.

Agile is typically preferred to Waterfall when scope is acknowledged to change or needs to be ‘discovered’ over time. These iterations are important to respond to feedback from end customers. Products or services that launch and are adopted quickly typically have changes that occur in the early launch window. Agile enables these changes to respond to market feedback, particularly if you automate right steps and skip the optional steps.

Why is Agile important?

Agile is important now for several reasons:

1. Agile is the primary software development methodology for newer companies, transformations within older companies, and recent college graduates. If you want to create a great place to attract and retain talent, you need to master Agile.
2. Agile is the primary methodology for the most successful SaaS and eCommerce companies in the world. If you want to continue to scale your company, you likely need to master Agile.
3. Agile enables very small companies to compete with much larger incumbents and take market share rapidly. If you are not doing Agile today, your competitors, potential acquisitions, or potential acquirers are mastering Agile to continuously deliver valuable features and fix or hide flawed features.
4. Agile, done properly, helps keep teams aligned and connected in the disconnected post COVID-19 world. The time boxed meetings with clear roles, attendees, and topics provide a great mix of live meetings with time for each team member to get stuff done in their day. Misapplying Agile techniques and tools with remote work can become toxic for work culture and morale.

Key Agile Points for CEOs and Boards

Boards and CEOs need to understand several concepts that can help or hinder Agile delivery:

1. Respond quickly to the market: Unlike physical goods such as buildings or automobiles, modern software can be modified after it is in the hands of customers or end users. If a competitor introduces something better or if customers do not like some aspects, Agile enables you to quickly correct course.
2. Firm short term plans, flexible roadmap: By responding quickly to the market, long term plans must be flexible. However, short term commitments such as the next 2 weeks should be as firm a commitment as possible.
3. Automate and self-service as much as possible: Most humans struggle with repetitive work while machines are designed for it. Repetitive work usually causes the human mind to default to the Type 1 thinking described by Daniel Kahnhaman. Type 1 thinking leads to common mistakes and burnout. Humans doing repetitive work that can be done by machines is typically more expensive to the firm over time. This automation should be focused on self-service for everyone in the value chain. Self-service is not only for engineers, but it also applies to customer support teams and customers.
4. Constrain and Monitor Work in Process: Work in Process (WIP) in Agile is the number and size of tasks that start and stop in an iteration – typically in 2 weeks. By minimizing WIP within a team, the likelihood of meeting your commitments increases.
5. The Agile Manifesto is alive and well: The Agile Manifesto was written by a group of software developers in 2001 to find a common ground to common problems. This group was passionate about avoiding late projects and unhappy customers. The Manifesto is quite short – only 9 lines. To help interpret the Manifesto, the team identified 12 principles that each software team should be following. Although the website is well preserved visually from the time it was originally authored, the 12 principles are still relevant today. Teams that are missing even 1 of these principles will almost always lead to suboptimal outcomes.
6. Co-located teams or recreate the experience: At the core of Agile, developers and business stakeholders are meeting in the same room multiple times per week. The face to face interactions (synchronous) are needed to more quickly coordinate communications vs messaging back and forth. Asynchronous communication in Agile teams leads to numerous forms of waste such as waiting, errors, and overproduction. For companies that are no longer meeting in person, the in-person communications need to be replaced with live communications and tools that replace what works so well in the same physical space. The real sense of team is what is important – and remote teams need to recreate the real communications that make teamwork enjoyable and rewarding.
7. Architecture can hinder Agile: Agile works best with teams smaller than 12 people due to communication overhead increasing exponentially (as team size increases). Teams may be properly formed around customer facing outcomes, but may still be hindered by the underlying architecture. When an application grows in size due to increasing functionality, multiple teams may be working on the same underlying components (e.g. sections of code, tables in databases, etc). When multiple teams are coordinating with each other to avoid errors, they are violating the principles of Agile and slowing down development! To avoid this, teams will need to split these larger applications (what we refer to as monoliths) into smaller services (frequently called microservices). Splitting monoliths is not an easy task. See our best practices how to safely split up large monolithic applications to enable teams to independently deliver features.

The next section helps you determine if you are using Agile properly to improve business outcomes.

Common CEO Questions about Agile

The CEO needs to be able to answer these questions for both board members and employees:

• How do I really know if we are Agile?
• What are ceremonies – and do I need to attend them?
• What are story points – and why are they important?
• What does velocity mean in Agile?
• What is the difference between a Product Owner and Product Manager?
• When is Waterfall better than Agile?
• What is the difference between Product, Project, Program and Portfolio management?
• How does Agile change our budgeting process (and CFO’s mindset)?

How do I know if we are really Agile?

The fastest way for your team to determine if they are really Agile is how well they are following the 12 Principles of the Agile Manifesto. This quick survey can help you benchmark your team.

The slightly more advanced way to determine if your team is following Agile is to see how well they are adhering to Scrum practices that are taught by leading professionals. This longer survey is what we use in teaching our clients Scrum/Agile. We capture an initial baseline and a follow up 3 months later to track that proper behaviors are being followed.

What are ceremonies – and do I need to attend them?

Ceremonies are the formal meetings practiced by the core team and extended stakeholders. The core team will attend almost all ceremonies. The extended team will typically only attend one ceremony which is called the Sprint Review. As the CEO, you should only attend this type of ceremony. With a large number of teams, you can only attend a handful of Sprint Reviews. Your VP of Product or Engineering should let you know which Sprint Reviews you need to attend.

Your responsibility as an executive it to enable each Agile product team to be as productive as possible. You want to maximize the time developers are delivering valuable features.

What are story points – and why are they important?

Story points are the way in which each team estimates the effort of work for that particular team.

Story points refer to the effort required by the team to deliver each task. Each task is considered a user story. Some teams simply use the term ‘task’ rather than ‘stories’. We prefer, where possible, to use a properly written user story rather than a task. A user story help explain who benefits from task and why it benefits that user. By writing tasks as user stories, the likelihood of mistakes or errors by engineers is reduced. It also increases the chances of innovation to let engineers creatively solve problems versus being told what to build.

Furthermore, story points are used to track how much effort each team can handle in an iteration (frequently called a Sprint). If your team is communicating effort in terms if time (e.g. hours, days), this is usually a sign the team is not fully understanding the principles of Agile.

Story points are a ‘relative sizing’ methodology for estimating work. For example, if a CEO needs to lead different activities such as preparing for board presentations, recruiting a VP of sales, evaluating a potential acquisition, or responding to a lawsuit – a CEO may relate the size of each effort to other known efforts to get a sense of the relative effort for the CEO and his/her team. As CEO, you likely have a deadline you must meet to complete these activities. However, you are likely not estimating exactly how many people and how much of their time is needed to accomplish each activity. From the list of examples, an acquisition will likely require more people than responding to a lawsuit.

Story points also typically use a Fibonacci number or technique where there is non-linear difference in size between estimates. Unlike a t-shirt sizing effort of Small, Medium, and Large – the relative difference between those sizes can be difficult to determine if they are relatively close to each other. For example, sizing where the next size is 10-20% greater than the previous size is hard to identify significant differences. The difference of each bucket of work needs to be noticeably different to matter.

Note that you do not compare story points across teams. The story points are for each team to determine how efficiently and effectively they work as an individual team.

As CEO, you only care that each team is using story points to estimate work, each team has multiple people estimating story points, and they are tracking how many points they are committing and completing each iteration.

What is velocity?

Velocity in Agile is really throughput per team. In Agile, it is the number of story points each team is able to consistently deliver each iteration. The term velocity is used so teams can think in terms of their throughput as slowing, accelerating, or steady state.

When teams are properly following their ceremonies, particularly the Retrospective ceremony, each team can identify what is slowing or improving throughput.

Strong Agile teams can self-identify where they need more automation, additional skills, or other types of help to improve velocity (throughput).

Durable teams that are fully autonomous are typically the highest performers. Swapping out or losing team members will typically drop the velocity or throughput of the team short term.

As CEO, you may be shown burn-down charts or burn-up charts. Burn-down is tracking how well each team is doing each iteration to get the work done. Burn-up is the cumulative addition of story points that track how much relative value each the team is producing over multiple iterations. As CEO, you are more likely looking at burn-up charts.

As CEO, you need to make sure that your VPs of Engineering and Product are tracking velocity for each and every team over every iteration, and that they are able to help teams when they need it.

What is the difference between a Product Owner and Product Manager?

Product Owner and Product Manager are sometimes used interchangeably. We prefer that SaaS companies understand our definitions to make sure these two roles are being performed – preferably by the same person.

A Product Owner in Agile is the person that prioritizes which tasks or stories get worked on each iteration (or Work in Progress). Typical Agile training doesn’t describe how the Product Owner prioritizes work, it simply identifies that a single person must be in this role. Other team members and outside stakeholders can influence the Product Owner, but the Product Owner makes the final call what gets worked on and what gets deferred to future iterations.

A Product Manager is the traditional Product Manager in hardware or other physical goods. A Product Manager is acutely aware of the competition, market forces, user personas, and profitability of their portion of the product. A Product Manager may have been formally trained via a group such as the Silicon Valley Product Group and/or they may have their MBA. A Product Manager has been trained or has the competitive mindset to know how to prioritize work.

We sometimes find Product Managers that do not properly understand their role in Agile/Scrum or Product Owners that lack the outside-in view of their competition, buyers, and influencers. In short, a Product Owner is a role on a team and a Product Manager is a full time job. Ideally, your Product Managers understand concepts from the SVPG, think like mini-CEOs, and are adept at Agile principles.

When is Waterfall better than Agile?

Waterfall is better than Agile when the scope or design has a very low likelihood of changing from the beginning of the project. It is also better than Agile when there are numerous 3rd party dependencies that need to be tightly coordinated and sequenced.

Replacing older systems can be more effective in Waterfall when a thorough Discovery process has been performed to uncover hidden risks, identify dependencies, create a sound design that has been approved by end customers or key stakeholders.

As CEO, you will still likely need someone skilled in traditional waterfall project management because these activities do not go away in a pure SaaS and Agile world. You will likely need to replace old systems, work with 3rd parties, incorporate new entities via M&A. A seasoned project manager in both Waterfall and Agile is much less risky than a person who has only held a leadership role in an Agile team.

What is the difference between Product, Project, Program and Portfolio management?

Unfortunately, the terms Product, Project, and Program are misapplied or generalized. Or, each term means something different to different people. We have provided the following definitions to help get clarity on these different types of work patterns.

• Product – is trying to find a current and future market fit at a profit
• Project – has a known scope, start, and end date
• Program – we refer to as repeatable (do it frequently) or ongoing effort (sequence of projects)
• Portfolio – is a grouping of any of the above (product, project, program)

Different disciplines are needed to master each of the aforementioned work patterns or management of work. For software products, Agile is a discipline that must be mastered.

As CEO, it is important that your leaders have an understanding and preferably agreement on the definition of each of these terms. At the very least, leaders and employees need to recognize that these terms are not synonymous across team. They also need to know which disciplines are needed to master each type of work, and when mastery of one or more is needed.

How does Agile change our budgeting process and CFO’s mindset?

In Agile, we care about how efficiently and effectively we create output. Not input. More important, we care even more about outcomes than output. Output should align to outcomes.

We prefer that the CFO, VPs of Engineering and Product, and ideally every engineer and Product Manager understand the cost of input vs output, and output vs outcomes.

CFOs have the right mindset to be aware of the cost of each team member and team. We recommend that each team leader understand the cost of each sprint. For example, if a team has 10 team members, each with an hourly rate of $150/hour, and approximately 10 working days in an iteration – that is a cost of $120,000 per sprint. With 20 iterations/sprints in a year, that team has a cost of $2.4 million per year.

Each team should be delivering significantly more value than they cost the company on an annual and quarterly basis. It is difficult to deliver immediate value every sprint/iteration because teams need to pay down technical debt or invest in new technology to improve velocity (throughput). However, each team should be pointing to customer value delivered multiple times per quarter.

Focusing only on cost per input – the hourly rate of each team member -- without focusing on cost per output or outcome will inevitably lead to lower financial returns to shareholders.

How does Agile fit with OKRs?

OKRs are Objectives/Outcomes and Key Results. We prefer the use of the word Outcomes. Outcomes should paint a clear picture of what success means in the future. Outcomes defined in terms of customer value are easier to cascade down to product teams. These Outcomes make it easier for each team, and particularly the Product Manager, to prioritize stories for each iteration and articulate the customer value delivered every iteration, quarter, and year.

What Agile is NOT

Agile:

• Does not mean cutting corners – Agile has rigid ceremonies, roles, and activities that if skipped, derail the effort. We have retrained multiple clients on failed Agile transformations.
• Is not 100% synonymous with SAFe implementations –SAFe or Scaled Agile Framework for enterprises is a hybrid methodology that attempts to create the best of both Waterfall and Agile. It is our opinion at AFK that proponents of SAFe focus too much on the command and control elements of SAFe vs the decentralized autonomy of pure Scrum/Agile. While minimizing risk for Waterfall delivery is important, we find SAFe proponents typically do not prioritize creating profitable products and services as much as they do following enterprise wide processes.
• Is not isolated to Product and Engineering – Companies pivoting to Agile or reintroducing Agile will typically require involvement from HR (recruiting new talent and coaching out the untrainable), Sales & Marketing (interactions may change with Product teams), Finance (what to measure and how to report to the board), and Operations (have one or more product managers focused on automation for their teams and customers).
• Is not a quick fix to structural issues in your architecture, processes, or organization – Agile may expose underlying issues that are true bottlenecks to productivity. The measurements and ceremonies should help identify how and where to fix these bottlenecks.
• Is not just about improving throughput/velocity – you need to measure progress by improved business outcomes. Outcomes from well-formed customer/market oriented OKRs that tie to financial results generate the best results for SaaS companies.

Where AKF can help

AKF helps companies of all sizes and ages with continual innovation in the Digital Age. We can assess and fix:

• How well your team understands and applies the key principles of Agile – see the short and longer form self-assessments.
• If your team is confusing different types of work patterns – such as Scrum, Kanban, Waterfall, or a hybrid.
• Which type of work pattern is appropriate for different teams.
• If your organization is properly organized to successfully implement Agile.
• If your technology is holding you back from implementing Agile.
• Where the points of friction are in changing behaviors to proper Agile.