Satisfy Customer with Valuable Software

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Satisfying the customer means delivering valuable software in a timely manner (that is, in the market window) for a reasonable cost. Continually striving to meet elusive customer value is important. Ultimately, the key measure of value for customers is an increase in sales and the continued loyalty of existing customers.

How do you know that you are moving in the right direction of building value? It starts with understanding your customers: who they are and what motivates them. Their profiles include such information as their challenges, their vision for your product, and their buying trends.

Delivering value continues with an effective Sprint Review process where the customer gains an opportunity to review and provide feedback on working software. If customers can sense that their input is valued during the demos, their satisfaction can increase. This is particularly true if the customers see that their feedback from the last demo has been incorporated in the working software of the current version.

In addition, it is beneficial to use the Product Owner (PO) as the delegated voice of the customer to solicit acceptance criteria on what the customer would expect when they see a particular requirement or feature in action. You may also conduct periodic customer surveys to gauge their level of satisfaction with the product or solution.

What actions exhibit “satisfying customer with valuable software”?

• The PO works to understand customer value, constantly prioritizes and grooms the backlog, and discusses customer needs with the team.
• The PO creates customer profiles to recognize motivations.
• The backlog is your single source of requirements (aka value).
• The Customer role reflects how you wish to engage your customers.
• Strategy focuses on delighting the customer.
• Customers are invited to Sprint Reviews to provide feedback and validate what they feel is valuable.
• Acceptance criteria are been captured and met for each user story.
• Customer satisfaction surveys are periodically conducted.
• Criteria are applied to ensure the software is built with quality.
• Customer revenue metrics are captured and reviewed.

What is the level of belief?

• Do you believe in continuous customer engagement, adapting requirements, and validation as a means of building valuable software to satisfy the customer?

Welcoming Change to Requirements

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. From an agile perspective, you embrace change to increase the chances of delivering value to the customer. You understand that change is necessary because you understand that customer needs, market conditions, and general demand change over time.

Welcoming change implies several things. The first is that there is a positive attitude toward change from the team and management. The second is that there is a process that allows change to flow without obstruction. This doesn’t mean that all changes are accepted but that changes are prioritized along with existing requirements in the product backlog and methodically discussed.

What actions exhibit “welcoming change to requirements?”

• The PO continually engages with the customer to identify new requirements or changes to requirements.
• No person or process restricts change.
• The backlog is continually groomed and reprioritized.
• Sprint Planning is applied to introduce the newly prioritized requirements.
• Continuous customer engagement via customer visits and Sprint Reviews are applied.

What is the level of belief?

• Do you have a positive attitude toward change even late in the development cycle?

Frequent/Continuous Delivery

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. “Continuous delivery” refers to the capability of frequently releasing software to the customer when they want it. This ensures that when customers believe there is value from what was built and they want it, it can be delivered instantly. Because timing is critical, the key phrase is “when a customer wants it.” Identifying the elusive customer value means you can release when the customer wants it. If it is delivered too early, the customer may not be ready for it; if it is too late, the market opportunity is missed.

Agile thinking includes a world that is fluid, where changes are continuous and welcome, and teams have the capability of releasing frequently, which applies to the delivery of software. This ability to frequently release highlights theimportance of infrastructure that can help with continuous integration, building, and testing. This ability assumes a level of automation that needs to be in place. Automated testing increases the possibility of testing as much of the functionality as is reasonable, including the capability of performing nonfunctional testing such as performance testing, load testing, and more.

What actions exhibit continuous delivery?

• A release capability to incrementally and rapidly deploy software
• Iterative framework with Sprint Reviews
• Continuous integration supported by merging process and configuration management system
• A continuous build process supported by an automated build management system
• Test automation infrastructure that can support continuous testing

What is the level of belief?

• Do you believe in continuous integration, building, and frequent delivery?

Business and Development Work Together

