Implement Agile Practices That Work

Agile is a cultural shift. Don't just do Agile, be Agile.

ANALYST PERSPECTIVE

"Agile is not a silver bullet that will magically fix what ails your organization. An Agilist who is not aware or realistic about the limitations of the organization they must work in will fail. The first step is to get real about the challenges of changing every aspect of how your organization works."

Cole Cioran,

Senior Director, Research, Application Delivery and Management

Info-Tech Research Group

Our understanding of the problem

This Research Is Designed For:

• Executives who need to evaluate the potential benefits Agile practices have for their organization.
• Application development managers who are looking for ways to optimize the value and efficiency of their development practices.
• Current or future Agile practitioners and enthusiasts who wish to understand Agile principles, methodologies, and its adaptability.

This Research Will Help You:

• Gain an understanding of Agile practices and how to adopt them successfully.
• Assess your current environment to determine where Agile can fit.
• Determine the right pilot for a structured evaluation of Agile.
• Identify and engage the relevant stakeholders on your Agile transformation journey.

This Research Will Also Assist:

• CIOs who are weighing the benefits and costs associated with implementing an Agile practice.
• Managers who are evaluating cultural shifts, organizational redesign, product development process changes, and customer impact.

This Research Will Help Them:

• Determine the value and benefits of adopting Agile.
• Evaluate the changes that need to be implemented to help Agile be a success in their environment.

Executive summary

Situation

• Many organizations have heard of Agile and the benefits it promises to software development practices; however, they fail to see the industry hype around the benefits it promises.
• Many delivery teams try and fail at “doing” and “being” Agile without proper training and education on what Agile is.

Complication

• Many Agile implementations fail due to a lack of experience and not understanding what Agile really is and the problems it is trying to solve. When these projects fail, Agile often gets blamed for it.
• A lack of management support, inflexible organizational culture, resistance from team members, and insufficient training are some of the biggest contributors to failed Agile practices.

Resolution

• Educate and train your executive, management, and delivery teams to adopt Agile the right way.
• Assess your current software development lifecycle (SDLC), culture, and environment to evaluate Agile fit and determine what changes need to be implemented.
• Conduct a structured evaluation of Agile to assess and recognize the benefits of Agile in your organization and teams.
• Develop an iterative approach to rolling out Agile within your organization to fail fast and recover quickly.

Info-Tech Insight

1. Agile is first and foremost a cultural shift. Culture is often the biggest challenge to Agile implementation. Don’t take this as a sign that Agile is failing. Instead, use it as a lesson to bring forward improvement opportunities.
2. The Agile mindset must be created at every level of the organization. A top-down approach to Agile implementations often leads to failure.
3. Don’t let your organization get carried away with the hype around Agile. The quantitative benefits of Agile are not realized by most organizations due to immature implementation and adoption of Agile principles and practices.

Agile’s four core values

We value. . .

“…while there is value in the items on the right, we value the items on the left more.” – Source: “The Agile Manifesto”

Agile is not just something organizations do…

Agile brings a complete fundamental shift in the way teams, project managers, and stakeholders traditionally plan and execute development projects.

“[‘Doing’ Agile is] just some rituals but without significant change to support the real agile approach as end-to-end, business integration, value focus, and team empowerment.” – Arie van Bennekum

Understand the importance of building a minimum viable product (MVP)

Most people compare Waterfall to Agile

"I believe in this concept, but the implementation described above is risky and invites failure." – Winston W. Royce

By delivering the product in smaller iterations, teams recognize value sooner and reduce accumulated risk. Both are realized as the iteration enters validation testing and release.

Source: “Managing the Development of Large Software Systems”

Recognize how Agile can minimize the risk accumulated and deliver value quicker

By delivering the product in smaller iterations, teams reduce the amount of risk that is accumulated over time, as they validate the accuracy with each iteration. The shaded area represents the risk mitigated by teams when they deliver with smaller iterations through Agile.

In an ideal world, teams could maximize effort expending to value received, which is represented as the green dotted line. With Agile, teams shorten the cycle and find more releases where they deliver earned value. The shaded area represents the value missed over time in a Waterfall world.

Understand the benefits provided by Agile and the requirements for successful implementation

The effectiveness of your delivery method will depend on how integrated you are with the business and how disciplined you are in the execution of the method.

Source: Ambysoft, “2018 Project Success Survey Results”

Evaluate how to get started with an Agile SDLC

Understand how to inject Agile into your SDLC in the short term

Info-Tech research shows that starting small with Agile in the context of a project or operations team is a key to success. A hybrid “WaterAgileFall” is the best place to start.

Extend iterations and Agile practices through as much of the project lifecycle as possible to maximize the value created

First, into plan and design.

And then, downstream into deploy and support.

Follow Info-Tech’s approach to learn and scale up Agile in your organization

Product Focused

Transition to Product Delivery

Build a Product Roadmap and Build a Better Backlog

Build a Better Product Owner

Delivery Focused

Implement Agile Practices That Work

Enable Organization-Wide Collaboration by Scaling Agile

Spread Best Practices With an Agile Center of Excellence

Development Focused

Structure Your DevOps Adoption Using a Metrics-Driven Approach

Make Development Teams Leaner and Improve Time-to-Release in Five Steps

Recognize how Agile fits into your organization whether you are a “product-based” or “project-based” shop

The Projects Within the Product

Regardless of whether you recognize yourself as a “product-based” or “project-based” shop, the same basic principles should apply. You go through a period or periods of project-like development to build a version of an application or product. You also have parallel services along with your project development, which encompass the more product-based view. These may range from basic support and maintenance to full-fledged strategy teams or services like sales and marketing. All apps can be considered products and all products have projects.

Not everything in “The Agile Manifesto” should be taken as gospel

Don’t take the manifesto too literally – it must align to the operations and workflow of your project teams and not increase the risk of project failure when unexpected situations occur. Therefore, recognize the redundancies, practices, and platitudes in the manifesto. There are five key principles that really matter and can’t be ignored.

PRINCIPLES OF THE AGILE MANIFESTO

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sources: “The Agile Manifesto”; Agile! The Good, the Hype and the Ugly

Speed of delivery and productivity remain top drivers for Agile adoption

Benefits of Adopting Agile

By implementing Agile, respondents cited seeing improvement in the following areas:

Adapted from: “12th Annual State of Agile Report"

The quantitative results of Agile are far from conclusive

Qualitatively

Every survey conducted by Agile consulting shops and tool vendors shows Agile feels more successful than traditional approaches.

"Based on the results of our recent agile quality study, expect agile software quality to exceed traditional method performance by a factor of from 6 to 12 percent in about three years."

– “Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings”

Quantitatively

The average Agile practice is no more productive than Waterfall.

"…some researchers argue that there is nothing new about agile methods…"

– “Empirical Studies of Agile Software Development: A Systematic Review”

"Agile isn’t necessarily better. Being involved in the process of throughput just feels better."

– “The 12 Stages Of The Agile Transformation Journey”

Info-Tech Insight

Don’t gauge the success of your Agile implementation based on speed and productivity alone. Prioritize the human benefits of a positive experience, trust, and resilience to become the partner your business needs you to be.

Why do organizations adopt Agile?

Traditional processes have their limitations

"Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization[s] embarking on their journeys to become agile."

– Stefan Wolpers, “Agile Failure Patterns in Organizations 2.0”

So where do the problems start?

"Most IT funding depends on one-time expenditures or capital-funding mechanisms that are based on building construction-funding models predicated on a life expectancy of 20 years or more. Such models don’t provide the stability or flexibility needed for modern IT investments."

– “Aligning IT Funding Models to the Pace of Technology Change”

How do you fund projects today?

These models require increasing accuracy throughout the project lifecycle to manage actuals vs estimates.

Poor estimation leads to downstream issues in projects

In Waterfall, we frequently see models where increasing accuracy is required throughout the project lifecycle to manage actuals vs estimates.

"The average rough order of magnitude estimate for software is off by up to 400%"

– “Software Project Estimation Practices at CodeTiburon”

The reality is software estimation is more of dark art than a science. There is more to it than just implementing or developing the software.

Lack of business or IT stakeholder participation significantly reduces the success of Agile downstream

78% of IT professionals believe the business is “usually” or “always” out of sync with project requirements.

Source: “10 Ways Requirements Can Sabotage Your Projects Right From the Start”

Communication with the business does not happen on a regular basis throughout the development cycle which leads to final product delivery that does not meet business and/or customer expectations. This leads to further rework to attempt to meet expectations with a subsequent slow down in time-to-market delivery.

There are several factors that affect the nature and impact of stakeholder participation. Cater your strategies to engage different stakeholders based on these factors:

Source: “Active Stakeholder Participation: An Agile Core Practice”

Change is inevitable when it comes to business agility

However, traditional delivery processes work on the assumption that product requirements will remain constant throughout the SDLC. This results in delayed delivery of product enhancements which are critical to maintaining a positive customer experience.

Regardless,

64% of IT professionals adopt Agile to enhance their ability to manage changing priorities.

Source: “12th Annual State of Agile Report”

71% of IT professionals found their ability to manage changing priorities actually improved after implementing Agile.

Source: “12th Annual State of Agile Report”

Info-Tech Insight

Agile is first and foremost a cultural shift by adopting the mindset of embracing change. Therefore, if you are successfully being Agile, your ability to manage changing priorities will be a natural by-product of being Agile.

Create a culture that fosters innovation

Since development approaches are usually finalized at the beginning of the release cycle, there is no room for innovation. Resourcing is typically established up front with little room to enhance teams to encourage experimentation and creative thinking by team members.

Explore the barriers to innovation at your organization, and aim to create an environment where your team members are encouraged to be innovators:

Freedom to explore

People have the freedom to explore ideas that might lead to better products and experiences.

Bias for “now”

Leaders have a bias for “now” over “perfect.” Can we get 50% of the way there for 5% of the cost?

Good failures

There is an environment for prototyping and appetite for “good failures.” Good failures mean fast, cheap, and low-impact.

Prototypes into production

Easy process for converting worthwhile prototypes into production solutions.

The reception and value of software products do not justify the money invested

A process that does not support frequent and iterative deployment of solutions often produces a product that lags behind industry competitors. The inability to release solutions quickly and frequently to elicit customer feedback usually results in products that are not industry leading or valuable to the end users.

Over $1,000,000,000,000 is spent on software every year.

38% of spend on IT employees goes to software roles.

Source: Info-Tech’s Staffing Survey

18% of OpEx is spent on software licenses.

Source: SoftwareReviews.com

33% of CapEx is spent on new software.

Source: Info-Tech’s Budgeting Survey

These problems lead to large-scale failures in the delivery of software.

Only 34% of software is rated as both important and effective by users.

Source: Info-Tech’s CIO Business Vision

The distribution for development, implementation, and maintenance of software is misunderstood

Source: “Does Code Decay? Assessing the Evidence from Change Management Data”

Info-Tech Insight

Every maintenance team develops new code, enhances existing applications, and maintains and fixes production systems. Governance, management, and the ability to measure delivery is required to make the informed decisions about what activities to invest in to drive value.

There are barriers to evaluating Agile successfully

Agile does not:

…solve development and communication issues.

…finish requirements faster.

…mean you do not need documentation.

We don’t recommend evaluating Agile in the following scenarios:

If people are not accountable for delivery.

If you already have a project in flight in a Waterfall procurement or contractual environment.

If a critical design review phase has already passed in a large-scale project and there is no chance of revisiting the design.

If all stakeholders can’t agree on adopting Agile practices to deliver their initiative.

If the project has a fixed scope.

If the project touches on highly sensitive, risky, mission-critical, or legacy systems.

Consider these key aspects on your Agile transformation journey

Organizations need to consider each aspect of Agile as they embark on every step of their transformation to avoid the challenges lack of discipline and integration can create for Agile practices.

Learning

Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.

Automation

While Agile is tool-agnostic at its roots, Agile work management tools and DevOps inspired SDLC tools that have become a key part of Agile practices.

Integrated Teams

While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.

Metrics and Governance

Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams.

Culture

Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.

Recognize the stakeholders that will influence and impact your Agile transformation

Understand how to move through your Agile transformation journey with Info-Tech’s research

Use Info-Tech’s approach to kick start your transformation to Agile with facilitated learning and structured evaluation

Phase 1 – Facilitate Agile Learning

• A training module targeted at executives and management at an organization that will lead and manage an Agile transformation.
• A training module targeted at members on a delivery team that will be executing a structured evaluation of Agile in the form of a pilot initiative.

Phase 2 – Assess Current State

• Assess your team and organization’s readiness for Agile by evaluating and identifying business drivers, culture, and SWOT.
• Evaluate your current state SDLC process to uncover gaps and opportunities and understand how Agile will shift the current way of working.

Phase 3 – Execute Your Structured Evaluation

• Understand the baseline scrum process.
• Develop a stakeholder management plan to engage the right stakeholder to embark on your Agile journey with you.
• Evaluate and select the right pilot for Agile.
• Simulate scrum practices to adopt for your pilot.

Fortune 50 Technology case study

Case Study

Industry: Technology

Source: Info-Tech Research Group

The Challenge:

The member realized that the corporation needed to improve its agility, time to market, and ability to adapt to change to continue its growth. The company’s products and services were increasingly including a technology component and the need to deliver solutions sooner. In addition, the member wanted to make the company a more attractive place to work for new employees and the companies it acquired.

The Solution:

The member worked with Info-Tech to develop a comprehensive set of support and services to guide its Agile transformation.

• Executive leadership one-day workshop followed by four day-long pilot team workshops on Agile.
• Dedicated consulting and team coaching to ensure success.
• Development of an online academy with end-user certifications.

The Results:

• Executive leadership identified cultural and process barriers to improved agility and developed a roadmap to support the transformation.
• Agile team coaching helped establish a common baseline for Agile and hybrid methodologies.
• Workshops were completed internationally in four locations, training over 80 participants.
• The member is developing Agile methodologies and funding models to support different project needs and business units.

The member’s Agile transformation followed Info-Tech’s methodology.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks are used throughout all four options.

Implement Agile Practices That Work – project overview

Workshop overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Facilitate Agile Learning

Phase 1 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Step 1.1: Lead and Manage Agile

This step will walk you through the following activities:

• Facilitate learning for your organization’s executives and management.
• Agile practices and principles.
• Baseline Agile practices.
• Key tools that support Agile practices that work.

This step involves the following participants:

