permalink: /dt/agile

This post covers Agile Transformational Practices (from Driving Digital Transformation, by Isaac Sacolick, AMACOM)

Definitions

What is Scrum?

• Agile teams operate in sprints that are usually one or two weeks in duration and are asked to commit to completing a list of user stories.
• Each story articulates a requirement, how it benefits the user, and a list of pass/fail acceptance criteria.
• Stories are typically grouped together into epics to make it easier for team members to navigate and manage the entire backlog of stories.
• At the end of a sprint, the team demos their completed stories, and the product owner evaluates their completeness.
• Issues are characterized as defects if they impact users, miss business rules, or fail acceptance criteria.
• Technical debt is also captured when the team acknowledges that improvements are needed in the underlying implementation.
• Teams assign a size to each story and then attempt to commit to a consistent velocity of stories, measured as the aggregate of the sizes, every sprint.
• They use daily meetings, called standups, to communicate status and raise any blocks that might impede their ability to complete stories.
• At the end of a sprint, teams usually call a retrospective meeting to discuss process improvements.
• Releases to production can be done every sprint or over multiple sprints.

Technical debt

• concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer

Why Agile?

• Let’s say you know there is a business opportunity and demand for a new application.
• You want to get momentum to define a project and be a partner to determine whether there is a strong business case to implement it.
• The first thing to do is articulate a vision
  • what you’re trying to accomplish (definition of business need and opportunity) and
  • why (what benefits, both financial and performance driven).
• For this example, let’s simplify your options to getting this initiative started given that it’s just an idea without a complete vision.

OPTION 1 - CLASSIC APPROACH

• You go back to the sponsors, assign a business analyst, listen to what is required, and work on requirements and a project plan. It takes a couple of months to have all the meetings with stakeholders to gather requirements, document, and review.
• At the end of the process, you ask your engineering team to estimate a solution, but under business pressure to respond, you allow them only a couple of weeks to complete it. The engineers do the best they can at outlining a technical approach and laying out a whole list of assumptions.
• The technologists feel pressure to provide an inexpensive solution, but they would prefer to use this opportunity to phase out a legacy system.
• Your business stakeholders receive a document outlining a solution and assumptions, and some show up to the business review. But their level of understanding of the details is limited given their expertise.
• At the end of the day, they skip all this detail and look at the bottom-line cost and duration to execute. The engineers have recommended a minimal solution that can be implemented in six months, but the sponsors haven’t read the details and assume they are getting everything they want in a reasonable time frame.
• The team is commissioned to work, and all is good until you are two months into the project and things are starting to go south.
• The project is taking longer than expected, and the team is falling behind. At the same time, market conditions are changing, and the sponsors are asking for new things added to the scope. Your team adjusts, but by month three they are further behind and you must extend the timeline.
• By month four, there are more changes, and the team is getting frustrated having to modify things already developed while sponsors are getting nervous on whether the project will complete at all to their expectations.
• This seesaw of changing requirements and implementation complexities carries on unless the team and sponsors decide to work collaboratively toward a common milestone. In many cases, this doesn’t happen.
• This project methodology where requirements are defined before implementation, known as waterfall is a less successful methodology in an environment where sponsors are challenged to define requirements fully, where changing market requirements require reevaluating implementations, and where the urgency to deliver products faster requires engineering teams to make compromises in their solutions.

OPTION 2 - AGILE

• Start off from the same point, where there is only the identification of an opportunity or need but with no other details.
• Instead of throwing an analyst to work with sponsors on “requirements,” imagine bringing a small team of experts together to brainstorm a vision. That vision focuses on a future point with a defined statement on the opportunity, needs, and benefits.
• By bringing the team together, there is a shared understanding of what the opportunity is and why it’s beneficial.
• The agile methodology requires assigning a team to work with the product owner to identify the most business-critical aspects of the project, the technical risks, and other unknowns. The team then commits to completing deliverables in a relatively short period, usually one to three weeks.
• After this period, the team demos their work and then focuses on the next set of critical items for the one- to three-week period.
• In waterfall, the project team must engage the business manager for a significant amount of time to define requirements.
• Projects are broken into milestones that have no specified rhythm of delivery (some milestones may be weeks, others months) and no requirement or expectation to demo functionality.
• In agile, leadership is getting several significant advantages. Teams can start working on the most critical features and risky technical areas without overtaxing the business sponsors for upfront information.
• The frequency of delivery in one-to three-week “sprints” leads to better execution.
• Let’s say your team does sprints that are two weeks in duration. In three months, they complete six iterations, giving them plenty of time to prove themselves, mature the agile process, and address risks.
• Agile then allows sponsors to prioritize at the beginning of each sprint, enabling a stronger business and IT alignment. The sponsor gets to prioritize based on customer feedback, and the IT team gets frequent and direct engagement from the business sponsor.

Why Agile Is a Key Transformational Practice