Business people and developers must work together daily throughout the project. Agile attempts to bring an understanding of business value to the development team. To do this, it attempts to integrate business and development as one team. In traditional methods, there is often little interaction between the business (e.g., product management, sales, and marketing) and development (aka cross-functional team). On the business side, Scrum introduces the PO role and XP introduces the Customer role as the bridge between the customer and the development team. These roles allow for a closer embodiment of the business and development team spirit and avoids fiefdoms and throwing work “over the wall” from one group to another with little interaction.

The intent is to make a sincere effort to build a collaborative, amicable relationship between business and development. Development benefits from a better understanding of what the customer finds valuable. The business side benefits because development will ask for details that business may not have thought about it. In both cases, the result is a product that more closely aligns with what the customer finds valuable.

What actions exhibit business and development working together?

• A dedicated business contact (namely, the PO) who works continuously with the Development team.
• Development comprises a cross-functional team with developers, testers, technical writers, designers, and so on.
• The PO and Development Team work together during Sprint Planning to build a mutual understanding of the requirements.
• The PO and Development Team work together during the demo of the working software and gain customer feedback.
• The Development Team can reach out to the PO as needed throughout the project life cycle.

What is the level of belief?

• Do you believe that business and development should work continuously together as a team?

Trust Motivated Individuals

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivated individuals make for a more engaging and productive workforce with good morale. There are strategies to get employees engaged, continually educated, and building on their strengths. Management values employee opinions, appreciates them, and trusts that they can get the work done. Motivated individuals are empowered, feel ownership of their work, and size their own work.

As part of getting work done, there need to be clear release, sprint, and organizational goals provided by the right people who can energize employees and encourage them to invest more effort in building a better product. Vague goals can reduce commitment and motivation. Increased transparency between management and teams increases communication and promote trust.

What actions exhibit trust of motivated individuals?

• Teams have the ability to make decisions, such as sizing their own work.
• Management trusts team decisions and minimizes command and control.
• Teams are kept whole and members are treated like people, not fungible resources.
• Management provides transparency in decision making.
• Management provides organizational goals such as employee engagement.
• The PO provides release and sprint goals.
• Team members demonstrate their working software during sprint reviews.
• The Scrum Master provides a servant–leader approach.

What is the level of belief?

• Do you believe in motivating employees and trusting them to get the job done?

Promote Face-to-Face Communication

The most efficient and effective method of conveying information to and within a team is face-to-face conversation. Agile puts a premium on face-to-face communication. Because of the nonverbal cues built into communication, there is a benefit of harvesting visual cues during interpersonal interactions. Face-to-face discussion improves the overall communication experience and understanding. From an Agile perspective, a Scrum team (about seven people) should be as collocated as reasonable or should use technology to emulate face-to-face interaction as much as possible.

With communication comes the importance of listening. Listening means hearing and understanding what the other is saying and what they are not saying (hence the importance of nonverbal cues). Determining if silence is because of a lack of understanding, simply not being engaged, or a variety of other reasons should be probed. Another aspect of collaboration is being assertive. Quietly listening often does not lead to building ideas. Therefore, communication is a balance of being a collaborative speaker and a respectful listener.

What actions exhibit promoting face-to-face communication?

• Ideally, individual teams are colocated.
• Teams are kept small (about seven members)
• Rooms are available for face-to-face discussion andcommunication in teams.
• Technologies are used to emulate face-to-face discussion whenever colocation is not possible.
• Listening skills are emphasized.

What is the level of belief?

• Do you believe in the importance of colocation and face-to-face communication?

Working Software as Measure of Progress

Working software is the primary measure of progress. From an agile perspective, working software is the best measure of progress. Working software must be produced at the end of each time-boxed period (sprint). You may use other measures to help gauge progress, such as Sprint Burndown, but they should be minor in relation to the criterion of working software.

The reason for this new thinking on measures is that when you follow waterfall, you may be 50 percent through the project schedule and have no working software. From a customer perspective you haven’t accomplished anything. Although there may be internal benefit to gathering requirements, preparing a plan, and doing design and development work, an external paying customer only values the actual working software. You don’t get credit for in-progress stuff, only the working software.