• CXOs
• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Build knowledge and support for Agile practices across different layers of your organization.
• Build knowledge of Agile practices and concepts across the executive and management teams to drive the change.
• Educate and support Agile teams to ensure successful adoption of Agile practices.
• Standardize your organization's understanding of what it means to “be Agile.”

Begin with facilitating Agile learning for leaders at your organization

Lead and Manage Agile

Phase 1.1 of this blueprint

• Participants: Executives and management.
• Purpose: Build knowledge of Agile practices and concepts across the executive and management teams to drive the change.
• Info-Tech Engagement: One-day executive introduction and coaching.

Evaluate Agile

Phase 1.2 to 3 of this blueprint

• Participants: Agile team members.
• Purpose: Educate and support Agile teams to ensure successful adoption of Agile practices.
• Info-Tech Engagement: Four-day on-site facilitated learning. Ongoing Agile coaching.

Info-Tech Insight

Create the Agile mindset at every layer of your organization. The move to Agile can’t be a top-down decision; it must be a journey to changing the cultural and governance structure from the bottom up. The first step on the educational journey to introducing Agile is starting with the big picture and answering the question: “What’s in it for me?”

Achieve your goals to lead and manage Agile with these key aspects to ensure success

Comparing Waterfall and Agile Delivery: Explore the origin and myths of Waterfall methods and the reasons behind the rise of Agile.

Decoding Agile: Principles, Terminology, and Roles: Introduce and decode the Agile principles, terminology unique to Agile, and the roles it has introduced.

Product Owners and Product Agility: Move beyond project-based Agile and understand the benefits and challenges of product agility.

Enterprise Agility and the Value of Change: Introduce enterprise agility and the integration of business and IT around products and services.

Lead, Manage, and Govern Agile Teams: Identify the behaviors that leaders and managers need to embrace to help people become Agile.

Define Your Agile Principles: Define the principles you need as leaders and managers to make Agile successful in your organization.

Commit to Agile: Drive personal commitment to the principles to ensure the leaders and managers become Champions of Agile for your organization.

Exercise: What is driving your organization to become Agile? Complete your personal Agile story card

1.1.1

Estimated Time: 15 to 30 minutes

1. Individuals: Complete your personal Agile story card.
2. Small group (12 or fewer participants):
   • Share your personal Agile story card with the facilitator and other participants.
3. Large group (more than 12 participants):
   • Table groups: Share your personal Agile story card with the other participants at your table.
   • Identify three (3-4 table groups), two (5-6 table groups), or one (7+ table groups) priority stories.
   • Share your priority stories with the facilitator and other participants.

Input

• Personal expectations from participants

Output

• A checklist of key topics to cover or schedule for future discussion

Materials

• Agile story card
• Pen
• Flip chart or whiteboard

Participants

• All

Explore the origin and myths of Waterfall methods and the reasons behind the rise of Agile

Where did Waterfall come from?

Managing the development of large software systems

• Dr. W. R. Royce
• IEEE WesCon 1970

W. R. Royce was a:

• Rocket scientist
• Project manager
• Pioneer

Source: “Managing the Development of Large Software Systems”

What did Royce really say about Waterfall?

Most people compare Waterfall to Agile

Dr. Winston W. Royce first introduced the Waterfall process back in 1970. However, he noted:

"I believe in this concept, but the implementation described above is risky and invites failure."

Royce’s 5 Principles for Success

1. Complete program design first.
2. Keep documentation current and complete.
3. Iterate within each phase, often repeatedly.
4. Plan, control, and monitor testing throughout.
5. Involve the customer formally, in-depth, and continually.

Source: “Managing the Development of Large Software Systems”

Understand how things will change in an Agile world

Source: “Empirical Studies of Agile Software Development: A Systematic Review”

Exercise: How is building and implementing software different from construction?

1.1.2

Estimated Time: 15 minutes

1. Individuals: Write down up to three ways that building and implementing software is different from building construction.
2. Small group (12 or fewer participants):
   • Share a key example with the facilitator and other participants.
3. Large group (more than 12 participants):
   • Table groups: Share your list with the people at your table and identify one item that creates challenges when you deliver today.
   • Table groups: Nominate one member of the table to share one or two key items you identified as a group.

Input

• Personal knowledge of software delivery and your organization

Output

• Key differences that might create challenges today

Materials

• Pen and paper
• Whiteboard or flip chart

Participants

• All

Construction vs software

So where do the problems start?

"Most IT funding depends on one-time expenditures or capital-funding mechanisms that are based on building construction-funding models predicated on a life expectancy of 20 years or more. Such models don’t provide the stability or flexibility needed for modern IT investments."

– “Aligning IT Funding Models to the Pace of Technology Change”

How do you fund projects today?

These models require increasing accuracy throughout the project lifecycle to manage actuals vs estimates.

Poor estimation leads to downstream issues in projects

In Waterfall, we frequently see models where increasing accuracy is required throughout the project lifecycle to manage actuals vs estimates.

"The average rough order of magnitude estimate for software is off by up to 400%"

– “Software Project Estimation Practices at CodeTiburon”

The reality is software estimation is more of dark art than a science. There is more to it than just implementing or developing the software.

The distribution for development, implementation, and maintenance of software is misunderstood

While the exact balance point between development or implementation costs varies from application to application, on the whole, well over half of the cost of a piece of software is realized after it is in production.

Info-Tech Best Practice

Funding models that support innovation, learning, and continuous improvement drive better estimates and outcomes.

The Lean Enterprise Funding Model is an example of a different approach

A flexible funding pool akin to venture capital models is maintained to support innovative ideas and fund proofs of concept for product and process improvements.

Every product line has funding for all changes and ongoing operations and support. POCs are run by standing innovation teams or a reserve of resources not committed to existing products, projects, or services.

Teams are funded continuously so that they can learn and improve their practices as much as possible.

Consider how budgeting will differ in an Agile environment

Info-Tech Insight

Traditional budgets place the focus on “cost centers,” whereas Agile budgets account for “value streams.” The values streams are based around projects which may span cost centers.

Why do organizations adopt Agile?

Traditional processes have their limitations

"Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization[s] embarking on their journeys to become agile."

– Stefan Wolpers, “Agile Failure Patterns in Organizations 2.0"

Explore the origin and myths of Waterfall methods and the reasons behind the rise of Agile

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

That is, while there is value in the items on the right, we value the items on the left more.

Source: “The Agile Manifesto”

“The Agile Manifesto” minus the redundancy, practices, and platitudes

Don’t take the manifesto too literally – it must align to the operations and workflow of your project teams and not increase the risk of project failure when unexpected situations occur. There are, however, five principles that cannot be ignored.

PRINCIPLES OF THE AGILE MANIFESTO

1. Our highest priority is to satisfy the customer through early and continuous delivery of value software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Business people and developers must work together daily throughout the project.
4. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
5. The best architectures, requirements, and designs emerge from self-organizing teams.

Sources: “The Agile Manifesto”; Agile! The Good, the Hype and the Ugly

Embrace Agile to achieve greater business alignment and effectively react to change in requirements

Learning

Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.

Automation

While Agile is tool-agnostic at its roots, Agile work management tools and DevOps inspired SDLC tools that have become a key part of Agile practices.

Integrated Teams

While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.

Metrics and Governance

Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams

Culture

Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.

Adopting Agile is not risk free

“One of the largest sources of failure we have seen on large projects is an immature agile implementation in the context of poorly defined requirements.”

– “Large Scale IT Projects – From Nightmare to Value Creation”

“Requirements maturity is more important to project outcomes than methodology.”

– “Business Analysis Benchmark: Full Report”

“Mature Agile practices spend 28% of their time on analysis and design.”

– “Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings”

Requirements analysis, design maturity, and management are critical for a successful Agile transformation.

So which services really matter?

Business leaders misjudge which services really matter to them.

KEY FINDINGS:

• Apart from the applications themselves they underrate the key factors that lead to success.
• Business product ownership remains key.
• Technical product owners, architects, and business/systems analysts are critical.
• Where they lack the project and requirements skills they can be supplemented with an IT-based project management.

Info-Tech Insight

Rethink your priorities; invest in services with the highest return on IT satisfaction. Projects, work orders, and innovation leadership drive IT satisfaction.

Info-Tech Business Vision Survey, N=21,367

Accommodate the transition from a traditional to an Agile mindset

Agile brings a complete fundamental shift in the way teams, project managers, and stakeholders traditionally plan and execute development projects.

• With Waterfall, development teams are expected to complete a project with a fixed scope, which is used to estimate a fixed budget by an established deadline. However, teams are commonly unable to meet these commitments due to unexpected changes and complexities. Deadlines are not met and are frequently pushed off, and time often becomes variable.
• With Agile, time is bounded (i.e. iterations) and the scope is constantly adjusted to ensure a product is valuable, successful, and delivered by the fixed deadline. A completed Agile product may contain a smaller scope compared to Waterfall, but the committed user stories are stable and valuable to the stakeholder.

Be aware of common myths around Agile

Agile does NOT:

…solve development and communication issues.

…ensure you will finish requirements faster.

…mean you will not require documentation.

"Although Agile methods are increasingly being adopted in globally distributed settings, there is no panacea for success."

– “Negotiating Common Ground in Distributed Agile Development: A Case Study Perspective.”

"Without proper planning, organizations can start throwing more resources at the work which spirals into the classic Waterfall issues of managing by schedule."

– Kristen Morton, Associate Implementation Architect, OneShield Inc., Info-Tech Interview

Consider the other key observations made by Info-Tech’s research

1. Culture is the biggest challenge to Agile implementation.
2. Hybrid development methodologies can be a better fit than pure Agile.
3. Don’t let your organization get carried away with success.

Start with a baseline scrum implementation

Use scrum as a starting point for your Agile implementation because of its popularity and community support.

Why start with scrum?

Simplicity: Scrum philosophies and methodologies are straightforward, prescriptive, and the available resources to aid in implementation are widely available.

Flexibility: Scrum makes an ideal foundation to build a personalized Agile process strategy. Technical Agile techniques, such as pair programming and continuous integration, can easily be injected.

Success: Scrum has had a lot of success with confronting changes in requirements, increasing collaboration and communication within teams, and improving the transparency with stakeholders.

Be aware of the limitations of scrum:

• Business risk: Scrum cannot not rescue a product’s development if the business does not have a clear sense of its direction.
• Resolution agnostic: Scrum exposes impediments and issues but does not offer insights on how to solve the problems.
• Redefinition of roles: Scrum can change the roles and responsibilities of the existing project team considerably.

Info-Tech Insight

• Use well-known, by-the-book, scrum processes and artifacts to ease the rollout of your initial pilot. Gradually modify these processes and artifacts to better fit your context as you gain more experience.
• It may be necessary to bring in an Agile coach to help provide training.
• There are no designated project managers, but leaders are still needed to challenge the team to improve.

Understand the scrum process

The scrum process coordinates multiple stakeholders to deliver on business priorities.

Note: Functional requirements, which make up your product and sprint backlogs, are typically written as short user stories. Additional details are added to these user stories once they are “ready” and prioritized for immediate development.

Establish scrum roles and responsibilities

See how traditional development roles translate to those in scrum

Development roles may shift when transitioning to scrum but the value of each role will remain the same.

Info-Tech Insight

• Be aware of conflicting interests – Without the right training, traditional roles (e.g. business analysts and projects manager) may continue to bring traditional thinking and priorities to your pilot project. This can counteract the goals you hope to achieve and conflict with your development guidelines.
• Rotate Scrum Masters – Scrum masters can be anyone, as long as they have a deep understanding of the dynamics in development and a strong grasp of Agile and scrum concepts.
• Keep the team size to 5-9 members – This size helps ease task coordination and collaboration among team members. Separate teams can be created to support the development team (e.g. security, architects), but they must be actively communicating with the development team and collaborating in key scrum activities.

Exercise: What’s my team’s Agile role?

1.1.3

Estimated Time: 15 minutes

1. Individuals: Map out your team’s current role and the role that seems like best fit on a notepad:
   • E.g. stakeholder, product owner, scrum master, team member.
   • Include what your key responsibilities in each role might be.
   • Identify what you see as the key differences between your team’s current role and their potential Agile role.
2. Large group (12+ Participants):
   • Take turns discussing your observations and key differences.
   • Note any themes that arise at your table.
3. Small group (<12 Participants):
   • Share key themes.

Input

• Your knowledge of your current role
• Today’s discussion

Output

• A greater understanding of your role in Agile

Materials

• Notepad

Participants

• All

Understand the role of product owners in your Agile transformation

"Scrum introduced one of the relatively few brilliant ideas in Agile, the product owner."

– Bertrand Meyer, Agile! The Good, the Hype, and the Ugly

Understand the differences between a project-centric and a product-centric organization

Product delivery requires significant shifts in the way you complete development work and deliver value to your stakeholders. Make the changes that make sense.

Learn the importance of the product owner role

As described in the “Scrum Guide,” a scrum product owner is responsible for maximizing the value of the product resulting from the work of the development team. How this is done may vary widely across organizations, scrum teams, and individuals.

The product owner is the sole person responsible for managing the product backlog. Product backlog management includes:

• Communicating product backlog items (PBIs).
• Ordering the items in the product backlog to best achieve goals and missions.
• Optimizing the value of the work the development team performs.
• Ensuring that the product backlog is visible, transparent, and clear to all, and shows what the scrum team will work on next.
• Ensuring the development team understands items in the product backlog to the level needed.
• Remaining accountable, even though the product owner can have the development team do the above work.

The product owner is one person, not a committee. The product owner may represent the desires of a committee in the product backlog, but those wanting to change a product backlog item’s priority must address the product owner.

Source: “What Is a Product Owner?”

Info-Tech Insight

For the product owner to succeed, the entire organization must respect their decisions. The product owner’s decisions are visible in the content and ordering of the product backlog. No one is allowed to tell the development team to work from a different set of requirements, and the development team isn’t allowed to act on what anyone else says.

Product owners and managers facilitate effective decision making and coordination with delivery teams

Product delivery requires the centralized coordination among all roles and of all product decisions, and an open channel to allow communication with stakeholders or their proxies. Without proper ownership, your delivery teams may not be able to effectively align valuable product releases with corporate strategies, leading to dissatisfied stakeholders. Two roles have emerged to take on product ownership: product managers and product owners. Despite the lack of an industry standard on these role definitions, many organizations agree that:

• Product managers own the product’s strategic planning, roadmap, and value management.
• Product owners coordinate delivery and support with technical teams by owning the tactical planning and roadmap.

You may not have a need to have separate product owner and manager roles. However, their responsibilities, accountabilities, and capabilities must be accommodated in another suitable role.