• When you sign up to lead transformation, the implication is that you are going to review existing products, business processes, and capabilities and realign to a new vision.
• Transformation is a change management practice, so the organization must enable a culture, philosophy, governance, and practice to manage the change.
• Unfortunately, we no longer live in a static world. We can’t portray our digital business future with certainty since so many market forces are transforming in parallel. So thinking that you can manage transformation the same way we construct buildings, bridges, and rockets in the past is outdated thinking.
• In fact, construction projects are now leveraging elements of agile and lean to enable greater flexibility.
• For some organizations, just adopting basic agile practices is good enough to achieve a higher level of execution. These organizations will define their sprint and release schedule, practice standups, and use tools to document user stories.
• Even at larger scales, just adopting these basic practices provides value as it aligns business stakeholders and provides flexibility to adjust priorities.
• But to transform organizations, you need to evolve agile beyond these basic practices into a disciplined scalable process, a practice that connects other functional areas such as marketing and operations, and organizational change to drive to an agile culture.

Defining Agile Roles and Responsibilities

• A key tenet of the agile manifesto relates to self-organizing teams: “The best architectures, requirements, and designs emerge from self-organizing teams.”
• There’s a wide range of interpretation of what “self-organizing teams” means.
  • The problem with teams that are too self-organizing is that they may lack a full understanding of the business and technology strategy, and the lack of governance may lead teams astray.
  • However, teams that are managed tightly, don’t ask questions, are slow to think out of the box, or get lost working collaboratively finding solutions with ill defined requirements may never achieve results that can drive transformation.
• Teams need basic roles, responsibilities, and governance to be defined in order to be successful. Unlike startups, most organizations fill their agile teams with a mix of people, some with agile experience others with minimal exposure.
• Some organizations rely heavily on offshore or distributed team members, and some larger projects have the complexity of requiring multiple teams. In all these scenarios, you should provide structure to be successful.

SINGLE TEAM AGILE ROLES AND RESPONSIBILITIES

• Structure in agile practices starts with defining basic roles and responsibilities.

• Some of the constructs laid out in this section are standard for agile teams like the role of the product owner and technical lead. But beyond that, agile doesn’t formalize roles within the team.

• I have found that teams need these responsibilities defined to achieve an optimal cadence of delivery, and the structures need to address several different challenges.

• One issue is that the product owner and technical lead have significant responsibilities in agile practices but don’t always have the skill or time to complete all of them.

• Product owners are asked to write stories, but they may not be skilled on writing requirements.

• Technical leaders can become roadblocks if they take on solving all the technical challenges in the backlog.

• Another challenge is that many agile teams today are often distributed and may not be in a single location. Distributed teams can arise for different reasons. You may have a business team in one location and technical team in another.

• You might be working with one or more services providing development or testing team members at different locations. For smaller organizations, you might have fully remote individuals working from home.

• Very large organizations may attempt to implement 24-hour development lifecycles by distributing teams across the globe. Whatever the structure, roles, responsibilities and practices need to be defined and adjusted to the realities of distributed teams.

• The last challenge is how teams balance current sprint execution and future sprint planning. Teams that completely focus on executing the current sprint’s commitments can fail to respond to business stakeholder needs to forecast longer-term timelines and roadmaps.

Team Structure

Product owner

• Defines the vision of the product, the release and the epic.
• Prioritizes epics and stories. Reviews story definition and acceptance criteria.
• Reviews all estimation and seeks out minimal viable solutions.
• Reviews and signs off on completed stories.
• Aggregates customer and operational feedback to reevaluate priorities.

Business analyst (BA)

• Primary responsibility is to write stories, document requirements, and define acceptance criteria.
• Acts as moderator in discussions between the product owner and technical lead in reviewing implementation options and seeking minimal viable solutions.
• Answers questions from the development team during sprints to ensure there is a shared vision on what and how to implement.
• The business analyst is often the best person to lead other documentation efforts.

Technical lead (TL)

• Leads the delivery of the product. Partners with the product owner to define solutions.
• Breaks down epics to stories and partners with the business analyst contributing nonfunctional requirements and technical acceptance criteria.
• Leads review of completed stories for completeness and adherence to technical standards.
• Leads retrospective and captures technical debt.
• Also responsible for getting the team to a predictable velocity and for recommending a balance of functional, technical debt, and defect-fixing stories that lead to on-time releases.

Dev 1, Dev 2, QA 1

• Represent members of the development team who are responsible for reviewing stories, sizing them, committing to getting the sprint, and ensuring that all stories are “done” at the sprint’s completion.
• If you adopt the agile manifesto to its essence, the requirement is for shippable code at the end of every sprint.

Agile planning team

• should spend most of its effort working on priorities, vision, and requirements for the upcoming sprints. Ideally, they are involved only in the current sprint to answer questions and to review the results.

Agile development team

• primarily working on the current sprint.
• When they get toward the end of the sprint, they must dedicate part of their time to review the next sprint’s priorities, ask questions, size stories, and commit.

Roles and responsibilities configuring an agile tool for an initiative

Roles and responsibilities in managing releases