This is why, at the end of each time-boxed period, working software is delivered and validated with the customer during the demo. In addition, working software must meet done criteria to ensure that it is of high quality.

What actions exhibit working software as a measure of progress?

• Progress is measured by working software.
• Sprint Burndown tracks work done and work remaining.
• Done criteria are established that reflect engineering standards that are applied to user stories.
• Sprint Reviews are conducted to demonstrate the working software and gain customer feedback.

What is the level of belief?

• Do you believe that working software can be produced incrementally and is a measure of progress?

Sustainable Pace

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The concept of sustainable pace has been quantified by Kent Beck, who recommends working no more than 40 hours a week and never working overtime for more than one week at a time (not consecutively). ¹ When you maintain a reasonable pace, you can sustain a constant pace indefinitely. Studies have shown that when you consistently work more than 40 hours in a week, the overtime produces lower-quality software and a reduction in productivity. ²

A team establishes velocity based on a 40-hour work week to determine how much work they can do in a sprint. ³ Using velocity allows the team to empirically determine the amount of work they can build into working software in a given iteration. More important, does management trust the team’s velocity, or do they disregard it and force them to do more?

Another driver for sustainable pace is the concept of social responsibility: the obligation to benefit the people as a whole and maintain a work/life balance. With this in mind, a key to a strong Agile team is the notion that no one succeeds unless everyone succeeds. This promotes team spirit, whereby members collaborate and help each other out so that no one or two people are burdened with extra work while others have free time. To do this, each team member should gain secondary skills so they can ramp up quickly should there be a bottleneck. A side effect of sustainable pace is that it often leads to improved team morale. Folks do not feel burned out and come to work with fresh minds, which can lead to innovative ideas.

What actions exhibit sustainable pace?

• Each member of the team works only 40 hours a week.
• Velocity is used as a measure to define the number of story points a team can complete in an iteration or sprint.
• Management trusts the team velocity.
• Management does not force the team to work longer hours or initiate death marches.
• All team members have secondary skill sets and pitch in when needed.

What is the level of belief?

• Do you believe in sustainable pace where working approximately 40 hours a week is a healthy norm?

Technical Excellence

Continuous attention to technical excellence and good design enhances agility. To strive for technical excellence, you need team members who have knowledge and experience to produce sound architecture, good design, and quality software. It is important to have the capability of making the best technical decisions balancing design, usability, and maintainability. Such capability requires a seasoned and professional team. In Agile, employees should want to do the work in the context of career learning and growth.

To strive for technical excellence, effective done criteria should be establishedthat include engineering standards in design, UX, development, technical writing, configuration management, building, and testing. To achieve quality, it may include implementing various XP practices, such as continuous integration and build, coding standards, pair programming, refactoring, simple design, and test driven development that are applied to improve the technical excellence of a product. In addition, the use of retrospectives help the team reflect on opportunities to build their skills and further achieve technical excellence.

What actions exhibit technical excellence?

• Team members motivate each other toward technical excellence, including sharing technical practices and actively participating in code reviews.
• Team members may apply continuous integration and build, coding standards, pair programming, simple design, refactoring, code reviews, and test-driven development.
• Team members apply done criteria that include engineering disciplines’ need to deliver a quality product.
• Team members employ learning plans that include a focus on technical excellence that are actively managed.

What is the level of belief?

• Do you believe in applying technical practices that promote technical excellence and provide technical educational opportunities for employees?

Simplicity

Simplicity—the art of maximizing the amount of work not done—is essential. Striving for eliminating unnecessary work is the goal. This should include identifying the minimum amount of features for a customer release (MVP) for it to be successful. It should include reducing non-value-added work that team members are asked to do. It may involve reducing unnecessary steps of a process to deploy a release.

To simplify, you need to proactively remove the seven wastes in software development as defined by Mary and Tom Poppendiek and discussed in Chapter 6: eliminating partially done work, extra features, the need to relearn, hand-offs, task switching, delays, and bugs.