General Responsibilities of Product Owners and Managers

Product Manager (Strategic Focus)

• Understanding market problems/opportunities
• New product innovation/definition
• Product vision and product roadmap
• Release timing and focus (i.e. release themes)
• Release requirements
• Coordination with engineering during development cycle
• Product strategy, positioning, and messaging
• Defining pricing and licensing
• Managing internal/external release enablement
• Ongoing optimization of product-related marketing/sales activities
• Competitive analysis and positioning
• Win/Loss analysis
• Cross-functional communication across product lifecycle

Product Owner (Tactical Focus)

• Overall backlog management: backlog refinement and prioritization
• Epic/Story definition, refinement in conjunction with business stakeholders
• Sprint planning along with scrum master and other stakeholders
• Facilitating problem resolution related to sprint/story implementation
• Working with scrum team members to minimize disruption to scrum team velocity
• Ensuring alignment between business and scrum team during development cycle (e.g. sprints)

Source: “Let’s End the Confusion: A Product Owner is NOT a Product Manager”

Explore which existing roles would transition smoothly to a product owner and manager

Product owners and managers facilitate discussions between the business and IT. Given the importance and visibility of these roles, they require a diverse and intimate knowledge of business relationships and corporate products and have an experienced skill set. Look for prospects and opportunities to create partnerships within your organization before hiring new product owners.

Source: “Where Do Product Owners Come From?”

Product roadmaps are key to Agile delivery

Delivering a valuable product is a “multi-faceted, complex discipline that can be difficult to grasp and hard to master.” It will take time to learn, adopt, and become a competent product manager or owner. Take a strategic approach to develop your product delivery and management capabilities.

Source: “What Is Product Management?”

Adapted from: “What Is Product Management?”

Roadmaps tie together the value chain from idea to the delivered solution

Info-Tech Insight

Two practices are required to manage the delivery of your product roadmap:

1. Do not relate the estimates of the different artifact types and the artifacts used across teams. Use velocity to drive forecasts and continuous improvement of your teams.
2. Use an abstract measure of size and complexity such as user story points, function points, and story points to allow you to measure your delivery velocity.

Long-term and detailed planning can be both valuable and wasteful depending on your circumstances

In an ideal scenario, a roadmap that illustrates detailed, committed, and long-term plans can be immensely valuable by allowing you to align your teams and stakeholders and to increase your ability to meet project costs, required skills, and delivery dates.

In reality, things change. Your strategic intentions are subject to volatility, especially those planned within a further timeline. The more costs you incur in planning, the more you leave yourself exposed to inefficiency and waste if those plans change.

This is the fundamental problem true product roadmaps are designed to solve; they build in flexibility to handle change. However, volatility isn’t a given, and either are lengthy timelines. These will range from app to app or product to product. You will need to do some analysis to know the best approach that will garner the most value.

The real question is, how flexible do you need to be?

Backlogs illustrate the current requirements whereas roadmaps structure delivery

“The When”: Showcase when you can deliver and your progress leading up to delivery

Milestones

Milestones are points in the timeline when an established set of artifacts are complete. They are typically assigned a date and used to show the progress of development.

Release Dates

Releases mark the actual delivery of a set of artifacts packaged together in a new version of the product. Release dates, firm or not, allow stakeholders to anticipate when it is coming.

Info-Tech Best Practice

Some roadmaps will go even further and include an element visualizing their sprint cycles. This is typically only recommended when you are building a more tactical roadmap. In most cases keeping the roadmap above the sprint level is the ideal approach.

Consider other types of milestones or key markers

Learning Milestones

A completion of a set of artifacts dedicated to validating business opportunities and hypothesis. These tasks are outside of development teams and focus on market research. These can occur early on, prior to development, to establish your product strategy, or after an MVP is released to assess user acceptance.

Benefits

• Aligns teams on product strategy prior to build.
• Dedicates time for market research.
• Obtains user feedback early.
• Provides information on feature requirements.

Sprint Zero

The completion of a set of key planning activities typically before the first sprint. The artifacts help establish the architectural runway (key plans regarding hardware and infrastructure considerations). Also, scrum teams are established and assembled. This should occur prior to development and can extend into the first few sprints.

Benefits

• Establishes teams.
• Establishes key plans.

Go-to-Market Strategy

The completion of your plan to deliver or sell your product. This is a key responsibility of your product teams and a key aspect of your product strategy. This occurs after development is underway, but with sufficient time prior to the initial release.

Benefits

• Provides information for adjusting other milestones or deadlines.
• Provides other information for development artifacts.

Understand the importance of using milestones

Why use milestones when I have sprints?

Sprints are time-boxed development iterations, consistent in length. Like milestones, they are useful for managing development, tracking throughput, and focusing on business value. But they typically don’t represent a complete collection of artifacts meaningful to the business or another specific stakeholder.

Why use milestones when I have releases?

Releases are the actual instance of delivering something to the customer. Like milestones, they are useful for tracking the progress of a larger body of work. But they don’t indicate meaningful achievements that aren’t in the form of a customer deliverable.

Benefits

• Gauge the rate of delivery. They are visible indicators of progress.
• Trigger corrective action when delivery is off pace.
• Mark the beginning or end of a significant phase of work.
• Use for resourcing purposes (i.e. specific skilled individuals are no longer necessary).
• Mark important points for sequencing different types of artifacts.

Fixed Time vs. Fixed Feature-Based Milestones

Fixed-Time Milestone: When the established set of artifacts are delivered at a set date. Typically, some artifacts or features can be treated as independent variables. This is more commonly used when time sensitivity is high.

Fixed Feature: When the milestone is only achieved when the established artifacts are complete. Time is treated as the independent variable. This is more commonly used when innovation is a priority, and a strong degree of autonomy and trust is granted to development teams (the appropriate culture is a prerequisite).

Flexible Milestones: Choosing purely one or the other is not ideal. Estimated throughput speed can be an unpredictable factor. Setting fixed dates can force teams to sacrifice quality and fail to deliver on the full promise of a milestone. Conversely, not setting dates at all will virtually guarantee delays in delivery. Set dates and collection of features as targets and adjust, reprioritize, and communicate with the business as you develop.

Source: “Using Milestones in Project Management”

Understand how the product-based view applies to project-based delivery and vice versa

The Projects Within the Product

Regardless of whether you recognize yourself as a “product-based” or “project-based” shop, the same basic principles should apply. You go through a period or periods of project-like development to build a version of an application or product. You also have parallel services along with your project development, which encompass the more product-based view. These may range from basic support and maintenance to full-fledged strategy teams or services like sales and marketing. All apps can be considered products and all products have projects.

Including MVPs in your roadmap is the key to product success

The Build-Measure-Learn Loop suggests development should perpetually take an idea and develop, test, and validate, so it can then expand on the product using the lessons learned and evolving ideas. In this sense the MVP is just the first product in the loop.

Having your MVP represented by a milestone (or any of the components of this model for that matter) helps teams, the business, and customers know the important moments of development.

Minimum Marketable Product (MMP) – Extends this idea past a learning vehicle to the minimum product that is “market ready.”

Minimum Marketable Features (MMF) – Is a similar concept, where market ready features are added to a product.

Exercise: How to support a product owner

1.1.4

Estimated Time: 20 minutes

• Individuals: Identify one to three things you need to do to support product owners on the large sticky notes (one thing per sticky).
• Take turns sharing your observations and determine the three most critical items.
• Take turns sharing your most critical items.

Input

• Today’s discussion

Output

• Clearer understanding of the needs of product owners

Materials

• Sticky notes and markers

Participants

• All

Recognize the value of change through enterprise agility

Technology has become part of the lifeblood of an organization. There is no such thing as a business process that is not enabled by technology or supports the delivery of technology.

There is no such thing as an IT project.

Ultimately, our goal must be to create exceptional customer service focused on early and continuous delivery of value to our customers. That value is defined by exceptional customer experiences with our products and services.

Many vendors claim to know the right way to deliver valuable business solutions

*Framework image source: “DevOps and User Experience at Concur”

What does it take to create exceptional customer experiences with your products and services?

Differentiate

Organize

Partner

Perspective

Get a clear picture of how your products and services drive customer and business value

Business value definitions must come from the business, not IT. They are the keepers of the organization’s mission, vision, or mandates. Make the business the authority on value, then form a partnership that defines that value in the context of your products. Outline the business value sources that define the success criteria of your products and services. Note that these drivers should tie back to your holistic business strategy. Business value is divided into four categories.

• Profit Generation – The revenue generated from a product or business capability.
• Cost Reduction – The below-the-line, operational cost savings by executing business capabilities with a product.
• Service Enablement – The productivity and efficiency gains of internal business operations from enhanced products and capabilities.
• Customer and Market Reach – Metrics measuring the improved reach and insights of the business in existing or new markets.

Exercise: Identify your business value sources

1.1.5

Estimated Time: 1 hour

1. Put on the hats of your product, IT, and business stakeholders. These individuals are the critical strategic partners in the organization’s governing bodies.
2. Using a flip chart, draw the 2x2 Business Value Matrix.
3. Brainstorm the different types of business value that you produce on the sticky notes (one item per sticky). Draw from examples of products in your portfolio.
4. Winnow down to the most important value items for your organization (two to three per quadrant).

Input

• Understanding of stakeholder priorities and sources of value

Output

• Business value sources from products across all areas of organization

Materials

• Flip charts
• Markers
• Sticky notes

Participants

• All

Lead, manage, and govern Agile teams successfully

Ten Agile Axioms That Make Managers Anxious:

The Law of the Customer

1. Firms make more money by not focusing on making money.
2. There are no internal customers.
3. There are no B2B corporations.
4. Better products often make no money.

The Law of the Small Team

5. Forget economies of scale: your market is one person.
6. Don’t scale up: descale complexity down.
7. Agile is not a process.
8. Talent drives strategy, not vice versa.

The Law of the Network

9. Control is enhanced by letting go of control.
10. Lead like a gardener, not a commander.

Source: “Ten Agile Axioms That Make Managers Anxious”

Increase success by involving IT, the business, and customers in your product and service roadmaps, planning, and delivery

Product and service management and delivery improves relationships among IT, the business, and customers, driving business satisfaction and customer value.

Collaboration

IT, the business, and customers working together through all stages of the product lifecycle, from market research through the roadmapping and delivery processes and into maintenance and retirement. The goal is to ensure the risks and dependencies are realized before work is committed.

Communication

Prioritizing high-value modes of communication to break down existing silos and create common understanding and alignment across functions. This approach increases transparency and visibility across the entire product lifecycle.

Integration

Explore methods to integrate the workflows, decision making and toolsets among the business, IT, and customers. The goal is to become more reactive to changes in business and customer expectations and more proactive to market trends.

Ensure long-term Agile rollout success with management support

Changing to Agile can be perceived by management as a loss of control. Help them understand the benefits of improved communication, responsiveness, and cost containment.

Management Team With Agile

Provide Constant Support

Rather than dictating timelines and scope, management will now support the team by helping to prioritize scope and resolving conflicting requirements amongst themselves.

Take a Hands-Off Approach

Once the scope is determined for a given iteration, management will not inject new requirements until the current work is complete.

Be a Catalyst for Change

Management should encourage the move toward Agile as a means of increasing development transparency.

Info-Tech Insight

Do not underestimate political influences that can interfere with Agile implementations. Resource shifting late in the pilot, for example, can derail an attempt at rolling out Agile. You will need upper management governance support to resolve such issues.

Governance should focus on risk and value delivery

Disentangle governance and management

Governance bodies will focus on setting the direction, investment mix, and prioritization for IT in line with the organizational goals. Once the direction has been defined the governance bodies will manage escalated exceptions and monitor performance against goals.

Risk-based governance

In order to remain Agile, governance thresholds/ involvement needs to be determined based on the risk to the organization. IT Leadership will need to be empowered to make decisions within the defined risk thresholds and work collaboratively to drive success.

Govern at milestones

The governance bodies should align responsibilities and agendas with key strategic decisions and milestones and not be involved in the day-to-day management of how work is executed.

Measure the team to drive improvement

Measuring and reporting on the performance of IT will be critical in building trust in the new model and in identifying improvement opportunities. Governance bodies will all have an element of performance measurement to drive continuous improvement.

Enforce principles and standards

To drive organizational success, it’s critical that the IT governance bodies have a strong focus on driving discipline and monitor adherence to principles and standards.

Exercise: Part 1 – How Agile is your leadership and management culture?

1.1.6

Estimated Time: 30 minutes

1. Individuals: Identify three to five current aspects of management and leadership culture in your organization.
2. As a group, map them to quadrants.
3. Debrief the quadrants as enablers/barriers to Agile success.

Input

• Today’s discussion

Output

• Clearer understanding of the organization’s culture and barriers to implementing change

Materials

• Sticky notes and markers

Participants

• All

Exercise: Part 2 – Map and discuss

1.1.6

Estimated Time: 30 minutes

4. Identify potential actions to shift barriers.

Input

• Today’s discussion

Output

• Clearer understanding of the organization’s culture and barriers to implementing change

Materials

• Sticky notes and markers

Participants

• All

Define your Agile principles

Agile’s four core values

We value . . .

“...while there is value in the items on the right, we value the items on the left more.” – Source: “The Agile Manifesto”

Agile is not just something organizations do….

Agile brings a complete fundamental shift in the way teams, project managers, and stakeholders traditionally plan and execute development projects.

“[‘Doing’ Agile is] just some rituals but without significant change to support the real agile approach as end-to-end, business integration, value focus, and team empowerment.”

– Arie van Bennekum

Not everything in “The Agile Manifesto” should be taken as gospel

Don’t take the manifesto too literally – it must align to the operations and workflow of your project teams and not increase the risk of project failure when unexpected situations occur. Therefore, recognize the redundancies, practices, and platitudes in the manifesto. There are five key principles that really matter and can’t be ignored.

PRINCIPLES OF THE AGILE MANIFESTO

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sources: “The Agile Manifesto”; Agile! The Good, the Hype and the Ugly

Exercise: Principles for Agile success

1.1.7

Estimated Time: 30 to 40 minutes

1. Principles for Success: Name and Description
   • Individually list one to three things that will be critical for leaders and managers to drive the success of Agile in your organization.
   • Take turns sharing your items with the table group.
   • As a team identify the most critical item you’ve discussed.
   • Write a short name (three to five words) for the item on your flip chart.
   • Come up with a short description for the item (one sentence).
   • Present your name and description to the table.
