20+ Benefits of Agile Project Management 2019
In this blog, we explain the 20+ benefits of agile project management and its quality factors. And also discuss how Agile project teams utilize Agile methods for business benefits and Profits in 2019. Agile methods have excellent safeguards to make sure that quality is as high as possible.
Better Product Quality
Projects exist to build great products and purpose-driven outcomes. Agile methods have excellent safeguards to make sure that quality is as high as possible. Agile project teams help ensure quality by doing the following:
Take a proactive approach to quality to prevent product problems.
Embrace technological excellence, good design, and sustainable development.
Define and elaborate requirements just in time so that knowledge of product features is as relevant as possible.
Build acceptance criteria into user stories so that the development team better understands them and the product owner can accurately validate them.
Incorporate continuous integration and daily testing into the development process, allowing the development team to address issues while they’re fresh.
Take advantage of automated testing tools to develop during the day, test overnight, and fix defects in the morning.
Conduct sprint retrospectives, allowing the scrum team to continuously improve processes and work.
Complete work using the definition of done: developed, tested, integrated, and documented.
Now we discuss all 20+ Key Benefits of Agile Project Management:
Higher Customer Satisfaction
Agile project teams are committed to producing products that satisfy customers. Agile approaches for happier project sponsors include the following:
Collaborate with customers as partners and keep customers involved and engaged throughout projects. Have a product owner who is an expert on product requirements and customer needs.
Keep the product backlog updated and prioritized to respond quickly to change.
Demonstrate working functionality to customers in every sprint review.
Deliver products to market quicker and more often with every release.
Possess the potential for self-funding projects.
Agile project management techniques virtually eliminate the chance of absolute project failure — spending large amounts of time and money with no return on investment. Agile project teams run projects with lower risk by doing the following:
Develop in sprints, ensuring a short time between initial project investment and either failing fast or knowing that a product or an approach will work. Always have a working, integrated product, starting with the first sprint, so that some value is added as shippable functionality every sprint, ensuring an agile project won’t fail completely.
Develop requirements according to the definition of done in each sprint so that project sponsors have completed, usable functionality, regardless of what may happen with the project in the future. Provide constant feedback on products and processes through the following:
Daily scrum meetings and constant development team communication
Regular daily clarification about requirements and review and acceptance of features by the product owner
Sprint reviews, with stakeholder and customer input about completed product functionality
Sprint retrospectives, where the development team discusses process improvement
Releases, where the end user can see and react to new features on a regular basis
Generate revenue early with self-funding projects, allowing organizations to pay for a project with little up-front expense.
Increased Collaboration and Ownership
When development teams take responsibility for projects and products, they can produce great results. Agile development teams collaborate and take ownership of product quality and project performance by doing the following:
Make sure that the development team, the product owner, and the scrum masterwork closely together on a daily basis. Conduct goal-driven sprint planning meetings, allowing the development team to commit to the sprint goal and organize its work to achieve it.
Hold daily scrum meetings led by the development team, where development team members organize around work completed, future work, and roadblocks.
Conduct sprint reviews, where the development team can demonstrate and discuss the product directly with stakeholders.
Conduct sprint retrospectives, allowing development team members to review past work and recommend better practices with every sprint.
Work in a collocated environment, allowing for instant communication and collaboration among development team members.
Make decisions by consensus, using techniques such as estimation poker and the fist of five. You can find out how development teams estimate effort for requirements, decompose requirements. To discover more about sprint planning and daily scrum meetings.
More Relevant Metrics
The metrics that agile project teams use to estimate time and cost, measure project performance and make project decisions are often more relevant and more accurate than metrics on traditional projects.
Agile metrics should encourage sustainable team progress and efficiency in a way that works best for the team to deliver value to the customer early and often. On agile projects, you provide metrics by doing the following:
Determine project timelines and budgets based on each development team’s actual performance and capabilities.
Make sure that the development team that will be doing the work, and no one else, provide effort estimates for project requirements.
Use relative estimates, rather than hours or days, to accurately tailor estimated effort to an individual development team’s knowledge and capabilities.
Refine estimated effort, time, and cost on a regular basis, as the development team learns more about the project.
Update the sprint burndown chart every day to provide accurate metrics about how the development team is performing within each sprint.
Compare the cost of future development with the value of that future development, which helps project teams determine when to end a project and redeploy capital to a new project.
You might notice that velocity is missing from this list. A velocity is a tool you can use to determine timelines and costs, but it works only when tailored to an individual team.
The velocity of Team A has no bearing on the velocity of Team B. Also, velocity is great for measurement and trending, but it doesn’t work as a control mechanism. Trying to make a development team meet a certain velocity number only disrupts team performance and thwarts self-management.
Improved Performance Visibility
On agile projects, every member of the project team has the opportunity to know how the project is going at any given time. Agile projects can provide a high level of performance visibility by doing the following:
Place a high value on open, honest communication among the scrum team, stakeholders, customers, and anyone else in an organization who wants to know about a project. Provide daily measurements of sprint performance with sprint backlog updates. Sprint backlogs can be available for anyone in an organization to review.
Provide daily insight into the development team’s immediate progress and roadblocks through the daily scrum meeting. Although only the development team may speak at the daily scrum meeting, any member of the project team may attend.
Physically display progress by using task boards and posting sprint burndown charts in the development team’s work area every day. Demonstrate accomplishments in sprint reviews.
Anyone within an organization may attend a sprint review. Improved project visibility can lead to greater project control and predictability, as described in the following sections.
Increased Project Control
Agile project teams have numerous opportunities to control project performance and make corrections as needed because of the following: Adjusting priorities throughout the project allows the organization to have fixed-time and fixed-price projects while accommodating change.
Embracing change allows the project team to react to outside factors such as market demand.
Daily scrum meetings allow the scrum team to quickly address issues as they arise.
Daily updates to sprint backlogs mean sprint burndown charts accurately reflect sprint performance, giving the scrum team the opportunity to make changes the moment it sees problems.
Face-to-face conversations remove roadblocks to communication and issue resolution.
Sprint reviews let project stakeholders see working products and provide input about the products before release.
Sprint retrospectives enable the scrum team to make informed course adjustments at the end of every sprint to enhance product quality, increase development team performance, and refine project processes.
The many opportunities to inspect and adapt throughout agile projects allow all members of the project team — the product owner, development team, scrum master, and stakeholders — to exercise control and ultimately create better products.
Improved Project Predictability
Agile project management techniques help the project team accurately predict how things will go as the project progresses. Here are some practices, artifacts, and tools for improved predictability:
Keeping sprint lengths and development team allocation the same throughout the project allows the project team to know the exact cost for each sprint.
Using individual development team speed allows the project team to predict timelines and budgets for releases, the remaining product backlog, or any group of requirements.
Using the information from daily scrum meetings, sprint burndown charts, and task boards allows the project team to predict performance for individual sprints.
Customized Team Structures
Self-management puts decisions that would normally be made by a manager or the organization into scrum team members’ hands. Because of the limited size of development teams — which consist of three to nine people — agile projects can have multiple scrum teams on one project if necessary.
Self-management and size-limiting mean that agile projects can provide unique opportunities to customize team structures and work environments. Here are a few examples:
Development teams may organize themselves into groups with specific skills or that work on specific parts of the product system and features. Development teams may organize their team structure around people with specific work styles and personalities. Organization around work styles provides these benefits:
Allows team members to work the way they want to work
Encourages team members to expand their skills to fit into teams they like
Helps increase team performance because people who do good work like to work together and naturally gravitate toward one another
Scrum teams can make decisions tailored to provide a balance between team members’ professional and personal lives. Ultimately, scrum teams can make their own rules about whom they work with and how they work.
The idea of team customization allows agile workplaces to have more diversity. Organizations with traditional management styles tend to have monolithic teams where everyone follows the same rules.
Agile work environments are much like the old salad bowl analogy. Just as salads can have ingredients with wildly different tastes that fit in to make a delicious dish, agile projects can have people on teams with very diverse strengths that fit in to make great products.
Dedicated Team Members
we talk about the importance of dedicated team members — product owner, development team members, as well as scrum master — to a single project at a time. This is especially critical at the beginning when the scrum team and the rest of the organization are still learning what it means to value agility and embody agile principles.
If team members are jumping between project contexts hourly, daily, weekly, or even monthly, the focus on getting agile techniques right is minimized at the expense of just trying to keep up with multiple task lists.
Also, the time lost due to the continual cognitive demobilization and remobilization involved with task switching is very costly to each project involved.
if you think you don’t have enough people to dedicate to your scrum teams, you definitely don’t have enough people to thrash them across multiple projects simultaneously. The American Psychological Association reports that task switching wastes as much as 40 percent of the time.
The Agile Manifesto lists individuals and interactions as the first value. The way you get this value right is by collocating team members to be able to have clear, effective, and direct communication throughout a project.
we talk about collocation as the first crucial element of an agile environment. Bell Laboratories showed a fifty-fold improvement in productivity simply by getting individuals and interactions right through collocation. With this success factor addressed adequately, customer collaboration, working functionality, and responding effectively to change become much more of a reality.
Development teams cannot develop at the rate technology and market conditions change if they have to manually test their work every time they integrate new pieces of functionality throughout the sprint.
The longer teams rely on manual testing, the larger the holes in test coverage become — manual testing simply takes too long and in reality becomes spot-checking. Without automation, scrum teams will struggle to completely deliver value in every sprint.
Enforced Definition of Done
Ending sprints with non-shippable functionality is an anti-pattern to becoming agiler. Your definition of done should clarify the following:
The environment in which the functionality should be integrated
The types of testing
The types of required documentation
The scrum team should also enforce its definition of done. If scrum teams tell their stakeholders that they are done after a sprint, but an aspect of the definition of done is not met, the work to finish meeting the definition of done must be added to the next sprint, taking capacity away from working on new valuable product backlog items. This scenario is a Ponzi scheme.
Development teams get to do by swarming on user stories — working on one user story together at a time until it is complete before starting the next. Developers hold each other accountable by ensuring that all rules for their definition of done are satisfied before starting a new user story.
Product owners review completed work against the scrum team’s definition of done as soon as developers complete it, and the scrum master ensures that developers resolve issues rejected by the product owner before moving on to new user stories.
Clear Product Vision and Roadmap
Although the product owner owns the product vision and product roadmap, many people have the responsibility to ensure the clarity of these agile artifacts.
Product owners need access to stakeholders and customers at the beginning during project planning as well as throughout the project to ensure that the vision and roadmap continually reflect what the customer and market need. Purpose-driven development delivers business and customer value and mitigates risk effectively.
Without a clear purpose, people wonder and lack ownership. When all team members understand the purpose, they come together. Remember the agile principle, “The best architectures, requirements, and designs emerge from self-organizing teams.”
Product Owner Empowerment
The product owner’s role is to optimize the value produced by the development team. This product owner responsibility requires someone to be knowledgeable about the product and customer, available to the development team throughout each day.
And empowered to make priority decisions and give clarification at the moment so that development teams don’t wait or make inappropriate decisions for the product’s direction.
Although all roles on the scrum team are vital and equally important, an unempowered and ineffective product owner usually causes scrum teams to ultimately fail at delivering the value customers need from the team.
You probably won’t start your first agile project with a development team that has the ideal level of skills required for every requirement on your product backlog.
However, the goal should be to achieve skill coverage as soon as possible. Your team will also be challenged to meet its sprint goal if you have single points of failure on any one skill, including testing.
From day one, you need developers on your team with the intellectual curiosity and interest to learn new things, to experiment, to mentor and to receive mentoring, and to work together as a team to get things to do as quickly as possible.
Scrum Master Clout
As you depart from command and control leadership to empower the people doing the work to make decisions, servant leadership provides the solution. With formal authority, a scrum master would be viewed as a manager — someone to report to.
Scrum masters should not be given formal authority but should be empowered by leadership to work with members of the scrum team, stakeholders, and other third parties to clear the way so that the development team can function unhindered.
If scrum masters have organizational clout, which is informal and is a socially earned ability to influence, they can best serve their teams to optimize their working environment.
Provide training and mentorship to ensure that your scrum masters develop the soft skills of servant leadership and put off the tendencies of commanding and directing.
Management Support for Learning
When executive leaders decide to become agile, their mindset has to change. Too often we see leadership directives without any follow-through for supporting the learning process to implement the changes.
It is unrealistic to expect all the benefits of following agile principles after the first sprint. we talk about choosing an appropriate agile pilot project, one with leeway to stumble a bit at first as everyone learns a new way of working together.
The bottom line: If support for learning is merely lip service, scrum teams will pick up on it early, will lose motivation to try new things, and will go back to waiting for top-down directives on how to do their job.
What’s Different about Agile Quality?
Quality refers to whether a product works, and whether it fulfills the project stakeholders’ needs. Quality is an inherent part of agile project management Those principles follow:
Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
These principles emphasize creating an environment where agile teams are able to produce valuable, working functionality. Agile approaches encourage quality both in the sense of products working correctly and meeting the needs of project stakeholders.
Another difference in quality on agile projects is the multiple quality feedback loops throughout a project, you see the different types of product feedback a scrum team receives in the course of a project. The development team can immediately incorporate this feedback into the product, increasing product quality on a regular basis.
Managing Agile Quality
Agile development teams have the primary responsibility for quality on agile projects. The responsibility for quality is an extension of the responsibilities and freedoms that come with self-management.
When the development team is free to determine its development methods, the development team is also responsible for ensuring that those methods result in quality work.
Organizations often refer to quality management as a whole as quality assurance or QA. You may see QA departments, QA testers, QA managers, QA analysts, and all other flavors of QA-prefixed titles to refer to people who are responsible for quality activities.
QA is also sometimes used as shorthand for testing, as in “we performed QA on the product” or “now we are in the QA phase.” Quality control (QC) is also a common way to refer to quality management.
The other members of the scrum team — the scrum master and the product owner — also play parts in quality management. Product owners provide clarification on requirements and also accept those requirements as being done throughout each sprint.
Scrum masters help ensure development teams have a work environment where the people on development teams can work to the best of their abilities.
Luckily, agile project management approaches have several ways to help scrum teams create quality products. In this section, you see how testing in sprints increases the likelihood of finding defects and reduces the cost of fixing them.
You gain an understanding of the many ways agile project management proactively encourages quality product development. You see how inspecting and adapting on a regular basis addresses quality. Finally, you find out how automated testing is essential to delivering valuable products continuously throughout an agile project.
Quality and the sprint
Quality management is a daily part of agile projects. Scrum teams run agile projects in sprints, short development cycles that last one to four weeks. Each cycle includes activities from the different phases of a traditional project for each user story in the sprint: requirements, design, development, testing, and integration for deployment.
Here’s a quick riddle: Is it easier to find a quarter on a table or in a stadium? Obviously, the answer is a table. Just as obvious is that it is easier to find a defect in 100 lines of software code than in 100,000 lines.
Iterative development makes quality product development easier. Scrum teams test throughout each sprint Notice that testing begins in the first sprint, right after developers start creating the first requirement in the project.
When development teams test throughout each sprint, they can find and fix defects very quickly. With agile project management, development teams create product requirements, immediately test those requirements, and fix any problems immediately before considering the work done.
Instead of trying to remember how to fix something they created weeks or months ago, development teams are, at the most, fixing the requirement they worked on one or two days earlier.
Testing every day on an agile project is a great way to ensure product quality. Another way to ensure product quality is to create a better product from the start. The next section shows you different ways that agile project management helps you avoid errors and create an excellent product.
An important and often-neglected aspect of quality is the idea of preventing problems. A number of agile approaches allow and encourage scrum teams to proactively create quality products. These practices include
Emphasis on technical excellence and good design
Incorporation of quality-specific development techniques into product creation
Daily communication between the development team and the product owner
Acceptance criteria built into user stories
Face-to-face communication and collocation
Regular inspection and adaption of work and behavior
The following sections provide a detailed look at each of these proactive quality practices. Quality means both that a product works correctly and that the product does what the project stakeholders need it to do. Continuous attention to technical excellence and good design
Agile teams focus on technical excellence and good design because these traits lead to valuable products. How do development teams provide great technical solutions and designs?
One way that development teams provide technical excellence is through self-management, which provides them with the freedom to innovate technically. Traditional organizations may have mandatory technical standards that may or may not make sense for a given project.
Self-organizing development teams have the freedom to decide whether a standard will provide value in creating a product, or if a different approach will work better. Innovation can lead to good design, technical excellence, and product quality.
Self-management also provides development teams with a sense of product ownership. When people on development teams feel a deep responsibility for the product they’re creating, they often strive to find the best solutions and execute those solutions in the best way possible.
Nothing is more sophisticated than a simple solution.
Organizational commitment also plays a role in technical excellence. Some companies and organizations, regardless of their project management approaches, have a commitment to excellence.
Think about the products that you use every day and associate with quality; chances are those products come from companies that value good technical solutions.
If you’re working on an agile project for a company that believes in and rewards technical excellence, enacting this agile principle will be easy. Other companies may undervalue technical excellence; agile project teams at these companies may struggle when trying to justify training or tools that will help create better products.
Some companies do not make the connection between good technology, good products, and profitability. Scrum masters and product owners may need to educate their companies on why good technology and design are important and may need to lobby to get development teams what they need to create a great product.
Don’t confuse technical excellence in using new technologies for the sake of using something new or trendy. Your technology solutions should efficiently support the product needs, not just add to a resume or a company skills profile.
By incorporating technical excellence and good design into your everyday work, you create a quality product that you are proud of.
Quality development techniques
During the past several decades of software development, the motivation to be more adaptive and agile has inspired a number of agile development techniques that focus on quality. This section provides a high-level view of a few extreme programming (XP) development approaches that help ensure quality proactively.
Many agile quality management techniques were created with software development in mind. You can adapt some of these techniques when creating other types of products, such as hardware products or even building construction.
If you’re going to work on a non-software project, read about the development methods in this section with adaptability in mind:
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Test-driven development (TDD):
This development method begins with a developer creating a test for the requirement he or she wants to create. The developer then runs the test, which should fail at first because the functionality does not yet exist.
The developer develops until the test passes, and then refactors the code — takes out as much code as possible, while still having the test pass.
With TDD, you know that the newly created functionality of a requirement works correctly because you test while you create the functionality and develop the functionality until the test passes.
Pair programming: With pair programming, developers work in groups of two. Both developers sit at the same computer and work as a team to create one product requirement. The developers take turns at the keyboard to collaborate.
Usually, the one at the keyboard takes a direct tactical role, while the observing partner takes a more strategic or navigating role, looking ahead and providing in-the-moment feedback.
Because the developers are literally looking over one another’s shoulder, they can catch errors quickly. Pair programming increases quality by providing instant error checks and balances.
Peer review: Sometimes called peer code review, a peer review involves members of the development team reviewing one another’s code. Like pair programming, peer reviews have a collaborative nature; when developers review each other’s finished products, the developers work together to provide solutions for any issues they find.
If development teams don’t practice pair programming, they should at least practice peer reviews, which increase quality by allowing development experts to look for structural problems within product code.
Collective code ownership: In this approach, everyone on the development team can create, change, or fix any part of the code on the project. Collective code ownership can speed up development, encourage innovation, and with multiple pairs of eyes on the code, help development team members quickly find defects.
Continuous integration: This approach involves the creation of an integrated code builds one or more times each day. Continuous integration allows members of the development team to check how the user story that the development team is creating works with the rest of the product.
Continuous integration helps ensure quality by allowing the development team to check for conflicts regularly. Continuous integration is essential to automated testing on agile projects; you need to create a code build at the end of the day before running automated tests overnight.
On an agile project, the development team decides which tools and techniques will work best for the project, the product, and the individual development team.
Many agile software development techniques help ensure quality, and there is a lot of discussion and information about these techniques in the community of people who use agile project management approaches. We encourage you to learn more about these approaches if you’re going to work on an agile project, especially if you’re a developer.
The product owner and development team
Another aspect of agile project management that encourages quality is the close relationship between the development team and the product owner. The product owner is the voice of the business needs for the product.
In this role, the product owner works with the development team every day to ensure that the functionality meets those business needs.
During the planning stages, the product owner’s job is to help the development team understand each requirement correctly. During the sprint, the product owner answers questions that the development team has about requirements and is responsible for reviewing functionality and accepting them as done.
When the product owner accepts requirements, he or she ensures that the development team correctly interpreted the business need for each requirement and that the new functionality performs the task that it needs to perform.
In waterfall projects, feedback loops between developers and business owners are less frequent, so a development team’s work typically strays from the original product goals set in the product vision statement.
A product owner who reviews requirements daily catches misinterpretations early. The product owner can then set the development team back on the right path, avoiding a lot of wasted time and effort.
User stories and acceptance criteria
Another proactive quality measure on agile projects is the acceptance criteria you build into each user story, we explain that a user story is one format for describing product requirements. User stories increase quality by outlining the specific actions the user will take to correctly meet business needs.
Even if you don’t describe your requirements in a user story format, consider adding validation steps to each of your requirements. Acceptance criteria don’t just help the product owner review requirements; they help the development team understand how to create the product in the first place.
Have you ever had a conversation with someone and known, just by looking at that person’s face, that he or she didn’t understand you? face-to-face conversations are the quickest, most effective form of communication.
This is because humans convey information with more than just words; our facial expressions, gestures, body language, and even where we are looking contribute to communicating and understanding one another.
Face-to-face communication helps ensure quality on agile projects because it leads to a better interpretation of requirements, roadblocks, and discussions between scrum team members. Regular face-to-face communication requires a collocated scrum team.
Chances are, at some point in your life, you’ve found yourself working or studying long hours for an extended period of time. You may have even pulled an all-nighter or two, getting no sleep at all for a night. How did you feel during this time? Did you make good decisions? Did you make any silly mistakes?
Unfortunately, many teams on traditional projects find themselves working long, crazy hours, especially toward the end of a project, when a deadline is looming and it seems like the only way to finish is to spend weeks working extra-long days.
Those long days often mean more problems later, as team members start making mistakes — some silly, some more serious — and eventually burn out.
On agile projects, scrum teams help ensure that they do quality work by creating an environment where members of the development team sustain a constant working pace throughout the project.
Working in sprints helps sustain a constant working pace; when the development team chooses the work it can accomplish in each sprint, it shouldn’t have to rush at the end.
The development team can determine what sustainable means for itself, whether that means working a regular 40-hour workweek, a schedule with more or fewer days or hours, or working outside a standard nine-to-five time frame.
If your fellow scrum team members start coming to work with their shirts on inside out, you might want to double-check that you’re maintaining a sustainable development environment.
Keeping the development team happy, rested, and able to have a life outside of work can lead to fewer mistakes, more creativity and innovation, and better over-all products.
Being proactive about quality saves you a lot of headaches in the long run. It is much easier and more enjoyable to work on a product with fewer defects to fix. The next section discusses an agile approach that addresses quality from both a proactive and a reactive standpoint: inspect and adapt.
Quality through regular inspecting and adapting
The agile tenet of inspecting and adapt is key to creating quality products. Through-out an agile project, you look at both your product and your process (inspect) and make changes as necessary (adapt).
In the sprint review and sprint retrospective meetings, agile project teams regularly step back and review their work and methods and determine how to make adjustments for a better project. Following is a quick overview of how these meetings help ensure quality on agile projects.
In a sprint review, agile project teams review requirements completed at the end of each sprint. Sprint reviews address quality by letting project stakeholders see working requirements and provide feedback on those requirements throughout the course of the project.
If a requirement doesn’t meet stakeholder expectations, the stakeholders tell the scrum team immediately. The scrum team can then adjust the product in a future sprint. The scrum team can also apply its revised understanding of how the product needs to work on other product requirements.
In a sprint retrospective, scrum teams meet to discuss what worked and what might need adjusting at the end of each sprint. Sprint retrospectives help ensure quality by allowing the scrum team to discuss and immediately fix problems.
Sprint retrospectives also allow the team to come together and formally discuss changes to the product, project, or work environment that might increase quality.
The sprint review and sprint retrospective aren’t the only opportunities for inspecting and adapting for quality on an agile project. Agile approaches encourage reviewing work and adjusting behavior and methods throughout each work-day. Daily inspecting and adapting everything you do on the project help ensure quality.
Another way to manage and help assure quality on an agile project is to use automated testing tools. The next section explains why automated testing is important to agile projects and how to incorporate automated testing into your project.
Automated testing is the use of software to test your product. Automated testing is critical to agile projects. If you want to quickly create software functionality that meets the definition of done — coded, tested, integrated, and documented — you need a way to quickly test each piece of functionality as it’s created. Automated testing means quick and robust testing on a daily basis.
Agile teams continually increase the frequency with which they automatically test their system so they can continually decrease the time it takes them to complete and deploy new valuable functionality to their customers. Project teams won’t become agile without automated testing. Manual testing simply takes too long.
Throughout this blog, we explain how agile project teams embrace low-tech solutions. Why, then, is there a section in this blog about automated testing, a rather high-tech quality management technique?
The answer to this question is efficiency. Automated testing is like the spell-check feature in word-processing programs. As a matter of fact, spell-checking is a form of automated testing. In the same way, automated testing is much quicker and often more accurate — thus, more efficient — method of finding software defects than manual testing.
To develop a product using automated testing, development teams develop and test using the following steps:
Develop code and automated tests in support of user stories during the day.
Create an integrated code build at the end of each day.
Schedule the automated testing software to test the newest build overnight.
Check the automated test results first thing each morning.
Fix any defects immediately.
Comprehensive code testing, while you’re sleeping, is cool.
Automated testing allows development teams to take advantage of non-working time for productivity and to have rapid create-test-fix cycles. Also, the automated testing software can often test requirements quicker and with more accuracy and consistency than a person testing those requirements. Today’s market has a lot of automated testing tools.
Some automated testing tools are open-source and free; others are available for purchase. The development team needs to review automated testing options and choose the tool that will work best.
Automated testing changes the work for people in quality roles on the development team. Traditionally, a large part of a quality management person’s work involved manually testing products.
The tester on a traditional project would use the product and look for problems. With automated testing, however, quality activities largely involve creating tests to run on automated testing software. Automated testing tools augment, rather than replace, people’s skills, knowledge, and work.
It is still a good idea to have humans periodically check that the requirements you’re developing work correctly, especially when you first start using an automated testing tool.
Any automated tool can have hiccups from time to time. By manually double-checking (sometimes called smoke-testing) small parts of automated tests, you help avoid getting to the end of a sprint and finding out that your product doesn’t work as it should.
You can automate almost any type of software test. If you’re new to software development, you may not know that there are many different types of software testing. A small sample includes the following:
Unit testing: Tests individual units, or the smallest parts, of the product code.
Regression testing: Tests an entire product from start to finish, including the requirements you have tested previously.
User acceptance testing: Product stakeholders or even some of the product’s end users review a product and accept it as complete.
Functional testing: Tests to make sure the product works according to acceptance criteria from the user story.
Integration testing: Tests to make sure the product works with other parts of the product.
Enterprise testing: Tests to make sure the product works with other products in the organization, as necessary.
Performance testing: Tests how fast a product runs on a given system under different scenarios.
Load testing: Tests how well a product handles different amounts of concurrent activity.
Smoke testing: Tests on small but critical parts of code or of a system to help determine if the system as a whole is likely to work.
Static testing: Focuses on checking code standards, rather than working software.
Automated testing works for these tests and the many other types of software tests out there.
As you may understand by now, quality is an integral part of agile projects. Quality is just one factor, however, that differentiates risk on agile projects from traditional projects. In the next sections, you see how risk on traditional projects com-pares to risk on agile projects.
What’s Different about Agile Risk Management?
Risk refers to the factors that contribute to a project’s success or failure. On agile projects, risk management doesn’t have to involve formal risk documentation and meetings.
Instead, risk management is built into scrum roles, artifacts, and events. In addition, consider the following agile principles that support risk management:
1. Our highest priority is to satisfy the customer through the 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. Working software is the primary measure of progress.
The preceding principles, and any practice that demonstrates those principles, significantly mitigate or eliminate many risks that frequently lead to project challenges and failure.
Risk of agile projects declines as the project progresses. All projects have some risk, regardless of your project approach. However, with agile project management, the days of catastrophic project failure — spending large amounts of time and money with no return on investment (ROI) — are over.
The elimination of large-scale failure is the biggest difference between risk on traditional projects and on agile projects. In the next section, you see why.
Teams Deliver Features
In the past, you might have worked on a team that received a gigantic product-requirements document from a product manager. You worked on that project for months—maybe longer—and invited the product manager in to see the work you finished. That product manager might have had any of these reactions:
You gave me what I asked for. It’s not what I need.
The market changed. I don’t want this now. I want something else, yesterday.
This isn’t what I wanted. You read what I wrote, but that’s not what I meant.
Or your team was working on all the features, and halfway through the project a product manager or a Very Important Manager came to your team and said, “We need to ship tomorrow.
What do you have?” Since the team worked across the architecture rather than through the layers of the architecture, the team had nothing to release. The team had many features in progress, but nothing was done.
Maybe you had a different experience, and it still wasn’t good. You needed more collaboration with the business, or to deliver something more often, or to finish some work to release early.
Agile approaches address all those problems. That’s because agile teams deliver finished features on a regular basis. Agile teams use feature-driven development (FDD), regardless of whether they use an FDD approach.
Enterprise Components and Processor some other plan-and-implement-by-feature approach. When a team delivers features, everyone can see the shape of the product from the beginning as it evolves.
That’s what we’ll discuss in this blog: what features are, how to think about planning features, how to plan and replan, and how to understand the difference between features and waste.
First, let’s talk about what we can plan.
Plan at Several Levels
How much certainty do you have about what your customers want? You might have certainty about some of the requirements for now. Most of the organizations I work with have some certainty about the next month or two, less certainty about the next couple of quarters, and not much certainty for the next few years.
Agile and lean approaches help when you don’t have a lot of certainty about the requirements or the technical approach(es) that might work.
You might work in a different environment, where you have total certainty for the next several years. If so, you don’t need agile approaches for the requirements feedback. You might want to use agile approaches for seeing product progress and the team’s ability to release regularly.
Sometimes when you’re starting a new product or offering, you understand the strategic value of the features, but your certainty past the next week or two is quite low. You’re using agile and lean approaches to deliver value fast and be able to change as often as possible to respond to feedback.
We plan and replan at various levels when we use agile approaches. The organization can plan the project portfolio, the mixture of projects that will define the organization’s strategy.
Product managers (often with product owners) plan the product roadmap: what the product people want when. I often see six-quarter roadmaps that look like the top figure.
This roadmap doesn’t have much detail, but it does show an external release every quarter. Some teams, when they start to use agile approaches, have trouble releasing even once a quarter.
While senior management and product management might be able to talk to customers about expected or hoped-for timing, a six-month roadmap.
The six-month roadmap shows you the months, the external releases, the internal releases, and the feature set the product management team hopes will be in the release. Roadmaps are hopes, not commitments.
Don’t worry if you can only create a one- or two-month detailed roadmap. When people try to plan in great detail, they tend to over plan. That creates waste. I run my business on a six-month big-picture roadmap and a one-month detailed roadmap. I update these roadmaps on a two-week rolling wave.
Release for Learning, Feedback, and Value
These roadmaps show quarterly external releases and monthly internal releases. For many teams starting with agile, a quarterly release might be as fast as they can have anything of value to release. Here’s a question you might find useful to help with thinking and small stories: when do you need to learn about what?
The more often your team can release internally or externally, the more the team learns about what it takes for the team to release. When teams start to use agile approaches, they discover they don’t have enough tests at any level. The team might discover builds take too long or require some manual intervention.
The more often your team practices releasing, the easier releasing becomes. Add to that the idea of releasing into the organization, and the more the team can receive feedback from others across the organization. The more often the team can release externally, the faster the team will receive customer feedback.
Before I became a director, I was a project manager. One of the other projects had finished, so I facilitated their retrospective. That project was almost six months late. The company needed the revenue from that release. Now that the product was out, everyone felt relieved. They were happy to think about what they had done.
As part of setting the stage for the retrospective, the VP of engineering said, “Our goal was to release these features by that date. Let’s see why we released, but late.” One of the engineers said, “Is that all you wanted? We could have had that six months ago. But releasing is such a pain we didn’t release it.”
We learned how to release more often after that retrospective.
Releasing is not just to deliver value to your customers. Releasing creates an environment of feedback for the team about its deliverables. The team can learn if the deliverables meet the customers’ needs for functionality and performance.
The more often your team can release, the more opportunities your team has for feedback. At first, your team might have trouble releasing as often as once every two weeks.
Your customers might not be able to take your product even once a quarter now. However, the more often you can release, the better the team will become at releasing and the more likely you can get feedback.
The more often you release, the more often everyone learns.
When teams release often, they get feedback. And teams have to release value, not architectural or technical bits of work, to receive that feedback. Let’s explore what value is.
Deliver Value Through the Architecture
You may be accustomed to teams working across the architecture, as in the GUI person does the GUI for several features, and the platform people develop platform libraries.
You see this when people work in “front-end” or “back-end” teams. Agile teams deliver through the architecture. Author Bill Wake originated the term “slice of cake” to explain how teams implement in vertical slices.
Your team might have a front-end person and a back-end person on the team. As shown in the figure that follows, the team might have a middleware person and an app-layer person.
The team works as a team to deliver value by implementing by feature through the architecture. In this figure, the squiggly lines indicate a small and complete story through the architecture, one slice.
When teams deliver value through the architecture, one small slice at a time, they get feedback early. They rarely deliver a large feature set that doesn’t meet someone’s needs. Teams that deliver slices can release something when they want to. Teams that deliver slices learn early what their product owner or customer wants.
Remember that the more narrow the slice, the more often the team can release.
While your team might start with the back-end, middleware, and front-end people, encourage the team members to become generalizing specialists. That will avoid the Trap: The Team Consists of Narrow Experts.
Create a Walking Skeleton
When people start to talk about what the product might do, they often jump to a vision of the entire product. That means we see all the requirements, the big picture of the product.
It’s tempting to think we need to deliver all of those features. Instead, think about how little you can do to create a walking skeleton of the product, and add more features as the features have value.
Suppose you have a product with a variety of reports: sales by geography, kind of product, aggregated by several customers. It’s tempting to try to create the database schema that would support all those reports. It’s also tempting to create the entire login/security process at once.
Instead, if you create a walking skeleton, you might say this:
Let’s have one of each kind of user be able to log in, and we already know their usernames and passwords. That allows you to create a flat file of four entries and still see what the different reports might produce.
Let’s have each user create just one kind of report: a report by one kind of product for one customer. That also allows you to create a flat file of data to use as input, and maybe not even a pretty report-based format.
I might do this in two ways: to create a paper prototype of the flow of information and as a way to see the user’s flow. As the team and the product owner learn about the product and what the product owner wants next, the team refactors to add more login capability and more report capability.
Deliver Value to Someone by Using Features
We hear a lot about stories, epics, and themes in agile. You might have other terms for your requirements, too. Let me explain some of these terms:
Story: The smallest possible value to a specific user. It might not be sufficient to release by itself.
Theme: A related group of stories. I call this a “feature set.” You can deliver any of the related stories and realize value.
Epic: A compound story that’s not easy to tease apart. I find that epics often contain feature sets.
You might have other words for these terms, especially if you’re using a tool for your board. I encourage you to think about stories and feature sets. That will simplify your planning and delivery.
Here’s an example that might help. Assume you have an administration interface for your product. Different kinds of users (customers, internal sales people, external sales people, and company management) all want to run reports of some sort.
Because there are different kinds of users, you’ll need some form of secure login. Each kind of person will have access to different data to run reports.
There are several login stories, all part of a feature set:
Existing user login
Ability to register as a new user
Ability to change a password
Ability to block a current user
Ability to change a user’s privileges
And many more
I can imagine several report stories: Report on sales by geography, by kind of product, aggregated by several customers for the internal people, and much more. Assuming each report type has more than one story, I would use the term “feature set” to describe each kind of report.
I’m going to discuss stories and feature sets. I find that people too often lose the idea of stories when they start talking about epics and themes. The larger the chunk of work, the longer it takes to get feedback.
That’s why I talk about stories and feature sets. Feature sets help people realize there are several deliverables. A story is one of those features.
Stories are small; epics and themes are not.
The story—a feature for a specific user that provides value to that user—is the unit of the requirement in agile. If your thing—regardless of what you call it— does not deliver value to some user, it’s not a story.
Some teams work on what they call “technical stories.” Those are “stories” that allow the team to explore architecture or database schemas, or some form of design. Those are not true stories.
It’s possible your team needs to experiment to understand a feature more. That’s great. Create a user story, a real feature the team could release if it chose to, as an experiment. When teams understand who the feature is for, they are more likely to experiment in a shorter time and receive results they understand better.
Can I Use Tasks or Technical Stories Instead of User Stories?
You may have seen story advice that tells the team to break the work into tasks, such as setting up a database or creating tests, or some other function-based work.
Don’t fall for that advice. Don’t create tasks or technical stories.
The story is too large if you need to create tasks or technical stories. Teams create tasks because they don’t understand the story’s user—who the value is for—or if the story is quite large and the first item of value is not clear to the team. The team thinks it will save time by creating what it calls technical stories or tasks.
In reality, the team wastes time because it doesn’t need the database or the UI or those tests yet. (The team might never need the technical story, once the team starts delivering value.)
The first piece of value is much smaller than the task. You don’t need to use user stories as your only definition of a story. However, I don’t recommend tasks or technical stories.
If you’re worried about making sure you have tests for a given feature, don’t make “testing” a task. Instead, limit the team’s WIP and/or ask the team to pair swarm, or mob on the story. When the developers and testers work together, they often create a better story, with the supporting tests happening faster.
Define Stories So You Can See the Value
Stories often follow this format:
As a (particular kind of user), I want (some sort of action) to (provide me some achievement, value, or result). Not all stories arise from humans interacting with the product.
Sometimes the product monitors its health and takes autonomous (non–human-initiated) or asynchronous actions. In that case, consider this format from FDD as an alternative.
Some action — the result — some object
I’ve contrasted these two story types in the table. Know who the story is for. That way you know why you’re implementing it.
Here’s what I mean by a story:
As (an already registered user), I want to (download my bank statement) so (I can see if my budget is on track). This story assumes several pieces of other stories: There is some sort of security and log in.
That’s the point of “an already registered user.” We are not talking about creating new users in this story. Creating new users is another story.
The action, to download, assumes some sort of secure connection with sufficient performance. The value, to check actuals against the budget, assumes that the download arrives in some format, which we have not yet discussed. Again, we’ll discuss this in the acceptance criteria.
Creating user-based small stories makes the value transparent to the product-development team.
You might be thinking there are boundary conditions and other stories that are not part of this one story. You are correct. Here is a possible feature set that might include this story:
Allow related users, where you would need to create a relationship between bank account holders, to download the statement.
Allow downloads in several formats: spreadsheet, tab-separated text, comma-separated text, and PDF.
Allow downloads into several different money-management tools.
All of these might be the “Download statement” feature set.
Note that each of these stories provides value. You might need to experiment with different facets of the story or the feature set to understand how to proceed with your product. That’s the point of a minimum viable experiment (MVE).
Experiment and Spike to Explore
We rarely know exactly how a feature will turn out. We have ideas, but until we’ve implemented the story, we don’t exactly know how it will work. That’s why we don’t do Big Design Up Front in agile. Instead, we think of the smallest possible experiment or prototype that we can learn from.
It’s easy to create waste without trying. Here are some ways I’ve seen teams create waste without meaning to do so:
The team or an architect spent weeks defining an architecture up front and then the requirements changed.
The team or members of the team said, “While I’m in there…” and implemented more of a feature set than the product owner needed now.
The stories were so large the team spent considerable time in estimation.
The stories were so large the team took a long time implementing anything. By then, the customers had left for another vendor.
I bet you’ve seen other examples of waste in projects.
Teams can avoid many of these problems if they experiment to try something, prototype something for feedback, and spike to see what this “story” will really take. Teams reduce waste as a side benefit of experiments, spikes, and prototypes.
What Are Spikes?
Spikes are timeboxed prototypes that provide the team with information about the rest of the feature or the feature set. It’s even better when the team and the product owner write small stories.
The smaller the story, the less work a team has in estimating the story or in writing the story or the necessary tests to support that story. The smaller the story, the faster the team can release it.
And the smaller the story, the easier it is to experiment and understand if the customers want this feature or feature set. Small stories allow a team to experiment with its ability to do everything. Keep your stories small.
Write Small Stories
Just as short iterations provide you more frequent opportunity for feedback, small stories—as in one-day stories—provide you more possibility to see your progress and adjust.
Consider creating small stories that are one day or less in duration. Stories that short help the team see its progress and learning. The product owner can see the team’s progress and provide feedback frequently. The shorter the story, the faster the throughput.
Here’s a tip for creating small stories: Write the story on a 3x5 index card. You might have a tool that you’re supposed to use to keep the requirements in. While you build your agile mindset and learn how to work as an agile team, use index cards.
On the front of the card, write down the story. On the back of the card, write down the acceptance criteria. If your story and the acceptance criteria do not fit on one index card, the story is too big. Remember, stories are a promise for a conversation. The card does not have to have absolutely everything on it.
Is it difficult to create small stories? Of course, it is. It’s worth it. Think about a specific user and think about the flow of his or her work.
Create Rolling-Wave Roadmaps
Agile approaches invite change. The more often a team completes one small feature, the more often the product owner and team can change what the team delivers next. I like to show these possibilities with rolling-wave roadmaps.
There are at least two reasons to use rolling-wave planning:
We might get far enough into a feature set and realize we don’t need to do anymore, either at all or for this project. Agile approaches invite change. With rolling-wave roadmaps, we can show people how things might change.
Consider Minimum Viable Products and Experiments
Each of the preceding roadmaps has something called “MVP for release.” MVP means minimum viable product. Some feature sets are quite small. The team can deliver the entire feature set of multiple stories in one small chunk of time, such as an iteration or within a short cadence.
I see many feature sets that require more than one planning cadence or iteration to complete. And in the case of these roadmaps, you can see that the product owner wants the team to make progress across multiple feature sets in one planning iteration.
How can you show progress? With an MVP or maybe an MVE. A minimum viable product has enough functionality for the customer to use, even if it’s not the full functionality. A minimum viable experiment provides feedback for the team and the product owner.
In The Lean Startup, Eric Ries suggests the Build-Measure-Learn feedback loop, shown in the following figure. The concept is that you build the smallest possible piece of your idea in the form of a product.
When you release that product (the MVP), you can measure its success by gathering data. You can then learn, which helps you create the next batch of ideas.
When product owners create MVPs to test out the minimum features, they can use the Build-Measure-Learn loop.
Sometimes we want to see something even smaller than a useful feature or feature set. That’s an MVE. With an MVE, the product owner might think it’s worth considering a feature set. But the product owner wants more data. That’s why you create an MVE, something even smaller.
We have an embedded system. That means everything takes longer. It takes longer to develop, to test, and to release. I had this idea for a new vertical market, but I wondered if the boot speed was fast enough.
I checked with a great client. I got my product manager to visit the client and ask a bunch of questions about the vertical market and whether they needed something like what we were thinking. Yes, they were interested.
It turns out they were quite concerned about boot speed and application processing speed. Okay, that’s fine. The product manager asked them if they were willing to work with us to test an MVE, not an MVP. We might not deliver a full product, and were they okay with that?
They agreed and we all signed pages of nondisclosures.
I selected four very small performance enhancements, the happy path only. No error paths. The team took three days to develop and test the work. Then we all went to visit the customer to watch what the client did.
The team and I were surprised. Turns out boot speed was irrelevant (well, within certain parameters). What made the difference was one particular path through the application. The other three were irrelevant for this specific customer.
That gave us a ton of data. We spent a team-week altogether, on the development in the office, the travel, and watching the customer use the MVE. It looks like a ton of money, but I learned what a “necessary” feature was and wasn’t.
If you develop digital products, you might find that you don’t need nearly this amount of work for an MVE or even an MVP.
Sometimes you have a complex product and you can’t find a customer willing to experiment with you. The potential customers might think it’s too much work, or too complex to work on an MVE. Consider these possibilities:
Identify the smallest MVE you can. What can you do to release that MVE as something a potential customer will try?
Consider a simulation you can show potential customers. Maybe they can provide feedback on the simulation, not a product.
Revisit your strategy to see if it demands this project now.
The less work you do before you release, the more valuable the work the team completes is. That’s because the team can receive feedback on what it’s done so far.
Recognize Value Traps
As the team works on defining and delivering value, see if it encounters these traps:
The product owner has feature-itis. People in the organization want detailed schedules, such as Gantt charts. People are unsure about an MVP or an MVE, so they think they can’t recognize any value until “all” of the work is done. You have options for managing these traps.
Trap: The Product Owner Has Feature-itis
Product owners have feature-itis when they say things like this: “Gimme features. I don’t care about no stinkin’ framework. I don’t care about no technical debt.
I don’t care that it’s going to make your work harder later. I only care about now. I’m short-sighted, focused on today, or this iteration, and that’s all I care about. Show me the features, baby. Show me the features!”
Now, I bet that you have never heard a product owner or customer say those precise words. But you have heard words like them. If you have, you are witnessing feature-itis. And you have some options.
1. Explain to the product owner that you are a professional team. Make sure that all your estimates include the necessary architectural, refactoring, and testing work—whatever your team needs to deliver the finished value.
2. Explain the cost of not looking at the architecture, or at least the local design as you proceed, to the product owner. Explain that Technical Debt Is Not Unfinished Work.
The more you have unfinished work— incomplete refactoring to patterns, build or test automation—the more expensive it is to finish that work later. The team runs the risk of implementing Conway’s Law, where the design of the system reflects the organizational design.
3. Track velocity in a burnup chart. You will see if you start finishing fewer features over time.
You can placate the product owner, swallow your pride and your professionalism, and just do what the product owner asked for. Sometimes this is the right answer. But it’s often the wrong answer.
Feature-itis is a seductive disease common among relatively new product owners. For the first time in their careers, they actually see features coming out of the technical teams. It’s a heady feeling. No wonder they fall prey to the dark side.
But with that feeling of excitement must come a feeling of responsibility. Not only is the product owner responsible for the product features; the product owner is responsible for the business value of the product and knowing that the team is able to continue to develop the product.
Without architecture, tests, and all of the necessary engineering practices that good software requires, a technical team cannot deliver.
Trap: Your Organization Wants Detailed Schedules, Such as Gantt Charts
I said before that agile approaches change the culture of the project. In addition, they change the organization’s culture. However, not everyone changes at the same time. If your managers are used to assessing project progress with detailed schedules or Gantt charts, they might want to continue seeing those artifacts.
I have had good results when I’ve offered people the different pictures of the roadmaps: the longer roadmaps covered in Plan at Several Levels, and the shorter, more detailed road maps discussed in Create Rolling-Wave Roadmaps.
What do you do if someone really wants a Gantt chart? Do what you think you must. I don’t advocate placating those people. I recommend you help them learn how to read the other measurements.
Trap: It’s Not Done Until Everything Is Done
Some people are concerned that they can’t release anything until “everything” is done. They say things such as this:
“While I’m in there, I’ll do this, too.”
“It will take longer to do it later. I’ll just finish it now.”
“But no one can use it like this. I (or we) need to finish everything before we can release anything.”
There are several possibilities here:
People are concerned they will look incompetent if they don’t finish “everything.”
People might worry they can’t get to the rest of the value if they don’t do it now.
People don’t understand what an MVP or an MVE is.
You might, as an organizational leader, show by example that it’s okay to release interim, not-yet-totally-finished work; that might help people see that you don’t suffer any ramifications. You can do this with code, tests, a project charter—anything.
These people might have managers who want them to finish “everything” for some reason. A manager who doesn’t understand agile thinks people should receive performance evaluations based on “their” features.
See Managers Help with Team-Based Recognition. It’s possible a product owner or team member doesn’t understand how to slice and dice features so a team can release interim value. Review the MVP and MVE discussion.
Help people see that adding more work that’s not on the board (doing work while in a certain place in the code or tests) adds to the WIP and increases cycle time. That means the team has less idea of its estimates and when it might complete work.
Have a one-on-one with the team member or, if the team has sufficient safety, address this in a team meeting, such as a retrospective. You might also find that a backlog planning or refinement session is a good place to raise the issue.
Rank the Work
Think back to the last time you had a list of chores you needed to finish on a weekend. How did you decide what to do first? Maybe you attacked the one that would take the least amount of time, just so you could cross something off your list. (Finishing something can also impress a family member. You score points.)
Maybe something was no longer valuable if you didn’t finish it in time for a family member visit. If you’re supposed to finish hanging pictures because Aunt Martha is coming to visit and you don’t finish, is it really worth hanging the pictures after she’s gone? You might choose other work to do.
Maybe you decided you had a large project that you needed to explore a little first. In my house, home-improvement projects that involve painting are like that. The painter paints a swatch of paint and I get to look at it in a different light.
Maybe you wanted to timebox some of the work to see how long the rest of the work would take. I hate cleaning my office because I could be doing other work that I find much more enjoyable instead.
I’ll tackle that work by timeboxing the cleaning up to 30 minutes or an hour just to see where I am at the end of that time. If I think I can finish in a short period, I might do it. Otherwise, I get to do work I prefer doing next.
If I think something is risky, I might try to do something small to learn more about it. For example, if I think writing a specific book might be a good idea, I might try writing a blog post or an article first, before committing to a book. I haven’t expended much time and I have the value of the post or article.
You can rank work in these ways and more. If you don’t like these alternatives for ranking features in a project, consider the alternatives in Manage Your Project Portfolio. There are additional options there that, even though they are for ranking projects in a project portfolio, will work for features also.
Rank the Shortest Work First
Don Reinertsen in The Principles of Product Development Flow: Second Generation Lean Product Development [Rei09] suggested that we consider delivering work that takes little time to do, as a way to rank the work. That’s called Shortest Job First. Since we’re talking about knowledge work, I’m going to use “work” instead of “job.”
It’s a terrific idea, as long as you really have short work. And it’s a great idea if you have different lengths of work. That’s because you can push through some of the short work and get feedback before you attack the longer work.
Doing the shortest work first provides you with quick wins. You might be able to show people a walking skeleton, as described in Create a Walking Skeleton and ask for feedback. If they don’t like the skeleton, you haven’t invested too much time. And you can see finished work even if the work is not full feature sets.
The shortest-work-first approach works, as long as the time is short. By that, I mean not more than a couple of days in duration. I prefer no more than one day in duration. If the work takes more time, or if you have a ton of work that is all short and must be done now, consider using the cost of delay to rank the work.
Use Cost of Delay to See Value
One way to define the value of the work is to make sure the work is still valuable. Use the ideas from the cost of delay to define the value now and in the future.
There are four potential costs when you delay work:
The company misses the potential sales from the introduction delay.
The delay introduces lower maximum sales.
The delayed introduction creates less overall demand, so the feature has less value in total.
With less demand, the end of life might be earlier with a delay. Often, this is a function of not being able to capture the market at the optimum time. Since you don’t have the customers, you have an earlier end of life.
Here’s a quick example. Imagine you’re working at a game company. Game companies make most of their money when people buy presents for Christmas. When you release a game before October, you make the maximum amount of revenue, because your game is available when the buyers want it.
If you release the game in October, you may have lost some buyers, because some people buy their holiday presents before then.
If you release the game in November, you will still capture some buyers, but some—even many—of the potential buyers have already bought their presents. If you don’t release until December, you’ll have lost most of the buyers.
If you release in January, no one will care. And if this is your first product release, you might have to end-of-life the product in January because no one cares enough to buy a follow-on release.
The real question is this: When is the “best” time to release this feature (and, by extension, the project)?
Estimation often assumes that the feature has the same value over time. However, if you miss a specific time, the feature often has a decreasing value over time.
Thinking about when the feature no longer has value is one way of articulating value via cost of delay: When does this feature no longer have any value?
When you start to break apart a feature set into features and use the value-over-time idea to rank the stories in a feature set, the product owner and the team can have a rational conversation. The product owner no longer says, “I need everything or it has no value.”
Too often, product owners (or other manager-type people) say, “You have to do everything by next Friday or it has no value.” I’ve seen very few situations where the maximum-value date was that close in and the team had to have finished all of the work. But even if that’s true for you, here are the benefits of ranking by value over time:
The product owner might not even start work on this feature or feature set if the team can’t finish it when the feature runs out of value. The team can deliver the most valuable work and not have to start work that’s no longer valuable.
The product owner might be able to have a conversation about which story is first, second, and third. That helps the product owner and the team break apart feature sets into smaller features.
While I like the idea of ranking by seeing the value increase (or decrease) over time, that’s not the only way to rank. Sometimes interim learning is most valuable for everyone.
Rank by Valuing the Learning
Sometimes it’s worth learning more about a feature before you decide how to manage the roadmap or rank the entire feature set. In that case, consider these three approaches:
Instead of valuing an entire feature set, decide what you want to learn from an MVP or an MVE.
Spike the work to understand the feature set.
Try something quite risky to understand the risks more.
Learn from an MVP or an MVE
Back in considering Minimum Viable Products and Experiments, I suggested you might want to consider what was the minimum requirement for products and experiments.
Especially if you are thinking about creating small MVPs or experiments, you might value some of those features higher than others.
If you know what you want to measure and learn, you can create small experiments that provide you value. I’m not suggesting you work on an entire feature set, one small experiment at a time. I suggest you consider the smallest experiment you can to try to create some data that will help you learn what to do next.
Spikes Can Help Everyone Understand the Value
Sometimes you need to value something you’ve never done before. You can’t know how long it will take, so you can’t use the Shortest Job First. You might not even be sure of what the entire feature set is.
In that case, you might consider timeboxing a little work to understand what the entire feature set is. You might even learn enough to be able to estimate it. That timebox is a spike.
Back in Experiment and Spike to Explore, you learned about how to use spikes. Consider timeboxing your spikes to not more than one day. Your team might want to make it several hours instead of an entire day.
I encourage the entire team to work on the spike, swarming or mobbing to complete the work. At the end of that timebox, the team can see what is completed and what is left to compete for an MVP.
Use Risk to Assess Value
Sometimes you want to try something that’s quite risky because you can learn more about the risks. In that case, consider taking one story from a feature set, or create an MVE to try.
Rank that story or experiment high because of the learning from finishing that one story will help inform the team and the product owner about the rest of that work.
Recognize Ranking Traps
Ranking the work by value challenges many people. Watch for these traps:
Using estimation—and the only estimation—to rank the work.
Someone else pressuring the product owner to change the ranking to accommodate another person’s desires.
Ranking all the work for months or a release at the beginning of a project.
You have options for managing these traps.
Trap: Rank Only by Estimation
Some teams try to use estimation to rank their work. If we had perfect knowledge, we might be able to use estimation. However, we rarely have perfect knowledge about the work or the estimate.
If you know you have a one-day or shorter story, you can Rank the Shortest Work First. However, teams often have less knowledge than they need about the story size. Or the story is much larger than one day. In that case, using estimation to rank often doesn’t work.
Trap: Someone Else Pressures the Product Owner
You may have heard of the HiPPO (Highest Paid Person in the Office). I would love to say that agile approaches make HiPPOs go away. Not so. However, agile approaches make it clear that the HiPPO exists.
If you have a HiPPO who declares, “Everything must be done!” or “Do this first!” or the like, use your influence and collaboration skills to help that person realize the team will progress faster if it limits its WIP and works on one thing at a time, in a way that makes sense for the product.
Sometimes it helps to ask that person about his or her goals or measurements.
Sometimes people act in a way that satisfies the people measuring them.
Trap: We Must Rank All of It
Even if you consider rolling-wave planning, as discussed in Create Rolling-Wave Roadmaps, someone might want to rank “all of it.” That’s a trap because as the team finishes small stories, the product owner wants the ability to change which stories the team should do when.
Here are some ways of managing this “all of it” thinking:
Consider ranking up to three iterations worth of work, or enough to fill a cycle time of about six weeks.
Consider creating a parking lot, as discussed in Use a Feature Parking Lot to See Possibilities, as a way to manage the not-yet items.
See if clarifying the product vision and the release criteria helps the product owner and the team manage the requests for “all of it” now, as opposed to later. It’s tempting for people to want to do “all” of anything. See how you can help people move to “how little” thinking as opposed to the “how much” they traditionally had.
Visualize Your Work with a Board
I used yellow-sticky, rolling-wave, deliverable-based scheduling in my projects before I knew about agile approaches. I found it helpful to be able to show people the current view of the schedule.
In agile approaches, we have multiple tools for explaining the project’s plans and current state. The big-picture roadmap helps people see a larger view of the proposed deliverables, the larger plan.
The rolling wave–style, shorter roadmaps help people see what the product owner has planned for the near term. The project board helps the team and other people see what’s happening now—the current state.
Boards help teams visualize their work, their bottlenecks, and their delays. The idea is that the team members can see—at a glance—where they are with all the work on the board.
At the very least, the board tracks the state of the work: is it ready, is it in some sort of progress state, or is it done?
Your team board helps the entire team to see what’s going on. First, let’s discuss how to start creating your board.
Start with a Paper Board
It’s tempting to select an electronic tool when you start with an agile approach. Electronic tools provide you places to put your planned and in-progress work. You’re probably accustomed to electronic project-management tools. And electronic boards make it easy to calculate cycle time or velocity.
However, paper boards have several benefits electronic boards don’t have:
The team members can pass around a card or sticky to review, add/subtract, or rephrase. That’s how people on the same team build the same mental model of the story or feature set.
People don’t move something to some sort of in-progress column without actually standing up from their desk, walking over to the board and moving it. Electronic tools make it too easy for the team members to say, “Yes, I’m done with that” or “I’m working on it” when neither statement is true.
Electronic tools can hide the details of the card. Often, the box is too small to see the story details or the acceptance criteria at a glance.
The paper helps you create smaller stories because the paper (cards or stickies) is small.
When you start with paper, you can see which columns you need on your board and easily add or subtract them.
The paper helps you limit the team’s overall WIP. Paper creates a physical limit for what everyone sees, considers, and works on.
If you’re worried about how a distributed team can see a paperboard, see Create Visible Boards for Geographically Distributed Teams, for more details.
Teams that start with electronic tools fall into many traps. These traps are not the tools’ fault. The problem is that the tools don’t help the team create new, agile habits. The team reinforces old habits. I’ve seen these problems when teams started with a tool:
The team’s stories are too large to complete in an iteration, never mind in one or two days.
The team creates architecture-based work or tasks, instead of stories.
People tend to create tasks around the story to break it apart instead of swarming around the feature.
People tend to say, “I’m an expert there, for that story. Assign it to me.” Aside from the fact that no one should assign anyone work, reinforcing the expert problem creates bottlenecks and reduces team learning and feedback. Paper boards don’t have a need to assign anyone to the story when the team creates the story.
One of my clients used a whiteboard with index cards. Each person on the team had one magnet. Because each person had only one magnet, each person had limited WIP.
Another client had index cards on a corkboard. They used pushpins with people’s faces on them to push the index cards onto the correct column. They had three pushpins for each person on the team.
When I asked them how it was to have people be on three cards at the same time, the director said, “We know that having people assigned to multiple items is not helping our throughput. However, we can see what people are working on.”
Start with paper on your board. Paper invites collaboration and the agile mindset. Paper will help you see what you’re doing and not doing, as individuals and teams.
Don’t start with an electronic board. Start with paper of some variety.
Iteration-Based Boards Show Team Commitments
You might have seen a typical Scrum board, similar to the one shown here:
In Scrum and other iteration-based agile approaches, the team estimates what it can commit to for its iteration. The team takes that work and puts it in the Ready column in rank order.
The Ready column does not change during the iteration. This is important. The team, along with the product owner, commits to what the team will do during the iteration. This is one reason why an iteration is different from a cadence.
If a team has to manage interruptions, such as support requests, the team leaves room in the iteration for support work.
The team decides how it will work. The team decides the flow, and the flow is not explicit unless the team decides to make it explicit.
Teams own their own boards. If your team wants to separate support requests from the entire backlog or add a column labeled “Today,” it should do so. The board exists to help the team members see and finish their work.
Teams that use iterations might even decide to map their flow on their board. As soon as they create WIP limits, the board is technically a kanban board.
Does that matter? No, except for the team.
One Scrum team decided that it liked the idea of iterations for cadence, but the members needed to see their flow.
As shown in the following figure, they also wanted to have a “Today” and an “Urgent” queue for work. They created a board that looks a lot like a kanban board, which they call their “Scrum Flow” board. (Yes, they made that name up.)
Teams decide what goes on their board. Teams manage their boards. Teams can name their boards. As long as your team’s board provides the team members the data they need to manage themselves, it doesn’t matter what they call the board or what the board shows.
Kanban Boards Show Team Flow and Bottlenecks
Kanban boards are each unique to their teams. That’s because each team has its own unique flow.
The following kanban board has WIP limits on all major columns, including the Ready column. The WIP limits exist to make sure the team sees its flow and possible bottlenecks.
The Ready column has a WIP limit because the product owner can change what’s in the Ready column. This particular team has a step called “Discuss Story” in its flow. That column also has a WIP limit so the team doesn’t get too far ahead of itself.
Notice that this team has a WIP limit on the number of stories in Dev-Done. You can think of the Dev-Done column as a buffer for the System Test column.
Each of the columns with WIP limits is full, which means this board is full. If the team respects its WIP limits, the team can’t start a new story, nor can it take a story into Develop and Unit Test. This team has to move a story from System Test to Done before anything else on this board can move.
When the team has a full board, the members look at the board from right to left, to see what is closest to done. The team has a responsibility to move whatever is in System Test to Done before pulling any more work.
The team had started with a Scrum board. They had many items in the “In Progress” column. The developers noticed they were always “ahead” of the testers.
They decided to create the kanban board to see where the problems were. With a kanban board, the team was able to see the problem. The testers were behind on creating test automation and had to test too much manually.
The developers and testers paired on the work in System Test until the team created sufficient test automation for the team. Because they saw the bottlenecks, they could discuss the problems and fix them as a team.
Once they cleared the System Test bottleneck, they could move to the next leftmost column and see why they had bottlenecks there. Once they cleared their bottlenecks, they create WIP limits to manage where they had work in progress.
For example, if your team has interruptions from support, you might need an Urgent queue on your board. The board in the image has one urgent item.
That means that, depending on the agreement with the people who put items in the Urgent queue, the team might stop working on one of the items it’s working on now and have more WIP. The additional WIP is the work the team stops plus the new work.
Every team has a different meaning for “Urgent.” Some teams use Urgent as “Stop what you’re doing right now and start this.” Some teams use Urgent as “Take this next.”
If you use an Urgent queue, decide if the team can override WIP limits to take on new work. Almost any decisions your team makes are fine, as long as it makes a decision about what Urgent means and if and when the team can override its WIP limits.
If you do use an Urgent queue, consider defining response time in the working-agreements part of chartering the team. See Ask the Team to Develop Working Agreements.
Make Your Own Board
Teams are responsible for their own boards. It doesn’t matter if you use an iteration-based agile approach or a flow-based agile approach; create a board that matches your needs.
If you have several projects underway and your team is supposed to make progress on all of them, consider a kanban board with WIP limits. You will need to see how many items you can have in progress for your team. If your team addresses production support issues, consider adding an urgent queue to your board.
If your team has people in many time zones, you might need to see where the work is to see the state of everything in progress. I recommend your team use a kanban board with WIP limits, so no one gets too far ahead or behind.
As you start to use an agile approach, notice the kind of work you have and what flows easily through your team. Especially notice if you have bottlenecks and adjust your board to make those bottlenecks visible.
Visualize Problems with a Board
Your team might want to note problems (impediments, risks, other obstacles) on its board. I prefer to separate the problems from the work. That’s because a servant leader (not the team) may take the lead in addressing these problems. One team uses a board like the one shown in the following figure.
The team wants to track the date it added a problem to this board. If the team doesn’t address risks early enough, the risks turn into problems. But visibility doesn’t mean the team has to start working on it yet. When it’s time for someone to work on the item in the Concern column, the team promotes that item into the Ready column.
This team has a WIP limit of seven items in progress to make sure it continues to review and address its problems. Whoever works on the item can move it into a Waiting state too—waiting for an external or team decision. Once the person or team resolve the item, the item is moved to Done.
I’ve been vague about who would work these problems. Often a servant leader manages these problems. Sometimes team members do. There is no One Right Way to address risks, impediments, or other problems.
Make the work visible and work it. Your team might want to track items from a retrospective parking lot on this board, especially if it has trouble starting the work on that parking lot.
Create Visible Boards for Geographically Distributed Teams
You might be working on a geographically distributed team. You can still use a paperboard to start instead of an electronic tool.
The team creates the board as described in Make Your Own Board, in one physical location. Someone takes a picture of it and posts it on the team’s project space. Now the team has at least two choices.
The team can ask one person in that physical location to please move the cards as people take and finish stories. Or the team can replicate the board in each physical location. Each person can move his or her own cards, take a picture, and let the entire team know which card moved and where.
The team creates a team norm about how to move cards. When a team member moves a card, the team member notifies everyone according to the team norm.
When the team practices with its board and gets feedback from how the board works and how its process works, the team might decide to move to an electronic board. However, stay in the paper as long as possible. You will find that your stories are smaller and that your feedback is faster.
Beware of Board Tyranny
When people take stories alone, the standup or walking off the board tends to focus on the person. Too often I hear, “Why didn’t you finish this work?”
Instead, ask the team to focus on moving work across the board. It might be easier for your team to use flow to do this. The WIP limits help people focus on moving work across the board, rather than on what individuals are “responsible” for.
See Steve Reid, Prateek Singh, and Daniel Vacanti’s experience report, “Ultimate Kanban: Scaling Agile Without Frameworks at Ultimate Software.”
Never blame people for not doing “their” work. All the work belongs to the team, not one person.
The paper helps a team see its real flow, not what it thinks its flow should be. “Well, once a dev is done, a tester should just take it.” Are the testers in the same room, or at least on the same floor as the developers?
Did the testers participate in story creation or refinement? I’ve seen time zones and insufficient understanding prevent the testers from “just” taking a story. The longer a team stays in the paper, the more it is apt to create a board that reflects its real flow of work.
What if your management mandates a board in the form of a tool? That’s the Trap: Management Mandates Your Boards.
Recognize Visualization Traps
Not every team gets its board right the very first time. And defining a board that works for your team might be even more difficult if your team encounters these traps:
Management mandates your boards.
Every person takes his or her own story.
Waterfall masquerades as kanban.
The team works in iterations of waterfalls.
You have options for managing these traps.
Trap: Management Mandates Your Boards
Your management says, “Do Scrum!” or “Do Kanban!” Your management has an idea of what it wants to see for your board and your output.
Don’t fight with your management—at least, not yet. Instead, use the project frame that they request. If they request Scrum, use two-week iterations.
Use the board you want. If you have a ton of interruptions, use a kanban board to make that work visible. Use the board to measure cumulative flow and cycle time. I would not even bother measuring velocity.
With all those interruptions, cycle time and cumulative flow are better predictors of your capacity. See Cumulative Flow Shows Where the Work Is, and Cycle Time Shows How Long Work Takes, for information about these measurements.
Trap: Everyone Takes His or Her Own Story
Sometimes when teams are new to an iteration-based agile approach, they fall into the trap of dividing the work by the number of people. “We’ll each take our own story. We’ll make tons of progress.”
Or someone, such as a manager or product owner, asks or demands that everyone takes his or her own story. (When people demand that experts work on “their” stories, it’s the Trap: Experts Take Their Own Stories.)
It sounds like it should work. If we divide up the work, we can get done faster, right?
Well, no. Knowledge work is interdependent work and requires learning. That means we need other people to deliver a feature and we will learn as we deliver.
I have yet to see one-person features. Every feature requires at least a person who creates the feature and a person who checks the feature. Most features I see require more people.
If you have noticed this trap, consider these options:
Move to a kanban board and create WIP limits. This will help everyone see where the work is and if the team has bottlenecks. Ask the team to Swarm on the Work, or Mob on the Work, on every single feature. When people work together, they will finish the features faster.
At a minimum, ask the team members to pair on every single story.
Maybe you can see more options for your team. The team will make much more progress when people collaborate on stories than when each person takes his or her own story.
Trap: Waterfall Masquerades as Kanban
Just because you have a kanban board does not mean you are agile.
I’ve seen at least two kinds of flow that were not agile at all. In one, the team used a waterfall approach and its board had these headings: Analysis, Architecture, Design Specs, Functional Specs, Coding, and Testing, in that order.
Those headings might be okay, but here’s how they worked: The “product owner” supplied a large document full of functional and nonfunctional requirements. The product owner then put all those requirements into the Analysis column.
The requirements were not in the form of stories with acceptance criteria. The architect developed an architecture based on those requirements and handed off work to the senior developer.
The senior developer wrote design specs and many functional specs. The other developers finally joined the project and wrote their functional specs. Finally, the developers wrote code that tested their earlier assumptions.
The testers joined the team just in time to start working on requirements in the testing column. They had code and documentation to use to guide their testing. Except the documentation didn’t match the code.
The team had a tremendous amount of WIP, lots of up-front documentation that didn’t reflect the final reality, and little collaboration.
Its flow was not agile. And because the team had no WIP limits, it didn’t use any of the agile or lean principles to collaborate and finish work. The board itself is not bad. If the team collaborates on everything, uses WIP limits, and eliminates up-front documentation, this kind of a board might work to help a team move to an agile approach.
I’ve also seen a team where the architect was outside the team and told the team how to do the work. That team had these columns on the board: Receive Specs, Coding, Testing, and Rework. Yes, the board actually had a Rework column. That’s because that team’s experience was like many other teams’: its up-front design was often wrong.
Both of these teams felt as if they were wearing straitjackets. No one had any fun.
I can’t guarantee agile projects are fun. However, as the team defines its own workflow and its work, many agile teams appear to have more fun more often.
Trap: You Have Iterations of Waterfalls
Some people who start with an iteration-based agile approach have a two-week iteration that looks like this:
Day 1: Commit to work. Start development.
Days 2-6: Continue development. The testers are bored because they have nothing to do yet.
Days 7-10: Test and send back work to developers.
Day 10: Realize the team didn’t finish half of what it committed to finishing. Or the developers “finished” but the testers didn’t.
The team doesn’t finish the work it thought it could. Often, the team discovers (or, worse, the testers discover) that the developers created a number of defects along with the feature.
And sometimes the team doesn’t realize that it let defects escape into the next iteration. The team has a ton of WIP during the iteration that might be invisible to the team.
The real problem is that the team doesn’t take the responsibility to complete the work. Instead of a collaborative approach to starting and completing work, the team uses a waterfall approach inside iterations. Maybe you have board tyranny, as discussed in Beware of Board Tyranny.
You don’t have to work this way. You have at least these options: Swarm on the Work, or Mob on the Work; use a kanban board and measure your WIP; or make your iterations half the duration of what they were.
The way to see if your team is doing this is to use a kanban board. See Kanban Boards Show Team Flow and Bottlenecks. Make sure the team re-creates its flow on the board. Once the team sees its flow, consider asking it to create WIP limits, so people can see what they start and when.
If the team uses iterations, it can still use kanban to see the flow of work. However, it might be time to reduce the iteration duration to see what’s going on.
In Keep Your Iteration Duration Short, I said to make your iterations short enough that if you had to throw away everything you had done, you could. If your iteration is four weeks, divide it by two and use a two-week iteration. If your iteration is two weeks, make it a one-week iteration.
When the team halves the time, it puts pressure on itself to commit to less work. When the team commits to fewer features in less time, it reduces the batch size. That has the effect of increasing throughput.
If you are already using one-week iterations, consider this question: What would you have to do to get one feature done? Maybe the problem is your feature (story) size.
Create Technical Excellence
Do you like to practice some form of craft or hobby, such as cooking, woodworking, or knitting? When we practice our crafts, how do we go fast? Part of it is experienced with our craft. Part of it is how we create and maintain our environment.
I’m going to use cooking as an example. We need to know what we want to accomplish: is it making dinner or a grand dessert? The plans (recipes) for each are different.
We need our tools, such as good knives and pots and pans. We often need interim deliverables, because things need to melt and then cool for desserts. Or we need to sauté vegetables and put them aside for later combination.
Above all, I have noticed that when I am pressed for time I do these things: I read the recipe through a few times so I know what I’m going to do and when. I gather my ingredients so I know I have everything at hand. And I clean the kitchen as I proceed, so I can see my workspace at a glance.
We do something similar with code. We discuss the stories with the product owner so we know what we need to do. We review the code and tests already there to see what exists and what might need to change. And we create tests at a variety of levels to keep the code clean as we proceed.
I’m not saying that producing software products or any other kind of knowledge work is as easy as cooking. However, when we practice our craft, we often need to think about what we will do and how we might do it, and then keep our workspace clean as we proceed.
For software (and hardware and mechanical) products, we spend far more time discussing what we should do (defining and refining the requirements) and read the existing code and tests than we spend writing new code and
That means we need to consider these ideas to go fast:
Optimize for reading the code and tests. That often means we need to refactor (simplify) as we proceed.
Optimize for early delivery to see how we’re proceeding. That often means small stories and continuous integration as we proceed.
Optimize for creating technical excellence as we proceed. That means we need to test at a variety of levels as we proceed.
Although I’ve written this book for agile software teams, I’ve thought about other possible readers. If you are not a software person, please translate these ideas for your kind of product. Do you read and reread previous plans, schematics, or some other artifact to discover what you need to consider next?
How can you iterate on the requirements to refine the work as you proceed? How can you test as you proceed so you know you have a valuable product while you develop, not just at the very end?
How Much “Quality” Does Your Product Need?
Not every product needs excellence in order to be released. Consider Geoffrey Moore’s technology adoption lifecycle as a way to think about product quality. I added the part about what customers want at different times in the following diagram.
If you are in the early part of the life cycle, with enthusiasts and visionaries, your job is to release small increments of value fast. Those customers will provide you with the ability to learn. That means your batch size, the size of your stories, must be small—and yes, you can take shortcuts to achieve a fast delivery.
However, once your customers pass the chasm, when your product achieves mainstream status, you now have to focus on low defects: preventing and fixing defects so your customers can use the system.
The product owner, possibly via the product manager, might ask the customers what quality means to them. Sometimes the answers surprise everyone.
Too often, managers encourage teams to take “shortcuts” to shave time off the schedule. Gerald Weinberg in Quality Software Management: Volume 1, Systems Thinking names the Zeroth Law of Software Quality: “If you don’t care about quality, you can make any other requirement,” including schedule.
Shortcuts create cruft and a mess.
Our project speed is a function of the code and tests that already exist, the technical excellence of the code and tests, the clarity of what we want to do next, and the complexity of what we need to do next.
You might think of the team paying attention to the feedback, the learning, from the early part of the chasm. As the team learns, it now has to pay attention to the quality of the code and the tests. The team has options to create a high-quality product. That’s what this blog is about.
As a leader, you look for results from your team: a continuous flow of running tested features. Your team can achieve these results by thinking about how it can do the following:
Integrate often to see progress
Keep the code and tests clean
Work together to maintain throughput and focus
Test at all levels so the team has support for frequent change
In this blog, I’ll discuss the specifics your team might use to achieve those results.
Integrate as Often as Possible
If you are accustomed to large, multi-day or multi-week chunks of work, you might not be familiar with continuous integration. Continuous integration means the developers (and testers) work on some small chunk of value, check that value in the version-control system, make a build, check that build, and, as long as everything works, they’re done with that piece.
When I think of continuous integration, I think of people checking in at least twice a day. I check in my work every hour or two. I recommend a smaller time frame rather than a larger one.
Here’s the value of continuous integration:
You can see what you’re done with and what’s still in progress.
Developers can check to see if they broke the build.
Automated smoke tests can check that the product’s performance or reliability still works the way everyone expects.
Other people can use what you finished.
Other people here might be developers or testers. Developers across the project might be waiting for another developer’s code, even if that code is an MVE. Testers can start testing the real code as soon as they have it available.
Continuous integration provides a team the support it needs to move fast. When developers write a little code and write some unit tests to go along with that code, they know the code works.
It’s the same way with tests: when testers write small tests and verify those tests work, everyone knows the code works. And the team can see its progress because the team gets to move a card across the board.
The more often the team integrates the code, the more they see how the product works. They get immediate feedback about their thinking and coding or testing.
They learn fast.
If you want faster product development, create small stories and use continuous integration.
Consider Continuous Delivery
Back in here, I showed you the potential for release frequency for different kinds of products. If you have a totally digital product, you can have continuous delivery. See Continuous Delivery and Unblock! A Guide to the New Continuous Agile for ways you could organize your company to deliver multiple times a day and mistake-proof the delivery.
Even if you can’t use continuous delivery, consider how often you can release internally to learn what it takes your team to release.
Refactor Every Time You Touch Code or Tests
I said earlier in this blog that we want to keep the code and tests clean. You may have worked on a large product that had some automated tests. And eventually, those tests didn’t work anymore. No one refactored those tests as the code changed.
Even worse, you may have seen projects where “all of a sudden” the build didn’t work. Often, the suddenness arises from a lack of integration. But part of the problem is also that no one updated and simplified the code or the build scripts.
I’ve seen codebases where the code had several ways to get data and several ways to output data. They didn’t all work the same way. By the time a new team worked that code base, it needed to redesign the code, not refactor.
I’m not suggesting that you never have to redesign, but refactoring simplifies and makes everything clear as you proceed. You are less likely to need to redesign.
Refactoring is a simplification. It's not redesigned. It’s not architecture. Refactoring—by itself—does not add features to a product. It’s entirely possible that when you add a feature you first add functionality. Then, you refactor to simplify.
Refactoring works for both code and tests.
Work as a Whole Team to Create the Product
The payoff for the team building its safety and trust comes when the team members collaborate to build the product.
You’ve seen that agile approaches are about team collaboration to deliver value. Your team might take the collaboration to another level with the pairing, swarming, or mobbing.
Two people work together on one story, on one machine with one keyboard. Developers might pair-program. A developer and a tester might pair together to review performance. Two testers might pair-test. Any two people working together are a pair. See Pairing Creates an Environment of Continuous Review.
The team works together on one story, but each person contributes based on his or her expertise. The platform developer works on the platform, the middleware developer works on the middleware, the UI developer creates the UI.
In addition, the tester develops tests. When each person is done with “their” part, that person offers his or her assistance as a pair to whoever is still working. See Swarm on the Work.
The entire team works together on one keyboard. Think of mobbing as team-pairing. See Mob on the Work.
Here’s the value of pairing, swarming, or mobbing:
The team limits its WIP, which helps it focus on getting work done.
The team can learn together in swarming and does learn together in mobbing.
The team collaborates, so it reinforces its teamwork. Team members learn how each other person works. They also learn who has expertise
now, who might need which expertise, and how each of their colleagues learns.
The team has multiple eyes on small chunks of work, so it gets the benefit of continuous review.
Managers who are unsure of flow efficiency may wonder about the “cost” of pairing, swarming, or mobbing.
Early in our agile transformation, I thought pairing was expensive. I was paying two people to do the work of one person. What were these people doing?
Then we had a cascading problem. It started off in the Admin part of the code. The Admin guy fixed it. Then, a new problem popped up in the Engine. The Engine guy fixed that, and broke Payments and Search.
First, the Engine guy started to work with the Search guy. The Payments woman overheard what they were doing and said, “That won’t work!” I think they had a knockdown, drag-out fight. It was a little ugly.
The manager for the team asked this question: “What if you all worked together on this problem, so you can all explain what’s going on to each other?” The team agreed to do so.
I was not happy. Now I was paying five people to do one person’s job. We’d already spent two weeks on this problem.
They finished the fix the next day. One area in the code had made assumptions that another area hadn’t. They would have taken forever to find this working alone.
If they could be so fast and fix—really fix—the problem, what would they be able to do when they wrote new code?
In an agile approach, we want the team to take responsibility for its work. We want throughput as opposed to busyness. Pairing, swarming, and mobbing all use the ideas of flow efficiency to finish the team’s work.
The more the team feels as if it has collective code ownership, the less the team reinforces resource efficiency and the more it reinforces flow efficiency.
Pairing Creates an Environment of Continuous Review
You might think the pairing is about working on something where one person doesn’t understand it. Pairing works then. Pairing is even better when people learn and deliver together as a pair.
Pairing works and takes less time than any one person working alone. That’s because the pair focuses together. Each person acts as a check on the other person.
When team members pair in person, they work on one item—on one machine, with one keyboard. The pair trades off who types and who looks. The person typing is called the driver. The person looking is the navigator.
Often, the two people change places every 15 minutes. That gives both people a chance to see the small picture (what the driver sees) and the big picture (what the navigator sees).
With the real-time review that pairing provides, we can avoid the number and severity of defects that either person might produce alone. Pairing saves the team time and therefore money.
I have found another benefit to pairing: Each person learns about this domain from the other person’s perspective. I often ask what I consider stupid questions when I am the navigator.
Sometimes the questions aren’t stupid— they prompt us as a pair to understand the story better. I find that when I pair, I learn a ton about the domain.
Swarm on the Work
Swarming is another way to collaborate as a team. The entire team works on just one story at a time. The team’s WIP limit is 1.
In swarming, the team members work alone or maybe in pairs, according to their expertise and desire. They often start off the work with a short standup where people will say, “Here’s what I will do.”
The swarming team discusses the story. Then the team members work as they choose (solo, pairs, triads) in a short timebox of one hour to work on their own.
After that timebox, the team returns to check in with each other and see how the work is going for everyone. They might need to resolve issues in the code or the tests, so they decide what to do next.
They then repeat the work and check in until the team finishes the work. The team has a cadence: work for an hour, check in with each other, scatter to work for an hour, check in, repeat until the item is done. If one person is done before the others, that person offers his or her services— possibly as a reviewer—to the rest of the team.
Swarming helps the entire team understand the feature under development. Because the entire team works together, the team has no interruptions. No one multitasks. The team can reduce its cycle time for a given feature.
If your team has a difficult time making the stories small, swarming is one way to deliver larger stories faster. Here’s how this might work in practice:
Team 1 gets together as a team and discusses the item with the product owner to make sure everyone knows what they will do.
They talk among themselves for a couple of minutes to decide on their “plan of attack” (their words) and then scatter. The testers develop the automated tests and take notes on the exploratory tests. The developers work on the code.
Team 1 has an agreement to return every 25 minutes to check in with each other. They do this with this kind of a report: “I’m done with this piece. I need help with this next piece. Who’s available?”
Or “I’m as done as I can be for now. Anyone need another pair of eyes?” This team chose 25 minutes because it has smallish stories and wanted to make sure it maintained a reasonable pace/momentum.
As people finish their work, they help other people in whatever way they can. Early in Team 1’s agile days, it had a ton of automated test “technical debt.” (I would call it insufficient test automation, but whatever term you like is fine.)
The developers often are able to finish their code first and then help the testers bootstrap their test automation. You can swarm in any number of ways. On Team 2, the UI, platform, and middleware developers get together to discuss for a couple of minutes and then write code together, each on their own computer. They have a team room, so they can see each other.
On Team 3, the platform and middleware developers pair, on one keyboard for all the code-writing work. The UI person works alone, checking in when she is done. Everyone checks their work into the code base as they complete it.
There is no right or wrong way to swarm. The only problem with an agile team is if someone is stuck and no one knows and that person does not ask for help.
Mob on the Work
When a team mobs on the work, it combines swarming with some of the pairing ideas. The team has a WIP limit of 1. And the team mobs around one keyboard and large screen, so everyone can see what the driver is typing at all times.
The team changes drivers on a frequent basis, say, every 10 minutes. Many teams use a very large television as a monitor or hook up the computer to a projector. Whatever you do, make sure the team is comfortable: everyone has chairs that work for them. Many teams who mob also use hand sanitizer as a matter of course.
Team 2 mobs. The entire team sits around a table with one keyboard. The monitor output goes to a projector so everyone can see what the person typing is doing.
This team has a guideline that it trades off “driving” (the person at the keyboard) every 10 minutes. Sometimes the tester leads, developing automated tests. Sometimes the developer leads. This team often uses test-driven development, so the tests guide their development.
Team 2 checks in at least as often as they change drivers. They use continuous integration. They find that the change of drivers with the check-ins helps them see if they break anything or if they need to refactor next.
The nice thing about mobbing is that everyone checks everyone’s work as the team proceeds. Everyone learns about the code and tests.
Years ago, I was part of a “tiger team” that had to find and fix a problem a Very Important Customer discovered. We mobbed on discovering the problem, all looking at the area(s) of the code that seemed to be the problem.
Once we had a couple of hypotheses, we swarmed—each of us using our expertise to contribute to solving the problem. We met every couple of hours to check in with each other.
We worked on that one problem, reviewing our progress and reviewing our code and tests as we proceeded. For some of the challenging code, we pair-developed and pair develop-tested, so we had multiple eyes on the code and the tests.
We wanted to make sure we found and fixed this problem. You may have had the same experience. At the time, we did not call it pairing or swarming or mobbing. We called it “finding and fixing the problem as a tiger team.”
Test at All Levels So Change Is Easy
Think about the kinds of testing your team might do:
Automated unit testing for the code to know that we can refactor easily.
Automated and exploratory story testing (acceptance testing) for a story to know that we have satisfied the story’s criteria.
Automated feature testing for feature sets to know that the feature set looks and feels as if we have a coherent view of it.
Automated smoke testing for a build to know if the build is any good.
Automated system testing for the entire system, from the API, so we have the ability to quickly know if we broke anything.
System testing from the GUI, possibly with some automation, so we know the first interaction the user has works.
Exploratory testing at the system level so we find the interactions and potential problems we didn’t or couldn’t find with automation.
It sounds like a lot of testing, doesn’t it? However, the more tests the team has —and the more automated they can make those tests—the faster the team can test. A nice effect of all this testing is that the tests support changing the code when the requirements change.
One of the problems with all this testing is that the team might not know how to do it. If the team thinks about automating as it proceeds and building tests even before developing the product, it will find this testing much easier.
Automate as You Proceed
The more the team can automate, the easier it will be for everyone to complete their work. Aside from build and smoke-test automation, do consider asking the testers to automate little tests as they proceed.
We were trying to find the “best” or “perfect” test automation tool. In the meantime, all the testers tested manually.
Well, it didn’t take too long before we realized the testers were the bottleneck in finishing features. We had so much testing to do—new and regression testing—that we almost fell into the trap of staggered iterations.
I stopped looking for the perfect test automation tool. Instead, I made a list of reasonable tools and asked people to experiment. Their job wasn’t to find the best tool. Their job was to test as quickly as possible to provide feedback to the developers.
Once they started automating, they actually found more problems. I hadn’t expected that. And problems that cropped up again and again? The testers gave the developers their tests. The developers were happy to use the testers’ tests to understand where they had gone wrong.
We decided to refactor our tests as we proceeded. That worked. Every few months, we need to assess our tests and look for duplicate tests—yes, we still have duplicates. But we have an organization and naming system that works for us. We don’t need the “best” test automation tool. We can refactor our way into good enough.
Use Testing to Drive Product Development
In the agile community, we have advocated for a variety of approaches for user testing to drive product development:
Test-driven development (TDD) is when a developer writes a test that fails (red), creates just enough code to make it pass (green), and when it’s time to add to that code, refactors to clean any messes.
Behavior-driven development (BDD) is for specification by example, where given a certain context when the user behaves in a certain way, then we can expect certain results. See Define Acceptance Criteria for Each Story, for more details.
Acceptance test-driven development (ATDD) helps us create tests by thinking of the acceptance tests for the product.
Each serves a different purpose. While you can use all three kinds of testing to think about the product, teams often use TDD for developing and refactoring with unit tests as they proceed, BDD for a feature or feature-set testing with examples of behavior, and ATDD for system testing with examples of how the user might use the system.
When the entire team collaborates to write stories with acceptance criteria, as discussed in Create or Refine the Stories as Preparation for Future Work, the team can create examples that guide its testing.
Often, the testers will see devious, strange, and horrible possibilities for the story. When the entire team starts to think about “what can go wrong,” the product owner might see ways to create several stories.
Why test first? When we think about the tests first, and what would make a test pass or fail, we think about more possibilities for the product’s design and use. Our thinking is richer. That means we can question and refine the requirements.
For many years, requirements problems have caused problems in the code and the product. Anything that helps teams clarify and refine requirements will have a payoff in the future of the project.
Here’s the real value of all this testing: one of the big problems with changes to requirements is knowing whether or how the changes will affect the rest of the product.
Tests provide support for changes. The team has much more confidence in its code and the changes to that code when using tests as support. The team can know what “done” means at several levels: a given story, the entire feature set, and the project.
When the product owner realizes the team needs to change a feature or a feature set, the team and the product owner can have a deep conversation. When the team members ask for examples for ATDD and BDD kinds of testing, the product owner clarifies the new actions the product owner expects.
I use a form of ATDD and BDD development to write my articles and books.
I find using those approaches clarifies my thinking and therefore my delivery.
Beware of Technical Debt and Cruft
If you work on a legacy application, you probably have a code base that is not clean, with all kinds of supporting tests. Let me address what you have and how you might fix it.
We hear a lot about technical debt. I have consciously made the decision to meet a trade show deadline or to meet a demo date for a Very Important Customer. We scripted the demonstrations of those products and told the people running the demos not to stray off the very straight and narrow path.
We didn’t add in all the alternative paths. We didn’t do input-checking for bad input. We didn’t work on performance. We did the bare minimum and it wasn’t pretty.
We made the deadlines. We had code for a specific, limited application. We didn’t have enough time to do “all” of it and we were willing to trade off time to make something we could show. That’s a conscious decision to take on technical debt.
Here’s an alternative scenario: You realize after you wrote the code that there is a better way to make that code work. That’s not technical debt. That’s learning. And if you need to address performance or reliability in that code later, that’s a good time to change how the code works.
However, too much of the code I see is a mess. The developer(s) didn’t think about how to structure it. The developers didn’t test it, or didn’t test it well. The testers never got a real chance to test it, or the tests are insufficient for the code. That’s taking a shortcut and it’s not technical debt. That’s a mess— cruft.
Technical Debt Is Not Unfinished Work
Too often, we discuss unfinished work: insufficient refactoring, insufficient test automation, anything that we didn’t complete, as “technical debt.” That’s not debt. Debt is something you plan for.
If you, as a team, decide to take on technical debt, that’s fine. It’s a team decision that you will not address this root problem in the code or tests. You make that decision consciously.
However, if you don’t make the decision consciously, you “just” don’t finish the work—you don’t have debt. You have cruft, bloat, and possibly unneeded complexity, unfinished work.
One way to help the team avoid technical debt is to create automated tests for release criteria, as described in Develop the Release Criteria. Sometimes thinking about ATDD and BDD tests and automating them (as much as reasonable) can help the team see how to write good code and keep it clean.
Work at a Sustainable Pace
Too often, teams feel pressure from someone outside the team to “do more!” That’s often accompanied by the depressing “with less!” I don’t know of a way to do more with less. I understand how to do less with less. Much of that less is thinking.
I said at the beginning of the blog we should optimize for reading the code since team members tend to read a lot more code (and tests) than they write. Why?
Because people are looking to see if someone has already done this thing somewhere. Or this piece of functionality looks more like an octopus, with tentacles dangling into multiple places in the code or tests.
When people read the code, they think. When people discuss what to do in the form of a small story and how to do it in the form of design, they are also thinking. Sometimes they think collaboratively with other people when they define stories or acceptance criteria. Sometimes they think alone. However, they think.
Software development—in fact, most of the knowledge work—is about the thinking ability of the people developing the product. That means people need space and time to think.
Some people can manage to be inside a team room and still think. Some people can’t think there—they need a private place to think. For me, even more, important than having space to think is having time.
When managers or product owners pressure a team to deliver instead of think, the team creates defects. We see this effect when we multitask. We see this effect when people take shortcuts when they shouldn’t. Artificial deadlines don’t make it easy for people to deliver.
Small stories make it easy to deliver. If you need high-quality code, the technical practices, especially around review and testing, make it easy to deliver. Pressure does not.
I have never seen teams deliver under sustained pressure. I have seen teams deliver with very brief pressure, a break, and then back to normal time at work. That means if you want sustained delivery of features, you should create a project that has a sustainable pace.
People work together for a six-to-eight-hour day, five days a week. Some teams understand how to do ten-hour days. Some teams actually take time off in the summer, working four eight-hour days.
If your team pairs or mobs, they will be exhausted at the end of somewhere around six to seven hours a day. They have finished what they can. Encourage them to go home and recharge.
I have seen many teams improve their throughput when they stopped working overtime. I have seen too many teams, agile or otherwise, lose momentum and create problems for themselves when they pushed to work more hours than they could sustain.
If you want your team members to do “more,” make sure they aren’t spending time in unnecessary meetings, that they aren’t multitasking, that they work on the highest-value work, and that the work is small.
Use Technical Excellence to Speed Development
I said at the beginning of the blog that project speed is a function of the code and tests that already exist, the technical excellence of those codes and tests, the clarity of what we want to do next, and the complexity of what we need to do next.
As a leader, I recommend you invite your team to consider these possibilities for increasing and maintaining the technical excellence of your code base. When I teach, I ask the teams to swarm for an hour on a small story to see how close they can get to finish a story in one hour.
Many teams finish the story in one hour, including automated unit and system tests. They are thrilled with their progress and start to see how to use these approaches to work in a way that is fast and fun.
Your team might have to use shortcuts for a limited time, for a specific reason, such as a trade show or a demo for a Very Important Customer. But shortcuts, over time, will slow your product development.
You will have more escaped defects, the cost to fix a defect will be high, the team’s cycle time will increase, and your team will find it even more difficult to estimate.
There are many books and many online resources for creating technical excellence in the code. Here are some I particularly like:
One of the problems with craftsmanship is that too often people think about software-development craftsmanship. In my experience, testing requires just as much—if not more—craftsmanship. Consider these books for learning about a variety of testing practices:
There are plenty of other books and online resources about how to develop your team’s capabilities with more testing support. I encourage you and your team to discover them.
Recognize Excellence Traps
The technical excellence traps are about thinking you can get speed by not doing the necessary cleanup as you proceed.
Thinking the team can proceed faster without refactoring code and tests Waiting for other teams to test the team’s work
Feeling like no matter what you do, the defects multiply—or they never seem to decrease
You have options for managing these traps.
Trap: We Can Go Faster Without Clean Code and Tests
I have met people who want to postpone refactoring of code and tests because they think the team will proceed faster. Or they don’t want code review or some other way to get multiple eyes on the code, such as pairing or mobbing.
You can’t go faster when you avoid technical excellence. Sure, your team might be able to finish a demo or make a trade show. That product is not going to work in production environments without problems.
Don’t trade speed of delivery for excellence in production code. Your team will create technical debt and cruft. Technical excellence creates speed.
Trap: Waiting for Other People or Teams to Test
Some teams don’t have all the skills and capabilities they need. Often, they don’t have enough tester capability. When a team doesn’t have enough capability to test at all levels, it ends up waiting for another team to test its work.
That increases the cycle time and creates WIP. Too often, the team receives feedback about earlier work. That feedback is an interruption, a cause of multitasking.
Trap: Defects Prevent the Team’s Progress
Teams discover many causes for their defects. If they don’t practice keeping the code and tests clean, the code and tests can become so complex that it’s impossible to make progress.
If your team’s cycle time increases, or if the fault feedback ratio becomes too high, consider the following possibilities:
Identify the root cause(s) of the last six to ten defects. With any luck, they will share root causes. Here are some possibilities I’ve seen: fixing one defect uncovered more; cascading defects, where one defect causes several more; and the code is so complex that finishing anything is akin to climbing Mt. Everest.
If the team understands the root cause(s), see if there is a handful of defects—which, when the team fixes them, will help it proceed faster. Sometimes the team needs to fix only a few things before it can make progress.
Ask the team if it’s collaborating and refactoring as it proceeds. Maybe it needs a practice radar chart to see if its practices lead to clean code.
For example, one team started to chart several practices when it started its agile adoption, as illustrated in the radar chart that follows. The team experimented with these practices, under the assumption that if it practiced these ideas, it would have better throughput with fewer defects and a lower fault feedback ratio.
The team worked on its technical practices to see if the practices helped the team’s throughput and defects. After three months, the team’s chart looked like this one:
The team wasn’t perfect in the adoption of its chosen practices. However, it had many fewer defects, its throughput was up, its stories were smaller, and it was seeing the end of overtime.
The team had started with code review and moved to pair. The team was thinking about TDD or BDD as a way to help its unit test and system test automation. It used its practice chart as a way to help the team think about its improvement.
You, as a leader, might need to work with the product owner to make sure the team has the opportunity to fix problems—even problems not related to the features the team is working on now—to move toward a clean code base. Those problems might be code. More often, I see insufficient testing. Your team might have both problems.