Agile thinking focuses on short iterations and small increments. This way you can fail fast, learn, eliminate waste, and then succeed more quickly. You may also right-size your documentation with a focus on documenting decisions and why you made them.

What does this look like in action?

• There is continuous focus on staying lean and removing waste via retrospectives.
• During demonstrations, customers are asked not only what they need but what they don’t need.
• The PO applies continuous prioritization via the backlog with a focus on minimum viable product (MVP).
• Documentation is right-sized and includes key decisions and their rationales.

What is the level of belief?

• Do you believe in simplicity, removing waste, and continuously prioritizing requirements based on customer value?

Self-Organizing Teams

The best architectures, requirements, and designs emerge from self-organizing teams. Self-organizing teams have a combination of greater ownership and responsibility to achieve a common goal of building valuable software and reducing dependency on management. The team has the authority to be self-organizing and make decisions regarding architecture, requirements, and design as they evolve the product. The team needs to be cross-functional so that they have the skills and talent to make the decisions to develop the product.

A self-organized team moves away from the command-and-control hierarchy in which one person assigns the work. Instead, a self-organizing structure is one in which everyone participates in decision making and volunteering for work from the backlog. This is easier said than done. Therefore, prior to considering Agile, an assessment of the openness of the culture is helpful for gauging the starting point.

Having self-organizing teams also means thinking beyond the individual, since this can constrain collaboration and the team mindset. The focus should be on instilling team spirit: “You only succeed if the team succeeds.” Rewards should be team-based to drive the notion home.

The team notion also means hierarchy—such as title, levels, grades, heroes, and egos—needs to be removed as barriers to team success. Instead, promote equality among roles. Treating everyone on the team as equals leads to more engaged members. Nonetheless, team members should respect the fact that some people have more experience in certain areas and others can gain from this experience.

• What actions exhibit self-organizing teams?
• The team makes the decisions about its work, specifically regarding architecture, requirements, design, and sizing or estimating.
• Cross-functional teams include the right mix of skills among developers, testers, technical writers, UX designers, the PO, and the Scrum Master.
• There is no hierarchy on the team, although levels of skills and experience are respected.
• Rewards are given at the team level.
• Team members pull work from the backlog at their own initiative, rather than being assigned to it by their functional manager.
• Management reduces command and control and provides boundaries of authority.
• Management articulates goals to help the team focus their work and make their own decisions.

What is the level of belief?

• Do you believe in self-organizing teams who have authority to make their own decisions, manage their own work, and are rewarded as a team?

Reflection for Improvement

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The reflection for improvement is critical to the adaptive framework and the Agile mindset. Although what has occurred cannot be undone, reflecting on it can lead to action that will prevent the issue from recurring. With this in mind, the team should apply a periodic retrospective to reflect on the previous time-box of activity and become more effective in the future.

Remember, the team is self-organizing, so they own the practices, techniques, rituals, and particularly the behaviors. A key to real improvement is that team members are willing to let their guards down and be open and honest with each other. Otherwise, only the more superficial areas are discussed. Also, retrospectives should be private and closed sessions so “dirty laundry” can be discussed. The Scrum Master may act as the facilitator so that it is kept professional with the goal of identifying actions for improvement. Another key is that the team commits to support continuous improvement.

It may be important for teams to use root-cause analysis techniques such as Ishikawa (fishbone) diagrams to identify the cause of specific issues. In addition, Agile applies an empirical approach whereby data can be used to identify areas for improvement and help in decision making based on observation and experimentation. However, it is for the team to make the commitment to adapt and improve.

What actions exhibit reflection for improvement?

• A private team retrospective is used to identify and prioritize areas for improvement.
• The team is open and honest so that real improvement can be made.
• Retrospectives are conducted periodically.
• The team commits to implementing improvement actions.
• Retrospective actions are tracked, and progress is discussed in the retrospective session.

What is the level of belief?

• Do you believe in reflection activities and empowering the team to make the improvements?