2. Rationale
   • As a group discuss the reason this principle will drive success.
   • Document key points.
3. Impact
   • As a group discuss the impact this principle will have on the organization.
   • Document key points.
4. Present
   • A volunteer from each table will present their principle.

Input

• Your knowledge of the organization
• Today’s discussion

Output

• Principles for success

Materials

• Flip charts
• Markers
• Sticky notes

Participants

• All

Commit to Agile

There is no such thing as painless change.

"Like driving a car with a standard transmission for the first time, changing a hardwired organizational habit can be nerve-wracking"

– “The Neuroscience of Leadership”

Ensure Focus

People must be able to focus on the new behaviors to make them patterns.

Understand Expectations

People need to shape their own expectations to make the change.

Develop Practice

Individuals must commit to and repeat practices that will make the change stick.

Step 1.2: Implement Agile

This step will walk you through the following activities:

• Facilitate Agile learning for your delivery teams.
• Agile practices and principles.
• Baseline Agile practices.
• Identifying and choosing the right candidate for an Agile pilot.
• Scrum simulation.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Build knowledge and understanding for Agile practices across the organization’s application delivery teams.
• Standardize your organization's understanding of what it means to “be Agile.”
• Determine your organization’s current environment and appetite for adopting Agile.
• Simulate the baseline scrum methodology to further educate teams to successfully adopting Agile practices.

Follow the rest of this blueprint for a structured curriculum to facilitate learning within Agile team members

Lead and Manage Agile

Phase 1.1 of this blueprint

Participants

Executives and management.

Purpose

Build knowledge of Agile practices and concepts across the executive and management teams to drive the change.

Info-Tech Engagement

One-day executive introduction and coaching.

Implement Agile

Phase 1.2 to 3 of this blueprint

Participants

Agile team members.

Purpose

Educate and support Agile teams to ensure successful adoption of Agile practices.

Info-Tech Engagement

Four-day on-site facilitated learning. Ongoing Agile coaching.

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

Determine your team’s Agile roles

This activity involves the organization’s leaders to identify and map out how the roles and responsibilities of their existing team will align to the Agile environment. This enables understanding of how roles and responsibilities shift and evolve to fit an Agile delivery model.

Identify your business value sources

This activity involves business and IT stakeholders to identify how the organization’s products and services drive customer and business value. It enables an understanding of enterprise agility and the value of change that is brought by Agile practices.

Phase 2

Assess Current State

Phase 2 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Step 2.1: Assess and Prepare Your Teams

This step will walk you through the following activities:

• Examining your team and organization’s culture and how they impact adopting Agile practices.
• SWOT analysis.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• A completed culture assessment to determine the readiness and fit for adopting Agile.
• A completed SWOT analysis to identify and determine strengths, weaknesses, opportunities, and threats to adopting Agile.

Determine your gaps before implementing Agile to ensure success

Make sure your organization is ready to make the transition.

Learning

Agile is a radical change in how people work and think. Structured, facilitated learning is required throughout the transformation to help leaders and practitioners go from doing Agile to being Agile.

Automation

While Agile is tool-agnostic at its roots, Agile work management tools and DevOps inspired SDLC tools that have become a key part of Agile practices.

Integrated Teams

While temporary project teams can get some benefits from Agile, standing, self-organizing teams that cross business, delivery, and operations are essential to gain the full benefits of Agile.

Metrics and Governance

Successful Agile implementations require the disciplined use of delivery and operations metrics that support governance focused on developing better teams.

Culture

Agile teams believe that value is best created by standing, self-organizing cross-functional teams who deliver sustainably in frequent, short increments supported by leaders who coach them through challenges.

Info-Tech Insight

Agile gaps may only have a short-term, perceived benefit. For example, coding without a team mindset can allow for maximum speed to market for a seasoned developer. Post-deployment maintenance initiatives, however, often lock the single developer as no one else understands the rationale for the decisions that were made.

Achieve team cohesion for a successful Agile transformation

Ensure inner-team communication and a high degree of trust.

Communication

Teams must have some type of communication strategy. This can be broken into:

• Regularity: Having a set time each day to communicate progress and a set day to conduct retrospectives.
• Ceremonies: Injecting awards and continually emphasizing delivery of value can encourage relationship building and constructive motivation.
• Escalation: Voicing any concerns and having someone responsible for addressing those concerns.

Proximity

Escalation: Voicing any concerns and having someone responsible for addressing those concerns.

• Location: Placing teams in close proximity can close the barrier of geographical distance and time zone differences.
• Inclusion: Making a deliberate attempt to pull remote team members into discussions and ceremonies.
• Communication Tools: Having the right technology (e.g. video conference) can help bring teams closer together virtually.

Trust

Members should trust other members are contributing to the project and completing their required tasks on time. Trust can be developed and maintained by:

• Accountability: Having frequent quality reviews and feedback sessions. As work becomes more transparent, people become more accountable.
• Role clarity: Having a clear definition of what everyone’s role is.

Info-Tech Insight

When selecting a team for a pilot project, include individuals with both high skill and high integrity. These leaders help keep the lines of communication open between team members and build trust.

Sufficient decision-making power should be given to your Agile teams

Push the decision-making process down to your pilot teams.

Bring your business stakeholders and subject matter experts together to identify the potential high-level risks.

Discuss with the business the level of risk they are willing to accept.

Define the level of authority project teams have in making critical decisions.

"Push the decision making down as far as possible, down to the point where sprint teams completely coordinate all the integration, development, and design. What I push up the management chain is risk taking. [Management] decides what level of risk they are willing to take and [they] demonstrate that by the amount of decision making you push down."

– Senior Manager, Canadian P&C Insurance Company, Info-Tech Interview

Get stakeholders and managers on board with the Agile team

• Stakeholder feedback and management support are key components of a successful Agile pilot.
• Stakeholders can see a project’s progression and provide critical feedback about its success at critical milestones.
• Management helps teams succeed by trusting them to complete projects with business value at top of mind and by removing impediments that are inhibiting their productivity.
• Agile will bring a new mindset and significant amounts of people, process, and technology changes that stakeholders and management may not be accustomed to. Working through these issues in a pilot enables a smoother rollout after the pilot.
• The value of leadership involvement has not changed even though responsibilities will. The day-to-day involvement in projects will change but continual feedback will ultimately dictate the success or failure of a project.
• Management will play a key role in ensuring long-term Agile success and ultimately rolling it out to the rest of the organization.

Exercise: How Agile is your culture?

2.1.1

Estimated Time: 1 hour

• Individuals: Identify current aspects of your organization’s culture.
• As a group map them to quadrants.
• Debrief the quadrants as enablers/barriers to Agile success.

Input

• Knowledge of team and organization’s culture

Output

• Factors that affect collaboration, control cultivation, and impact competence

Materials

• Sticky notes
• markers

Participants

• All

Document results in Info-Tech’s Agile Playbook Template.

Improve consistency and reduce manual tasks with valuable tools and technologies

Agile aims to increase responsiveness, but this cannot happen if inadequate technology is slowing down communication and processes.

Establish accessible, scalable, and reliable environments:

• Emphasize development simplicity, which aids in communication.
• Automate code-level testing to increase velocity.
• Enable continuous integration with automated build capabilities.
• Codify unit testing to increase the scalability of test-driven development.

Leverage appropriate design tools and software:

• High-level and detailed design should be used as a communication vehicle for the cross-functional development, testing, and operations teams.
• Tools should be interoperable so various development domains can work in their preferred tool and maintain traceability of development and maintenance tasks back to business requirements.

Info-Tech Insight

Organizations are leveraging application lifecycle management (ALM) tools to provide the traceability of development tasks, test cases, and support tickets back to business requirements. This helps ensure that each activity is driving toward business value. Refer to Info-Tech’s Evaluate the Application Lifecycle Management Landscape.

Stay focused on your culture to ensure everyone has a common foundation as you roll out Agile

• Your diverse teams provide a well-rounded product. When a pilot team is comprised of members with different skills, opinions, and experiences, each person will bring a different perspective, helping to minimize gaps and defects during the creation of the product.
• Your teams aren’t scared to take risks. When pilot teams are comfortable taking risks and know they won’t be punished, they’ll push their creativity further and may come up with something others were afraid to try. Trust must first be established.
• Your team members feel accountable to others. Teams are more apt to meet deadlines and work smarter when they are accountable to others because they don’t want to let their team down.
• Your teams are value-driven. They deliver high-quality products to end users within an expected time frame. Achieving this goal will require a specific mindset, where teams treat failures as learning opportunities, seek to continuously improve the Agile process to increase throughput or productivity without compromising stakeholder alignment, and quickly respond to feedback.

Assess your culture for Agile implementation to ensure values are grounded

A common cause of Agile failure is an organizational culture that is too political and locked in a traditional mindset. Avoid this issue by adopting the right values and creating the appropriate organizational structure.

Values

To establish an Agile culture, you must place importance on creating common values and visions throughout the organization. Adopt the following:

• Welcome and embrace change in working environments and project requirements.
• Emphasize the delivery of high value to the customer rather than just meeting deadlines.
• Build an interactive, collaborative, and encouraging working environment.

Organization Structure

Rigid hierarchies and structure are significant challenges to adopting Agile. Organizations that have successfully implemented Agile have:

• Cooperative organizational cultures with clearly defined roles and responsibilities.
• Placed high value on in-person communication and transparent development processes, priorities, and schedules.
• Business and technical teams that accept and encourage Agile practices and philosophies.

Info-Tech Insight

Traditional emphasis on value delivery “on time” and “on budget” assumes an enormous forward-looking scope based on current knowledge that makes the value proposition risky and near impossible to attain. The intent is right but the execution is flawed.

Exercise: Conduct a SWOT analysis to reveal additional gaps in your organization

2.1.2

Estimated Time: 2 hours

1. Using sticky notes, write strengths, weaknesses, opportunities, and threats (one per sticky note) as they pertain to the current state of your development environment. Consider people, process, and technology elements.
2. Using a whiteboard, place the sticky notes on the appropriate section of the quadrant.
3. Discuss how Agile can alleviate your weaknesses, generate opportunities, and present threats to your Agile rollout.

Input

• Understanding of current development environment
• Understanding of team members

Output

• SWOT analysis of current SDLC

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Step 2.2: Assess Your SDLC

This step will walk you through the following activities:

• Identify and describe SDLC stage-gates.
• Draw current SDLC process.
• Determine pain points in SDLC.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Completed SDLC stage-gates.
• SDLC process flow.
• Pain points in SDLC as they relate to Agile.

Assess the current state of your SDLC

Your SDLC identifies the core artifacts, roles, and activities involved to deliver valuable features, software, and fixes to stakeholders, whether you are using a Waterfall or Agile methodology. Take a close look at the following components of your SDLC to reveal any issues and challenges that can pose a risk to your Agile implementation and pilot project:

Remember, Agile is just an approach to execute your SDLC. Using Agile will expose existing SDLC issues and inefficiencies because of the increased transparency. In some instances, these issues may have been previously masked or irrelevant. Proactively identify and address any potential SDLC people, process, or technology risks before they generate conflicts and derail your Agile pilot project.

SDLC services and capabilities are collectively defined as your SDLC practice. Therefore, your team’s responsibilities and accountabilities, communication flow, and decision-making rights must clearly support these capabilities, and the roles within your team must be competent. Understand the various capabilities needed within your SDLC practice and the underlying responsibilities and accountabilities that support them.

SDLC Capabilities

• Software Coding & Build Management
• Team Culture
• Team Design & Governance
• Resourcing & Capacity
• People Development
• Knowledge Management
• System Configuration
• Software QA
• Selection & Procurement
• Requirements Gathering & Management
• Application & Product Portfolio Management
• Release & Deployment Management
• Enterprise & Application Architecture
• Test Management
• Application Support
• User Experience
• Business Relationship Management
• Maintenance Management
• Vendor Management

Exercise: Identify and describe your SDLC stage-gates

2.2.1

Estimated Time: 30 minutes

1. List the major stage gate controls of your development process and identify who is accountable.
2. Briefly define each stage gate and the required passing criteria.
3. Ask yourself the following questions:

Input

• Understanding of current SDLC phases and hand-off points

Output

• Stage gate definition and passing criteria

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Exercise: Draw your current SDLC

2.2.2

Estimated Time: 1.5 hours

1. Using your SDLC stage-gates as a starting point, draw your current development process as a swim lane diagram.
2. Identify who is involved in each step of the process and what tools and technologies are used.
3. Identify when your SDLC artifacts are created and validated. These validation points should indicate the workflow if an artifact is not approved.

Input

• List of artifacts
• Development roles
• SDLC stage-gates

Output

• Grounded SDLC process flow

Materials

• Whiteboard
• Markers

Participants

• Development team

Example:

Document results in Info-Tech’s Agile Playbook Template.

Exercise: Determine the pain points in your current SDLC

2.2.3

Estimated Time: 1 hour

1. Using your SWOT analysis as a starting point, highlight the pain points and challenges in your current SDLC. Consider the following challenges and pain points:
   • Poor artifact hand-offs between roles, teams, and stakeholders.
   • Bottlenecks where excessive time is taken to complete tasks or teams are waiting for dependent tasks to be completed.
   • Lack of stakeholder involvement, leading to low quality applications.
   • Poor development practices, generating technical debt.
   • Missing standards, leading to inconsistently followed processes and structures.
2. Determine the root cause of each pain point and challenge you have identified by asking “why?” three times. Consider the example below:

Input

• Current SDLC process flow

Output

• List of SDLC pain points

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Example:

Document results in Info-Tech’s Agile Playbook Template.

Waterfall SDLC – Valuable product delivered at the end of an extended project lifecycle, frequently in years

• Business separated from delivery of technology it needs; only one third of product is actually valuable (ITRG, N=40,000).
• In Waterfall a team of experts in specific disciplines hand off different aspects of the lifecycle.
• Document signoffs are required to ensure integration between silos (Business, Dev, and Ops) and individuals.
• A separate change request process lays over the entire lifecycle to prevent changes from disrupting delivery.
• Tools are deployed to support a specific role (e.g. BA) and seldom integrated (usually requirements - test).

Wagile/Agifall/WaterScrumFall SDLC – Valuable product delivered in multiple releases

• Business is more closely integrated by a business product owner accountable for day-to-day delivery of value for users.
• The team collaborates and develops cross-functional skills as they define, design, build, and test code over time.
• Signoffs are reduced but documentation is still focused on satisfying project delivery and operations policy requirements.
• Change is built into the process to allow the team to respond to change dynamically.
• Tools start to be integrated to streamline delivery (usually requirements and Agile work management tools).

Agile SDLC – Valuable product delivered iteratively: frequency depends on Ops’ team capacity

• Business users are closely integrated through regularly scheduled demos (e.g. every two weeks).
• Team is fully cross-functional and collaborates to plan, define, design, build, and test the code supported by specialists.
• Change is built into the process to allow the team to respond to change dynamically.
• Explore automation for application development (e.g. automated regression testing).

Agile with DevOps SDLC – High frequency iterative delivery of valuable product (e.g. every two weeks)

• Business users are closely integrated through regularly scheduled demos.
• Dev and ops teams collaborate to plan, define, design, build, test, and deploy code supported by automation.
• Documentation is focused on supporting users, future changes, and operational support.
• Change is built into the process to allow the team to respond to change dynamically.
• Build, test, deploy is fully automated (service desk is still separated).

DevOps SDLC – Continuous integration and delivery

• Business users are closely integrated through regularly scheduled demos.
• Fully integrated DevOps team collaborates to plan, define, design, build, test, deploy, and maintain code.
• Documentation Is focused on future development and use adoption.
• Change is built into the process to allow the team to respond to change dynamically.
• Fully integrated development and operations toolchain.

Fully integrated product SDLC – Agile + DevOps + continuous delivery of valuable product on demand

• Business users are fully integrated with the teams through dedicated business product owner.
• Cross-functional teams collaborate across the business and technical life of the product.
• Documentation supports internal and external needs (business, users, Ops).
• Change is built into the process to allow the team to respond to change dynamically.
• Fully integrated toolchain (including service desk).

If you want additional support, have our analyst guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

SWOT analysis

This activity involves the delivery teams and other stakeholders to identify and determine the strengths, weaknesses, opportunities, and threats to successfully adopting and implementing Agile in the environment. By uncovering these drivers or roadblocks, the team gains an understanding of how to use their strengths to mitigate threats and drive weaknesses down by leveraging their opportunities.

Document your SDLC process

This activity involves the delivery teams and other stakeholders to document their current SDLC process along with their pain points, gaps, and opportunities for improvement. This enables further discussions around how your SDLC process will maturity through the Agile journey.

Phase 3

Execute Your Structured Evaluation

Phase 3 outline

Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

Step 3.1: Understand Scrum

This step will walk you through the following activities:

• Identify and evaluate business value definitions.
• Identify “ready” and “done” definitions.
• The baseline scrum methodology and practices.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Completed business value definitions.
• Completed “ready” and “done” definitions.
• A deeper understanding of the scrum methodology and benefits of adopting these practices.

Understand the importance of a structured evaluation to your success at adopting Agile

Research shows that Agile feels better and is very suitable for software development teams. However, not all organizations are ready or capable of making the shift to Agile. Your structured evaluation helps you determine and test run Agile practices in a controlled and pre-set environment to define the success rate of adopting Agile within your organization. While one pilot team cannot determine the success of Agile at your entire organization, it provides you with a platform to fail fast and recover quickly by learning from the team’s mistakes and focusing on continuously improving. Your structured evaluation allows you to determine what works and what doesn’t and takes an iterative approach to introducing Agile in your organization.

Start with a baseline scrum implementation

Use scrum as a starting point for your Agile implementation because of its popularity and community support.

Why start with scrum?

Simplicity: Scrum philosophies and methodologies are straightforward, prescriptive, and available resources to aid in implementation are widely available.

Flexibility: Scrum makes an ideal foundation to build a personalized Agile process strategy. Technical Agile techniques, such as pair programming and continuous integration, can easily be injected.

Success: Scrum has had a lot of success with confronting changes in requirements, increasing collaboration and communication within teams, and improving the transparency with stakeholders.

Be aware of the limitations of scrum

• Business risk: Scrum cannot not rescue a product’s development if the business does not have a clear sense of its direction.
• Resolution agnostic: Scrum exposes impediments and issues but does not offer insights on how to solve the problems.
• Redefinition of roles: Scrum can change the roles and responsibilities of the existing project team considerably.

Info-Tech Insight

• Use well known, by-the-book scrum processes and artifacts to ease the rollout of your initial pilot. Gradually modify these processes and artifacts to better fit your context as you gain more experience.
• It may be necessary to bring in an Agile coach to help provide training.
• There are no designated project managers, but leaders are still needed to challenge the team to improve.

Familiarize yourself with the key terminologies used in scrum

• User Story – Short description of a desired piece of functionality from the perspective of the customer. User stories provide just enough information of what the functionality is, who will be using it, and what benefit it will provide to the user.
• Ceremony – The collaboration sessions where development teams and stakeholders come together to discuss, review, reflect on, and assess work in progress, recent experiences, and lessons learned. In the scrum methodology, ceremonies include release planning, sprint planning, stand-ups, retrospectives, sprint reviews, and demonstrations.
• Epic – A collection of similar user stories that describe significant and large development initiatives.
• Points – Arbitrary values used by Agile teams to estimate the effort to complete a user story, epic, or theme. Teams are evaluated based on their ability to consume (i.e. burndown) points. Fibonacci sequence or exponential values are commonly used point schemes. In some cases, points are used to estimate and gauge the delivery of business value.
• Theme – A collection of similar epics used to define high-level business objectives.
• Sprints – Time-boxed development iterations where business value is ideally delivered at the end, whether that is an artifact (e.g. wireframe designs) to review or a deployed feature. Sprints are consistent in length (on average two to four weeks) during a project.
• Backlog – A prioritized list of user stories, epics, and/or themes for development teams.
• Release Milestone – A significant stage in development where an agreed-upon set of user stories, epics, and themes will be delivered to the customer. The scope of each milestone is broken down into same-sized sprints.

Understand the scrum process

The scrum process coordinates multiple stakeholders to deliver on business priorities.

Note: Functional requirements, which make up your product and sprint backlogs, are typically written as short user stories. Additional details are added to these user stories once they are “ready” and prioritized for immediate development.

Understand the ceremonies part of the scrum process

Leverage an Agile facilitation tool to assist in the documentation of your Agile artifacts

3.1.1 Scrum Documentation Template

Info-Tech Insight

Use a whiteboard for the scrum board of your first Agile implementation. A whiteboard is an ideal medium for learning because teams can visually and physically see how user stories are written, moved, and burned down; how feedback and roadblocks can disrupt project progress; and how project and resource dependencies are managed. Lessons learned from your whiteboard can then be translated to an Agile facilitation tool, such as Info-Tech’s Scrum Documentation Template.

Use Info-Tech’s Scrum Documentation Template

Document your user stories, tasks, points estimates, and burndowns once your release and sprint planning, stand-ups, and retrospectives have concluded. The blueprint will indicate when you should add information to this template.

Goals:

• Generate team velocities based on past performance.
• Benchmark estimates based on past sprint planning results.
• Demonstrate how key initiatives improved the team’s ability to complete user stories.

Many ALM vendors offer products to assist with and enhance the facilitation of Agile development. Their virtual scrum boards are ideal for distributed team members and each Agile artifact (e.g. user story, burndown chart) is automatically documented and monitored. Refer to Info-Tech’s Evaluate the Application Lifecycle Management Landscape.

Establish the scrum roles and responsibilities

See how traditional development roles translate to those in scrum

Development roles may shift when transitioning to scrum, but the value of each role will remain the same.

Info-Tech Insight

• Be aware of conflicting interests – Without the right training, traditional roles (e.g. BAs and PMs) may continue to bring traditional thinking and priorities to your pilot project. This can counteract the goals you hope to achieve and conflict with your development guidelines.
• Rotate scrum masters – Scrum masters can be anyone, as long as they have a deep understanding of the dynamics in development and a strong grasp of Agile and scrum concepts.
• Keep the team size to 5-9 members – This size helps ease task coordination and collaboration among team members. Separate teams can be created to support the development team (e.g. security, architects), but they must be actively communicating with the development team and collaborating in key scrum activities.

Leverage a coach’s expertise in training sessions and your initial sprints

If using a coach, they should:

• Gain an understanding of your team’s current situation to help you tailor an Agile process and culture best suited for your needs.
• Work closely with your teams during their first sprint (e.g. first planning meeting, first set of daily meetings, first retrospective) and then slowly wean off as your teams gain more experience. The coach will eventually withdraw when the team is capable of running key Agile ceremonies (phases) on their own.
• Be aware that no two teams will face the same challenges and hurdles. Some teams may need significant and rapid alterations to bridge major gaps, while others might only need knowledge and convincing. Have your Agile coach lead your training sessions to quickly bring your team up to speed and get them comfortable with the changes.
• Encourage the leads of other teams to facilitate retrospectives for each other to promote knowledge sharing.

Info-Tech Insight

Your coaches can assist in the facilitation of your retrospectives. They can help in uncovering issues experienced by your teams, create and prioritize your optimization user stories based on these issues, and assist in ensuring these stories are injected into your team’s backlog.

Define business value in your context to define the success of your Agile pilot

How do I define business value?

Business value must come from the business, not IT. They are the keepers of the organization’s mission, vision, and mandates. Make the business the authority on value, then form a partnership that defines that value in the context of your Agile pilot.

Consider all the ways your Agile pilot can create value. Then work with the business to identify your organization’s unique business-value drivers and weigh these in accordance with your organization’s overall strategy.

How do I measure business value?

Business value cannot always be expressed in monetary terms. Take a balanced approach by weighing the different sources of value and assigning metrics to measure and trace your pilot’s value.

Info-Tech Insight

Remove emotion from the assessment.

Assessing your Agile pilot against a robust set of business-value metrics ensures a critical understanding of the pilot’s actual importance, reduces everyone’s bias, and eliminates the “loudest voice in the room” style of decision making.

Activity: Clearly state your definition of business value

3.1.1

Estimated Time: 30 minutes

1. List key drivers that will define the value of the project deliverables to your business stakeholders. Discuss how these drivers have been applied to previous projects.
   • Business value drivers can be your business objectives.
2. Define the metrics that will be used to measure each driver.
3. Determine how these drivers can be qualitatively and/or quantitatively measured.

Input

• Knowledge of organization’s business value drivers
• Business objectives

Output

• Definitions of business value drivers

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Ensure requests and requirements are ready for development

Clearly define what it means for a requirement, change, or maintenance request to be ready for development. This will help ensure the value and scope of each functionality and change are clear and well understood by both developers and stakeholders before the start of the sprint. The definition of ready should be two-fold: ready for the backlog and ready for coding.

1. Create a checklist that indicates when a requirement or request is ready for the development backlog. Consider the following questions:
   • Is the requirement or request in the correct format?
   • Does the desired functionality or change have significant business value?
   • Can the requirement or request be reasonably completed within defined release timelines under the current context?
   • Does the development team agree with the budget and points estimates?
   • Is there an understanding of what the requirement or request means from the stakeholder or user perspective?
2. Create a checklist that indicates when a requirement or request is ready for development. Consider the following questions:
   • Have the requirements and requests been prioritized in the backlog?
   • Has the team sufficiently collaborated on how the desired functionality or change can be completed?
   • Do the tasks in each requirement or request contain sufficient detail and direction to begin development?
   • Can the requirement or request be broken down into smaller pieces?

Leverage the INVEST Model to determine when your user story is ready for development

The goal is to refine your user stories so they are:

Independent: Ideally your user stories can be built in any order (i.e. independent from each other). This allows you to prioritize based on value, and not get caught up in sequencing and prerequisites.

Negotiable: As Agile purists will tell you, focus on collaboration over contracts. Your user stories are meant to facilitate collaboration between the developer and the business. Therefore, they should be built to allow negotiation between all parties.

Valuable: Nothing new here. A user story needs to state the value so it can be effectively prioritized, but also so developers know what they are building.

Estimable: As opposed to higher-level approximation given to epics, user stories need more accuracy in their estimates to be effectively prioritized, but also so teams can know what can fit into a sprint or release plans.

Small: User stories should be small enough for a number of them to fit into a sprint. However, team size and velocity will impact how many can be completed.

Testable: Your stories need to be testable, which means you need to satisfy quality assurance standards.

Source: “New to Agile? INVEST in Good User Stories”

Ground your definition of what it means to be “done”

Clearly define what it means for a feature or change to be done. This will help ensure the completed feature or change meets stakeholder expectations and is stable for downstream activities, such as testing and deployment. The definition of done should come two-fold: done in terms of functional completeness and done in terms of stakeholder alignment.

• Create a checklist that indicates when a feature or change is functionally complete. Consider the following questions:
  • Does the feature or change perform as described in the business requirement or request?
  • Was the solution sufficiently unit, regression, and integration tested and will it be stable in the QA, staging, and production environments?
  • Does the solution align itself to existing security protocols, regulations, usability requirements, and other non-functional requirements?
• Create a checklist that indicates when a feature or change is done according to stakeholder expectations. Consider the following questions:
  • Is the completed feature or change acceptable to stakeholders and end users?
  • Will its deployment cause significant business disruption?

Done:

When the user story is accepted by the product owner and is ready to be released.

Done Done:

When the user story is delivered to the customer.

Done Done Done:

When the user story has the necessary documents to support it in production.

Activity: Clearly state your definitions of “ready” and “done”

3.1.2

Estimated Time: 30 minutes

1. Recall the steps and stage-gates in your current development process. Identify the criteria that is needed to start and complete a given task.
2. Use this criteria to define your ready and done criteria.
3. Create a checklist to help ensure these criteria are consistently followed.

Input

• Criteria for defining ready and done
• Knowledge of what ready and done mean in Agile

Output

• Definitions of ready and done for your Agile team

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Understand how requirements translate in an Agile world

Do not forget your enablers, the PBIs that provide the means for future functionality

An enabler is any support activity needed to provide the means for future functionality. Enablers build out the technical foundations of the product, otherwise referred to as the architectural runway.

Consider Granularity

Again, your audience will dictate the level of detail you should include, but it is a good rule of thumb to stick to the feature level.

Consider Types

Exploration

Any efforts toward learning customer or user needs and creation of solutions and alternatives. Exploration enablers are heavily linked to learning milestones.

Architectural

Any efforts toward building components of your architecture. These will often be linked to delivery teams other than your pure development team.

Infrastructure

Any efforts toward building various development and testing environments. Again, these are artifacts that will relate to other delivery teams.

Compliance

Any efforts toward regulatory and compliance requirements in your development activities. These can be both internal and external.

Source: “Framework for Scaling Agile”

Step 3.2: Evaluate Stakeholder Participation

This step will walk you through the following activities:

• Identify stakeholders and groups.
• Assess and prioritize all stakeholders and groups.
• Identify and evaluate strategies to engage stakeholders and groups.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Relevant stakeholder groups and their prioritization as it related to your Agile transformation.
• Completed stakeholder engagement strategies based on their prioritization.

Understand the importance of stakeholder engagement for your Agile transformation

Stakeholders are groups of people within the organization that have the interest or influence to impact your products, program, teams, or projects, and as a result can impact your Agile transformation.

What are the challenges with stakeholder management?

1. Organizational politics

Competition, History of conflict

2. Misalignment

Conflicting priorities, Misaligned vision and goals

3. Shoot the messenger

Fear of turning down stakeholders that you wouldn’t historically, Fear of delivering bad news that does not align to their expectations

4. Stakeholders change

Turnover, Might have to build relationships from scratch

Adopt a stakeholder management process to identify and assess the stakeholders that will help you along your journey

Identify the right stakeholders that will embark on your Agile journey with you

Not all stakeholder groups are inherently obvious and not all will be promoters of your transformation. Some groups often overlooked include subcontractors, suppliers, competitors, regulatory agencies, IT Ops, and Production support. Focus your effort on filtering through stakeholder groups into two buckets at the identification stage to determine if they are supporters or detractors:

• What is their ability to impact the Agile initiative?
• Are they subject matter experts? Can they enhance the initiative?
• Can they slow down the teams, projects, or initiative?
• Can they guide in removing impediments?
• Can they lead opinions?
• Do they have the ability to facilitate changes resulting from the transformation?
• Can they provide a voice of reason?

Identifying the nature of their influence and impact will help you tailor your approach to engaging specific stakeholders.

Exercise: Identify stakeholder groups as part of the Agile transformation and categorize them

3.2.1

Estimated Time: 30 minutes

1. List each of your stakeholder groups that will play a role in your Agile transformation journey.
2. Refer back to the list on the previous slide to vet each stakeholder group to determine their level of influence and impact.
3. Based on the team’s inputs, collectively decide on a categorization for each stakeholder group (Supporter or Detractor).
4. Determining the nature of their participation will impact how you prioritize them and ultimately engage with them on your journey.

Input

• List of stakeholder groups
• Scoping questions for categorization

Output

• List of stakeholders
• Categorization of each stakeholder group

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Define and assess the stakeholders involved in your Agile transformation using the CLAIM Model

Stakeholder feedback and management support are key components of a successful Agile transformation:

Exercise: Assess all your stakeholder groups as part of the Agile transformation

3.2.2

Estimated Time: 30 minutes

1. For each stakeholder group identified previously, list the characteristics and behaviors they possess (positive and negative) that impact each section of the CLAIM Model.
2. Based on the descriptions of each stakeholder group, identify the biggest communication challenges or roadblocks you may experience as part of your Agile journey.

Input

• List of stakeholder groups
• Scoping questions for assessment

Output

• List of stakeholders
• CLAIM assessment of each stakeholder group
• List of communication challenges

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Prioritize stakeholders based on their levels of discipline and integration with the business

Exercise: Prioritize all your stakeholder groups as part of the Agile transformation

3.2.3

Estimated Time: 30 minutes

1. Refer back to the stakeholder group list previously generated, and map each group to one of the four quadrants below.

Input

• List of stakeholder groups
• Scoping questions for prioritization

Output

• List of stakeholders
• Prioritization and mapping of each stakeholder group

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Identify strategies to engage stakeholders based on the nature of their influence and impact to your Agile journey

Exercise: Identify strategies to engage stakeholders

3.2.4

Estimated Time: 30 minutes

1. For each stakeholder group identified previously, refer back to their categorizations and list them alongside each other like below.
2. Considering their behaviors, communication challenges, and their degree of impact, influence, and priority, determine whether they require a high-, medium-, or low-effort level to engage actively or otherwise.
3. Brainstorm strategies to effectively engage each stakeholder group based on the level of effort and attention required from the team.
4. Ensure to use this information when rolling out Agile to your pilot teams and the business

Input

• List of stakeholder groups
• Scoping questions for engagement efforts

Output

• List of stakeholders
• Engagement effort and strategies for each stakeholder group

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Step 3.3: Select the Right Pilot

This step will walk you through the following activities:

• Identify business objectives and guiding principles for your structured evaluation.
• Assess pilot project complexity, duration, relevance, and ownership.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Completed business objectives and guiding principles for pilot project and team.
• Short-list of pilot candidates.

Understand the scope of your structured evaluation

Scope of this blueprint: plan and execute a structured evaluation of Agile practices with one to three application delivery teams.

Out of scope. Refer to Enable Organization-Wide Collaboration by Scaling Agile blueprint for this content.

Select a pilot project to gain visibility and buy-in for future implementations

Adopting the right set of practices and tools requires a significant degree of change that necessitates buy-in from all levels of the business. Leverage a pilot project to:

• Surface and address communication, governance, and technology issues that were not previously significant or not perceived as important.
• Generate the necessary metrics to convince management and stakeholders of further Agile adoption.
• Build a group of evangelists and champions.

STEPS TO SELECT YOUR SUCCESSFUL AGILE PILOT

Evaluate your business drivers using the CLAIM Model

Defining your business objectives for Agile adoption is instrumental is getting all stakeholders on the right page. Defining “what’s in it for me?” at every layer of the organization ensures that all stakeholders are invested and committed to adopting Agile. Determine some of the gaps within your teams and organization that are encouraging you to embark on your Agile journey.

Exercise: Document key business objectives related to Agile development

3.3.1

Estimated Time: 30 minutes

1. On a whiteboard, write the current business objectives related to Agile development. Some example objectives include:
   • Increase customer satisfaction and engagement.
   • Reduce business operation costs.
   • Create innovative products to remain competitive in the market.
2. Define the business value each objective is intended to deliver.
3. Identify the business priority for each objective.

Example:

Input

• Understanding of current business objectives

Output

• Prioritized list of business objectives related to Agile

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Use “The Agile Manifesto” to establish a basis for your development guiding principles

Development guiding principles (similar to a charter) help ensure your teams have the appropriate mindset, motivations, and behaviors to achieve a successful Agile pilot. Start with “The Agile Manifesto,” and add, remove, or modify principles as you deem fit.

PRINCIPLES OF THE AGILE MANIFESTO

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Source: “The Agile Manifesto”

Exercise: Establish the guiding principles of your Agile pilot

3.3.2

Estimated Time: 45 minutes

1. Discuss the development guiding principles of your Agile pilot. Your guiding principles should include “The Agile Manifesto” and can consider the following:
   • Improve collaboration between business and development teams.
   • Improve resource utilization and productivity.
   • Improve the quality and acceptance of products with Agile.
2. Discuss how your Agile pilot can achieve and optimize the alignment between your business objectives and development guiding principles. Use the following matrix to document your discussion.

Input

• Stakeholder expectations with Agile implementation

Output

• Alignment between development guiding principles and business objectives

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Select your Agile pilot project

Your pilot project selection should be based on four core criteria:

Complexity

The project should have sufficient complexity to demonstrate the effectiveness of Agile with relevant metrics, but not too complicated where teams cannot focus on learning Agile.

Duration

Either an entire project or several project milestones that can be completed within several months, so that sufficient data can be gathered to gauge the fit of Agile.

Relevance

The project will continuously and frequently deliver business value to stakeholders and stakeholders will provide constructive feedback for improvement.

Ownership

Decision-making authority around business requirements, task prioritization, and process optimization is clear and defined.

Select a pilot with low to moderate complexity so focus is concentrated on learning the Agile process

Restrict your pilot to the software development domain. If a project incorporates other disciplines, it can dilute the authenticity of your results.

Tips to Reduce Project Complexity:

Collocate the team: When teams are spread out geographically, it increases communication issues.

Keep team sizes small: Large pilot teams will reduce individual learning.

Select the right team: Choose domain experts who have in-depth experience and can act as champions upon pilot completion.

Manage risks: Don’t integrate with a high-risk project during the pilot. Otherwise, Agile could be blamed for the failure of both projects.

Understand the underlying technology: Complicated technology can distract teams from learning Agile during your pilot.

Break down requirements: Small and concise requirements help remove the ambiguity that large, high-level requirements often bring.

Info-Tech Insight

Complexity management is not a one-time effort. The natural tendency is for complexity to increase in a project over time. You need to wrestle against this natural momentum. As your pilot unfolds, continually strive to reduce complexity to improve chances of success.

Define your IT pilot program using the CLAIM Model

Exercise: Assess your pilot’s complexity

3.3.3

Estimated Time: 30 minutes

1. List the pilot project candidates across the top row of the table below.
2. For each project, answer the questions below about its complexity (Disagree, Neutral, Agree).

Input

• Understanding of the scope of pilot project candidates

Output

• Pilot complexity fit assessment

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Select a pilot with suitable duration attributes to get a true assessment of the fit of Agile

Stakeholders and managers should be looking for results. Provide tangible metrics for several iterations.

Tips to ensure sufficient duration:

Choose a project that allows three to five iterations. If the project is too short, it will create skepticism as people will assume Agile can only be successful with short, simple projects.

Keep the same development team throughout the pilot and focus on getting the process right first.

Agile benefits are best shown in pilots with these duration attributes:

• Shifting Deadlines
• Simple Decisions Are Taking Too Long

Info-Tech Insight

Do not focus exclusively on the delivery of your pilot project when setting and reviewing its duration. You need to also look at spin up and spin down activities like planning and retrospectives. Note any challenges and improve on them with management support.

Exercise: Assess your pilot’s duration

3.3.4

Estimated Time: 15 minutes

1. List the pilot project candidates across the top row of the table below.
2. For each project, answer the questions below about its duration (Disagree, Neutral, Agree).

Input

• Understanding of the scope of pilot project candidates

Output

• Pilot duration fit assessment

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Select a pilot that has stakeholder relevance to cultivate support

Align the objectives of Agile with stakeholder concerns.

Leverage the following strategies for dealing with difficult stakeholders:

• Include them in key discussions
• Listen and prioritize concerns
• Establish governance rules
• Focus on the end customer

Info-Tech Insight

Sometimes choosing a failed but self-contained and highly relevant project is appropriate. These are ideal candidates for an accelerated Agile pilot due to the urgency and management support the project already has.

Exercise: Assess your project’s relevance

3.3.5

Estimated Time: 15 minutes

1. List the pilot project candidates across the top row of the table below.
2. For each project, answer the questions below about its relevance (Disagree, Neutral, Agree).

Input

• Understanding of the scope of pilot project candidates

Output

• Pilot relevance fit assessment

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Select a pilot that has an appropriate ownership structure to ensure continuous feedback

Ownership establishes accountability that guides development efforts

The product owner should be sharing their vision with the team, ensuring they are available to resolve problems and provide guidance. This role prevents teams from guessing and going in the wrong direction.

• Owners must set priorities for each iteration.
• Developers should have access to end users (or representatives) as part of transparent communication.
• Retrospectives with product owners should lead to continual improvement.
• Requirements conflict resolution should be done by owners without resorting to politics with the team.
• Clear acceptance criteria for each prioritized iteration should be communicated.
• In some cases, owners need to accept that new requirements will surface and will not be committed to until the next iteration.

Info-Tech Insight

Moving to Agile does not mean you remove existing ownership structures and allow the team to set their own priorities. Lack of accountability will derail your pilot efforts if no one is able to make decisions about true business priorities.

Exercise: Assess your pilot’s ownership structure

3.3.6

Estimate Time: 15 minutes

1. List the pilot project candidates across the top row of the table below.
2. For each project, answer the questions below about its ownership structure (Disagree, Neutral, Agree).

Based on your responses in the previous exercises, select the project that you believe will benefit most from Agile and be a good proof of concept for future organization-wide rollouts.

Input

• Understanding of the scope of pilot project candidates

Output

• Pilot ownership fit assessment
• Pilot project selection

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Step 3.4: Simulate Scrum

This step will walk you through the following activities:

• Identify key scrum roles.
• Build user stories.
• Refine the backlog.
• Build development tasks for user stories.
• Estimate points for user stories.
• Determine team velocity and simulate sprint planning.
• Simulate daily stand-up.
• Simulate sprint review and demo.
• Identify the team’s Agile metrics.
• Simulate a sprint retrospective.

This step involves the following participants:

• Development Manager/VP/Director
• Project/Program Manager
• External Trainer/Consultant
• Agile Coach
• Product Manager/Product Owner
• Scrum Master
• Agile Teams (business analyst, developers, testers, architects, QA, UI/UX designers, etc.)

Outcomes of this step

• Understanding and knowledge of all scrum practices and ceremonies.
• List of Agile metrics.

Begin your scrum simulation

This simulation is intended to demonstrate by-the-book scrum in the context of your pilot project and gauge the team’s success in adopting Agile practices.

1. Identify scrum roles and self-organize the team
2. Build product backlog with user stories and introduce product backlog refinement
3. List your development tasks for each user story
4. Estimate the points for your user stories based on the tasks
5. Simulate sprint planning (commit to user stories for sprint)
6. Conduct a daily stand-up/scrum
7. Conduct a sprint review (demo sprint deliverables)
8. Identify and track Agile metrics to evaluate your success
9. Conduct a retrospective and improve your scrum and SDLC process

Activity: Identify key scrum roles

3.4.1

30 minutes

1. Identify the key scrum roles that should be involved in the pilot project.
2. Map existing SDLC roles to scrum roles and identify the required changes or training.
3. Self-organize team members and assign roles based on skillsets and responsibilities.

Input

• SDLC roles and responsibilities
• List of Agile team members

Output

• List of scrum roles and responsibilities

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Scrum Documentation Template.

Understand the relationship between user stories, requirements, and design

Create a product backlog to communicate business needs to development teams

Use the backlog to capture expected work.

The product backlog helps to create a roadmap for the project by showing you what requirements need to be delivered.

How is the product owner involved?

• The product owner is responsible for keeping in close contact with the end customer and to make the appropriate changes to the product backlog as new ideas, insights, and impediments arise.
• The product owner should have good communication with the team to make accurate changes to the product backlog depending on technical difficulties and needs for clarification.

How do I create a product backlog?

• Write requirements in user stories. Use the format: “As a (user role), I want (function) so that (benefit).” Identify end users and understand their needs.
• Assign each requirement a priority. Decide which requirements are the most important to deliver. Ask yourself which user story will create the most value.

What are the approaches to generate my backlog?

• Team Brainstorming – The product owner, team, and scrum master work together to write and prioritize user stories in a single or a series of meetings.
• Business Case – The product owner translates business cases into user stories as per definition of development ready.

Epics and Themes

As you begin to take on larger projects, it may be advantageous to organize and group your user stories into the following in order:

• Epics are a collection of similar user stories and are used to describe significant and large development initiatives.
• Themes are a collection of similar epics and are normally used to define high-level business objectives.

To avoid confusion, the pilot product backlog will be solely composed of user stories.

Example:

Understand how backlog refinement plays a role in sprint planning

Distinguish your specific goals for refining in the product backlog vs. planning for a sprint itself

Often backlog refinement is used interchangeably or considered a part of sprint planning. The reality is they are very similar, as the required participants and objectives are the same; however, there are some key differences.

A better way to view them is “pre-planning” and “planning.”

At this stage your PBIs should be user stories – use the INVEST Model

The goal is to refine your PBIs so they are:

Independent: Ideally your user stories can be built in any order (i.e. independent from each other). This allows you to prioritize based on value, and not get caught up in sequencing and prerequisites.

Negotiable: As Agile purists will tell you, focus on collaboration over contracts. Your user stories are meant to facilitate collaboration between the developer and the business. Therefore, they should be built to allow negotiation between all parties.

Valuable: Nothing new here. A user story needs to state the value so it can be effectively prioritized, but also so developers know what they are building.

Estimable: As opposed to higher-level approximation given to epics, user stories need more accuracy in their estimates to be effectively prioritized, but also so teams can know what will fit into a sprint or release plans.

Small: User stories should be small enough for a number of them to fit into a sprint. However, team size and velocity will impact how many can be completed.

Testable Your stories need to be testable, which means you need to satisfy your quality assurance standards.

Source: “New to Agile? INVEST in Good User Stories”

Create, split, and bundle user stories from your epics as necessary

The following questions can be helpful in dissecting an epic to the user-story level. The same line of thinking can also be useful for bundling multiple small PBIs together.

Source: “New to Agile? INVEST in Good User Stories”

Understand the common language used to build user stories

Documentation, or lack thereof, is intentionally minimal for a user story.

This isn’t to say user stories do not require documentation or more comprehensive information. The information related to the user story is stored in its corresponding epic. Therefore, traceability between user story and epic is the real objective, and a core responsibility for the caretaker of the product backlog.

Activity: Build user stories

3.4.2

Estimated Time: 1 hour

1. Have your product owner describe the business objectives of the pilot project.
2. Write the key business requirements as user stories.
3. Break down the user stories if the feature or business goal is unclear or too large.

Scenario: Build an HR system that manages employee absence requests.

Input

• Scope of selected pilot project

Output

• User stories

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master

Document these user stories in the Scrum Documentation Template.

Exercise: Refine the backlog

3.4.3

Estimated Time: 30 minutes

1. Based on the user stories created, the product owner assigns a priority ranking to each user story to determine the order in which they will be completed.
2. Have your team review the user stories and question the story’s value, priority, goal, and meaning to better understand the needs of the requirement.
3. Define “done” by defining individual acceptance criteria for each user story.

Input

• User stories

Output

• Priority rating

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master

Document these user stories in the Scrum Documentation Template.

Break down user stories into development tasks in sprint planning

Your sprint backlog must already contain many small and functional pieces of work. When breaking down user stories into development tasks, consider breaking it down across functional instead of technical boundaries.

Info-Tech recommends a vertical break-down approach!

The individual tasks themselves do not deliver working software and often you run into bottlenecks with breaking down tasks by technical needs. This approach also makes it harder for the product owner to prioritize technical tasks that should be done in a linear fashion.

Source: “10 Powerful Strategies for Breaking Down Product Backlog Items in Scrum (With Cheatsheet)”

Understand the common strategies to a vertical break-down approach

How do you determine how small a development task should be?

There is no hard and fast rule to how small a sprint item must be. This will depend on:

• The length of the sprint.
• The size of the application or project.
• The experience and comfort level of the team.

The experience and comfort level of the team.

Source: “10 Powerful Strategies for Breaking Down Product Backlog Items in Scrum (With Cheatsheet)”

Activity: Build development tasks for user stories in the sprint backlog (sprint planning activity)

3.4.4

Estimated Time: 30 minutes

1. Refer back to the user stories built from the previous activity.
2. Choose a vertical break-down strategy that the team is comfortable with.
3. List all possible development tasks associated with each user story in the sprint backlog.

Input

• User stories
• Vertical break-down strategies

Output

• Development tasks

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master

Document these user stories in the Scrum Documentation Template.

User story estimation

Planning poker: This approach uses the Delphi method where a group collectively estimates the size of a PBI, or user stories, with cards numbered by story points.

Materials: Each participant has deck of cards, containing the numbers of the Fibonacci Sequence.

Typical Participants: Product owner, scrum master (most commonly the facilitator), development team.

Steps:

1. The facilitator will select a user story.
2. The product owner answers any questions about the user story from the group.
3. The group makes their first round of estimates, where each participant individually selects a card, and all selections are revealed simultaneously.
4. If there is consensus, the facilitator records the estimate and moves onto step 1 for another user story.
5. If there are discrepancies, the participants should state their case for their selection, especially high or low outliers, and prompt a constructive debate.
6. The group makes an additional round of estimates, where steps 3-6 are completed until there is a reasonable consensus.
7. If the consensus is the user story is too large (to fit into a sprint) or too undefined, then the user story should be re-written.

The million-dollar question, What constitutes a story point?

A story point is meant to be a unit of relative volume, complexity, risk, and uncertainty, as it relates to the cumulative time required to develop a PBI.

How does one assign a point value to a user story? There is no easy answer outside of leveraging the experience of the team. Sizes are based on relative comparisons to other PBIs or previously developed items. Example: This user story is 3 points because it takes 3 times more effort than that 1 point user story. Therefore, the measurement of a story point is only defined through the team’s experience, as the team matures.

How does one equate a point to a unit of time? First and foremost, for the purposes of backlog prioritization, you don’t need to know time, just its size relative to other PBIs. But for sprint planning, release planning, or any scenario where timing is factor, story points require some form of time-based equivalency, which will differ from team to team. Again, this comes down to experience.

Info-Tech’s approach to measuring value at the user story level

Value is a tricky thing. So is determining how much time and effort should be spent attempting to measure the value of future component, especially when evaluating a PBI multiple times at different levels of granularity.

Info-Tech’s recommendation is as follows:

• Initial intake assessment of value should be intuitive, and therefore require less time and effort.
• Epic level assessment of value should be detailed, involve input from a variety of stakeholders, carefully aligned to product vision and organizational value drivers, and must be measured through metrics and a consistent scoring method (a value calculating tool is most appropriate here).
• User story level assessment of value will be detailed in the sense that each user story should be assigned an individual value, but the valuation per PBI should be less rooted in thorough measurement and metrics, and more so based on the alignment to its epic, which is best determined by the intuitive knowledge of the product owner.

Activity: Estimate the points for your user stories based on the tasks (sprint planning activity)

3.4.5

Estimated Time: 30 minutes

1. Look at all stories to determine how complex they are (high, medium, low).
2. Group stories of like complexity together.
3. Establish the minimum and maximum Fibonacci values that will be used.
4. Pick the lowest complexity story and assign the minimum Fibonacci value to it.
5. Pick the highest complexity story and assign the maximum Fibonacci value to it.
6. Compare all other stories to the lowest and highest valued story to determines values for all other stories.

Input

• User stories
• Development tasks
• Estimation techniques

Output

• Complexity levels
• Fibonacci values

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum Master

Document these user stories in the Scrum Documentation Template.

Have a sprint planning session to establish scope and estimates for your upcoming sprints

Planning takes time – don’t rush this step.

1. The product owner and team review the product backlog and release plan and discuss the high-priority items that must be completed for the upcoming milestone.
2. Break your user stories down into smaller individual tasks. Estimate the number of points of each task using the scheme on the right. Points should be viewed as an indicator of complexity and exponentially increase over time. Accumulate the points of all of the tasks to calculate your user story sizes.
   • Some tools (e.g. Team Foundation Server) estimate tasks by hours and not points. In this situation, consider estimating your tasks in hours and then rolling them up into points at the user story level.
3. Adjust your release plan based on the issues, risks, and tasks that were identified. Remember to leave a bit of buffer in your plan to accommodate unexpected impediments.
4. Break down your milestone into iterations called sprints that range from 1-4 weeks in length. Sprint lengths should be consistent within a given project. Identify the user stories that can be completed within a given sprint and shift your milestones and release plan if necessary. This is your sprint plan.
   • Ideally, a product should be deliverable at the end of a sprint. If this is not feasible, consider having your development artifacts (e.g. UI design, business requirements) reviewed at the end of each sprint.
5. It is common for new tasks to emerge as the team works through each sprint. Once the team makes a commitment, additions and changes must wait until the next sprint unless approved by the product owner.

Point Estimation Scheme

Consider the following scheme for new teams to the points paradigm: 1 point ~ 1 hour, 3 points ~ 0.5 day, 7 points ~ 1-2 days, 13 points ~ 3-4 days. Modify this scheme as necessary.

As teams become more accustomed to this approach, begin transitioning from a days-to-points conversion to tasks-to-points (e.g. code a button on the web UI = 3 points).

Track your team’s performance with burndown charts to achieve transparency of project progress

What are burndown charts?

• They show how much work is remaining for the rest of the sprint.
• They show whether or not you are being realistic about how much you can deliver in a given sprint and reveal the accuracy of your estimates.

How are burndown charts created?

1. Calculate the total number of points committed for the current sprint.
2. Draw your “Plan” burndown line, which will be used as your productivity benchmark as shown in the example on the right.
3. When a user story is completed, update your “Actual” burndown line by subtracting the points of the completed user story from the total number of points left to be completed.

Info-Tech Insight

Give incentives to teams for completing tasks on time and punish those for falling behind their planned burndown through creative means. For example, treats for top performing teams and exercises for poor performing teams.

Measure and communicate success to learn and build momentum

Demonstrate the continual productivity gains achieved through the pilot.

• Measuring the performance metrics of your pilot is important because stakeholders want to know if they are better off with Agile vs. Waterfall.
• High-performing teams are those that are dedicated to improving themselves. They want a way to measure their current performance and improve upon it.
• Communicating success also involves providing stakeholders with a review of challenges faced and how Agile processes and artifacts helped the team to address those challenges.

Learn how to manage the backlog during the pilot. It will impact the accuracy of your measurements.

Info-Tech Insight

Hard metrics can help explain the success of your Agile pilot. Anecdotal evidence from team members should also be used to provide evidence at a team level.

Set realistic expectations for the initial project velocity to allow for institutional learning

Start slow and set reasonable expectations.

• For the first iteration of your Agile pilot, a general consensus is to use one-third of available project implementation time as the baseline value for estimating the velocity of a team. This number allows for meetings, research, vacations, personal time off, and administrative duties.
• If you’re estimating ideal programmer time, then account for non-project time like meetings, email, design, documentation, rework, collaboration, and research.
• Monitor velocity during the first iteration (sprint). If underestimated, velocity in the first iteration will rise as new features are included. If overestimated, velocity will decrease as features are removed. For the second iteration, the scrum team should use the first iteration as a guideline.*

You must know the following to make an initial estimate:

• The number of people participating in the project and next iteration.
• The maximum amount of work any one person can accomplish during a typical time period of the iteration.
• The total number of workdays in the iteration.

*Source: “Best Practices for Effective Velocity Tracking”

Calculate your burndown velocities

Steps to calculate burndown velocities:

1. Calculate your daily points burndown velocities for each sprint, as shown below. Take an average of your actual and planned burndown velocities.
2. Identify the areas where your burndown velocities differ from your planned burndown. Determine why these variances occurred.
3. If applicable, investigate why some of your points were not completely burned down.

Measure sprint burndown variance to help teams surface assumptions

Assess the root cause of your burndown variances to remove assumptions in the future.

• Burndown variances should not be perceived as a bad thing as they provide the basis for a better understanding of actual events as compared to expected ones.
• When addressing burndown variance, ask “why?” multiple times to get at the root cause of the variance. This will help to accelerate future improvements in the process and give stakeholders insights into bottlenecks.
• Variances can reveal if a team has over- or under-committed on user stories for the current sprint. If a team has over-committed, then the release plan may be modified (i.e. pushing off stories to the next sprint) to better reflect the team’s current capabilities. If a team has under-committed, user stories from a future sprint can be brought into the current sprint to keep the team productive.

Common Reasons for Variances

• Poor estimation of tasks by development team.
• Broad project scope definition that generates inaccurate estimations.
• Unclear and ambiguous requirements, leading to features consistently rejected by stakeholders.
• Participation in meetings and other ceremonies that serves little to no value.
• Mid-sprint injections that are not captured in the burndown chart.

Info-Tech Insight

Track your variances for each sprint. Any delta represents a sign that Agile has helped you avoid a potential risk had you used the traditional Waterfall method. Track any team and stakeholder discussions for improving task estimation. This can have an effect on improving existing non-Agile project estimation.

Exercise: Determine the team’s velocity (sprint planning activity)

3.4.6

Estimated Time: 30 minutes

1. Determine the team’s velocity by first identifying the total points committed from historical sprints.

For example:

Sprint 1: total points committed = 12

Sprint 2: total points committed = 9

Sprint 3: total points committed = 9

Average points committed = 10 (team velocity)

2. Refer back to the tasks within each story and the points assigned to them in previous activities. Pull cards with an accumulated total value that does not exceed total team velocity

Input

• User stories
• Team velocity

Output

• Committed user stories for sprint

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master

Document these user stories in the Scrum Documentation Template.

Conduct a daily scrum session during development to measure progress

Use the daily scrum sessions to surface any blockers or risks from completing committed tasks.

Rules of the Scrum

• The daily scrum meetings begin once the sprint has started.
• The scrum should be roughly a 15-minute meeting at the same time and place every day.
• The meeting is led by the scrum master and everyone within the team should be present.
• The scrum master should control the tempo of the scrum to ensure everyone’s time is respected and focus is kept on risks and blockers.
• A log of issues discussed should be kept to serve as a point of continuation the following day.

Topic of the Scrum

Three things should be reported by each team member in a scrum meeting:

• What they have completed since the last scrum meeting.
• What they are currently working on and what they will complete by the next meeting.
• Any blockers, risks, or barriers.

Goal of the Scrum

• Transparency amongst team members so that root issues preventing the team from completing user stories are raised and addressed quickly.
• Updates from the scrum master on resolution of blockers and risks. This helps build integrity into the team.
• No intervention from product owners. It is possible to have a product owner attend a scrum for clarification of requirements but they should not inject new requirements.

Use a scrum board to visually show project progress

The scrum board shows a project’s health and progression during a given sprint. User stories move from left (backlog) to right (completed) on the scrum board.

• The backlog contains the user stories that are ready for development.
• The team commits to a set of user stories for the next sprint.
• When a team is prepared to take on a user story, it is moved to in progress. User stories that are blocked are clearly labeled.
• Once the user story is complete, as per your definition of done, it is moved to completed.

Leverage the Scrum Documentation Template to track the completion of your tasks and user stories after each day of your sprint.

Activity: Build your task board and simulate a daily stand-up

3.4.7

Estimated Time: 30 minutes

1. Identify and select a location for the team’s scrum board.
2. Set up the team scrum board by vertical columns for to do, in progress, tested, and done.
3. Add your committed user stories to the scrum board along with their relevant tasks.
4. Simulate a daily stand-up, facilitated by the scrum master by answering the three questions:
   1. What did I do yesterday?
   2. What am I going to do today?
   3. Are there any roadblocks?

Input

• User stories in sprint backlog

Output

• Scrum board

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master

Leverage the Scrum Documentation Template to track the completion of your tasks and user stories after each day of your sprint.

Hold sprint review sessions to reconfirm expectations

Collaborate, inspect, and adapt the direction of the project as required.

Goal of Sprint Review: Obtain the go-ahead to demonstrate completed features to stakeholders.

• Once the sprint is completed, there is a sprint review with the product owner. The product owner accepts the latest artifacts (e.g. build, design) and gets an understanding of where the project is heading from a risk perspective.
• Another output of this meeting is advice and feedback for the team to incorporate into the next sprint for product improvements.
• Preparation for this review should be brief as the team is only showing the work that has been completed.

Be Realistic With the Outputs of Your Sprints

In some circumstances, sprints may not be sufficient time to complete a tested and deployable build. Consider using your sprint review sessions to review development artifacts (e.g. UI design, business requirements document) that are critical for the progression of your project.

"Most teams underestimated all other demands on their time and achieve less in their first sprint."

– Mike Cohn, Succeeding With Agile: Software Development Using Scrum

Ensure alignment with stakeholder expectations through demonstrations

Involve stakeholders and management in your projects by including them in demonstrations – their constructive feedback will ensure the project is moving in the right direction. Aim to deliver an MVP for each demonstration.

Showcase your MVP for stakeholders to obtain feedback on enhancements or to modify, add, or remove features to meet new business needs.

• Identify key points in your release plan to schedule demonstrations with stakeholders. These points (ideally, at your project milestones) should demonstrate some business value in your solution. Find a balance between the frequency of your demonstrations and your stakeholders’ availability.
  • Focus on demonstrating features that are complete. If you are planning on showing work-in-progress, ensure your stakeholders understand that what they see may change.
• Leverage a proxy if your stakeholders or product owners are unavailable. Ensure that this proxy is up to date with the latest stakeholder needs and engages in regular communication with stakeholders.
• Collaborate with your stakeholders on the enhancements so the changes can be injected and prioritized against your product backlog. Assess and address any impacts these changes have to your release and sprint plans.

Activity: Simulate a sprint review and demo

3.4.8

Estimated Time: 1 hour

1. Refer back to the user stories each team committed to for the sprint, and prepare a wireframe for the acceptance criteria to prove you are done.
2. Practice showcasing the wireframe within your team and center your story around a realistic user solving a problem. Keep in mind that the demo must prove not only that the software works, but also that it is valuable.
3. Teams take turns presenting their demos to other stakeholders and stakeholders choose one option based on the demo:
   • Approve
   • Reject
   • Request for change (goes into future a sprint)

Input

• User stories in sprint backlog
• Acceptance criteria

Output

• Wireframe for user story
• Knowledge and understanding of a demo

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team
• Product owner
• Scrum master
• Other stakeholders

Ensure the stakeholders understand the value of Agile in metrics they appreciate

Points hold little to no value to stakeholders. Traditional metrics, related to budget, deadlines, and scope, will still need to be gathered to effectively and clearly communicate the successes of Agile for further stakeholder buy-in.

• Communicate the metrics at the release level. Release plans contain time-boxed milestones where scope and budget are often defined and set, which is aligned to traditional reporting approaches.
• Avoid mentioning points in stakeholder reports. Points definitions vary from team to team and project to project. Don’t confuse your stakeholders with metrics that are only relevant to your team.

Exercise: List the metrics that would be gathered during your Agile pilot

3.4.9

Estimated Time: 30 minutes

1. List the metrics that you will be gathering during your Agile pilot. Consider the metrics that are used to evaluate your SDLC.
2. Define the metrics and map them to the appropriate pilot goals and guiding principles that were identified earlier. Brainstorm the approaches to collect these metrics.
3. Ask yourself the following questions:
   • Do your stakeholders understand the meaning and interpretation of your metrics?
   • Are your metrics easy to gather but can demonstrate significant value?
   • How are your teams going to use your metrics to continuously improve?

Input

• List of SDLC metrics
• Pilot guiding principles
• User stories

Output

• List of Agile pilot metrics

Materials

• Whiteboard
• Markers

Participants

• Development team

Document results in Info-Tech’s Agile Playbook Template.

Leverage tools to help you track metrics so that you can focus on implementation rather than administration

Electronic tools can help simplify the gathering of metrics for reporting.

• Tracking metrics can become a time-consuming activity. Using an electronic tool allows stakeholders to get visibility into the project and frees up time that would be spent measuring performance.
• Tools can allow distributed teams to contribute their individual metrics for post-analysis on workload across multiple teams.
• Some tools allow you to track communication between team members, which can help track progress of a particular issue.
• Metrics from automation tools can be tied to downstream tools for an analysis of bottlenecks and efficiency across the project lifecycle.

For a list of Agile software vendors, refer to Info-Tech’s Evaluate the Application Lifecycle Management Landscape.

"High velocity projects need an automated tool to track status across teams and geographies. The best tools support bugs tracking and status of development tasks in one system to avoid extra work on data entry by developers."

– Jeff Sutherland, Scrum Handbook

When is Agile software most useful?

1. When geographic distance prevents team members from attending scrum sessions collectively.
2. When the overhead of manually collecting metrics is too high.
3. When an investment has already been made in a tool that supports Agile development.

Hold a sprint retrospective to identify and document issues to be resolved

Aim to learn from past mistakes and pain points, and apply lessons to future sprints.

• The sprint retrospective differs from the sprint review because it is not project-oriented, but process-oriented.
• This step is important in improving the scrum process as each team member has a chance to voice what is working and what is not.
• The scrum master can act as a facilitator for these meetings.

Questions to Ask During Your Retrospectives

• What did you like about the sprint?
• What were you lacking during the sprint?
• What did you learn?
• What do you desire to help improve the process?

Info-Tech Insight

Think of the first sprint as a test run. After the first sprint, the team members should have a better idea of their capacity and what they can realistically achieve in one sprint.

Leverage the Scrum Documentation Template to gauge your team’s performance after each day and sprint. See where improvements can be made to improve your team’s effectiveness and efficiency. Note these in the Project Review table.

Pick an approach to the retrospective that the team agrees on

Mad, Sad, Glad is a popular technique to a retrospective that encourages team members to discuss the emotional aspects of their sprint. It focuses the conversation on how the team feels rather than the events of the sprint.

Sailboat is a popular technique to defining the vision of the team and identifying any problems along the way. Refer here for instructions on the approach.

Starfish is a popular technique to gather data from the team to encourage team members to think about practices and the value the team gets from it. Refer here for instructions on the approach.

Info-Tech Best Practice

No matter your approach to the retrospective, it should always have these two components:

1. Feedback from current sprint to determine success.
2. A team-building component: e.g. improve communication, improve knowledge of Agile framework, and improve interpersonal relationships

Activity: Simulate sprint retrospective

3.4.10

Estimated Time: 30 minutes

1. Identify a retrospective approach that the team agrees upon and wants to use as part of their Agile practices.
2. Set up any materials (e.g. sticky notes, pens) that the team will require to simulate a retrospective.
3. With the scrum master facilitating, conduct a retrospective on the day’s activities you participated in to understand Agile practices.
4. Document any action items on how the team can improve.

Input

• List of retrospective techniques

Output

• Understanding of a retrospective
• Action items for improvement

Materials

• Whiteboard
• Markers
• Sticky notes

Participants

• Development team

Leverage the Scrum Documentation Template to gauge your team’s performance after each day and sprint. See where improvements can be made to improve your team’s effectiveness and efficiency. Note these in the Project Review table.

Realize that moving away from pure or by-the-book Agile practices is common

• Agile should be molded, adjusted, and fitted to your current team’s skillsets, work dynamics, and enterprise standards around compliance and project milestones. One team’s or project’s implementation of Agile may be different from other implementations.
• Agile requires a common understanding of Agile values and practices in your context. This will ensure your Agile initiatives are coordinated and all driving toward the same goal.

Understand that Agile is a learning framework.

• Continuous improvement is a core component of Agile methodologies: learn from your mistakes, roadblocks, and impediments to create customized solutions and processes that mitigate these issues in the future.
• Your Agile implementation should continually evolve as you grow and mature. As new issues manifest themselves within your projects, encourage your project teams to adapt so that communication and productivity improve and the completed product better aligns with business priorities.

Your transformation roadmap to scale Agile will depend on what your reach is

Take a holistic approach to implementing your product-focused Agile transformation

Take a holistic approach to implementing your enterprise-wide Agile Transformation

If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

Book a workshop with our Info-Tech analysts:

• To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.
• Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.
• Contact your account manager (www.infotech.com/account), or email Workshops@InfoTech.com for more information.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

Build team task board and simulate a daily stand-up

This activity involves the Agile pilot team members to understand how to build a task board to use as part of their daily stand-up ceremony. This enables team members to visually represent the progress of their work to the rest of the team and other stakeholders.

List your Agile metrics to gauge success

This activity involves the Agile pilot team to identify and list the relevant metrics that they will be responsible to track and measure on to gauge the success of their Agile pilot. This enables team members to increase transparency of the success of Agile across all stakeholder groups.

Related Info-Tech research

Enable Organization-Wide Collaboration by Scaling Agile

Execute a disciplined approach to rolling out Agile methods in the organization.

Spread Best Practices With an Agile Center of Excellence

Facilitate ongoing alignment between Agile teams and the business with a set of targeted service offerings.

Bibliography

Agile Modeling. Active Stakeholder Participation: An Agile Core Practice.” Agile Modeling. n.d. Web.

Ambler, Scott W. “Where Do Product Owners Come From?” LinkedIn. 21 Nov. 2016. Web.

Ambysoft. “2018 IT Project Success Rates Survey Results.” Ambysoft. 2018. Web.

Beck, Kent, et al. “Manifesto for Agile Software Development.” Agilemanifesto.org. 2001. Web.

Blueprint Software Systems. “10 Ways Requirements Can Sabotage Your Projects Right From the Start.” Blueprint Software Systems. 2012. Web.

Brock, Jon, et al. “Large-Scale IT Projects: From Nightmare to Value Creation.” BCG. 20 May 2015. Web.

Cohn, Mike. Succeeding With Agile: Software Development Using Scrum. Addison-Wesley. 2010. Web.

Denning, Steve. “Ten Agile Axioms That Make Managers Anxious.” Forbes. 17 June 2018. Web.

Denning, Steve. “The 12 Stages Of The Agile Transformation Journey.” Forbes, 4 Nov. 2018. Web.

Dyba, Tore, and Torgeir Dingsøyr. “Empirical Studies of Agile Software Development: A Systematic Review.” Elsevier, ScienceDirect. 24 Jan. 2008. Web.

EDUCAUSE. “Aligning IT Funding Models to the Pace of Technology Change.” EDUCAUSE. 14 Dec. 2015. Web.

Eick, Stephen. “Does Code Decay? Assessing the Evidence from Change Management Data.” IEEE Transactions on Software Engineering, vol. 27, no. 1, Jan. 2001, pp. 1-12. Web.

Hanson, Jeffrey J. “Best Practices for Effective Velocity Tracking.” IBM. 2012. Web.

Harrin, Elizabeth. “Using Milestones in Project Management.” The Balance Careers. 5 Nov. 2018. Web.

Hartman, Bob. “New to Agile? INVEST in Good User Stories.” Agile for All. 14 May 2009. Web.

IAG Consulting. “Business Analysis Benchmark: Full Report.” IAG Consulting. n.d. Web.

Khan, Saeed. “Let’s End the Confusion: A Product Owner Is NOT a Product Manager.” Onproductmanagement.org. 14 July 2017. Web.

Meyer, Bertrand. Agile!: The Good, the Hype and the Ugly. Springer, 2014. Web.

Modi, Sunila, et al. “Negotiating Common Ground in Distributed Agile Development: A Case Study Perspective.” ICGSE. 30 Sept. 2013. Web.

Pichler, Roman. “What Is Product Management?” Romanpichler. 26 Nov. 2014. Web.

Pogrebnoy, Konstantin, and Olga Yatskevich. “Software Project Estimation Practices at CodeTiburon.” Codetiburon. 28 Feb. 2017. Web.

Reifer, Donald J. “Quantitative Analysis of Agile Methods Study (2017): Twelve Major Findings.” InfoQ, 10 Aug. 2017. Web.

Rock, David, and Jeffrey Schwartz. “The Neuroscience of Leadership.” SCRIBD. 2006. Web.

Royce, Dr. Winston W. “Managing the Development of Large Software Systems.” Scf.usc.edu. 1970. Web.

Scaled Agile. “SAFe: Framework for Scaling Agile.” Scaled Agile. 2017. Web. Scrum.org. “What Is a Product Owner?” Scrum.org. n.d. Web.

Sutherland, Jeff. Scrum Handbook. Scrum Training Institute Press. 2010. Web.

VersionOne Inc. “12th Annual State of Agile Report.” VerisonOne. 2018. Web.

Verwijs, Christiaan. “10 Powerful Strategies for Breaking down Product Backlog Items in Scrum (With Cheatsheet).” Medium.com. 1 Apr. 2017. Web.

Wolpers, Stefan. “Agile Failure Patterns in Organizations 2.0.” The Startup. 21 Mar. 2018. Web.

ZDNet. “DevOps and User Experience at Concur.” ZDNet. 31 Jan. 2017. Web.