Am I doing it right? A check up for agile teams

Even on the best teams, things need to be monitored and adjusted. If you are doing this for the first time, it can be even harder. In this article, I share some signals of what success looks like and what to do if you are stuck in one of the many common pitfalls.

Agile is a philosophy where you listen to the people you are trying to serve, you learn from mistakes, and keep trying.

The goal of agile is to frequently test what you build with people that will use the product or service. So you don't make the wrong assumptions about what your customers need. You change your plans based on what you learn from testing. You build things as early and as small as possible so that when you make a mistake, you don't go too far in the wrong direction. Keep repeating your process, keep learning and researching, change your approaches or even your goal based on what you learn.

In practice, agile looks like building something small that can be completed within a few weeks, and then seeing if it's any good. This is a continuous process- you repeat, repeat, repeat.

Here are some good signs that your agile team is going in the right direction:

• The whole team collaborates on solutions and implementation ideas
• You are adding to or improving your product in production at least every two weeks
• You catch mistakes early and fix them quickly
• You changed your plans based on usability testing

These good signs show that your method is working well. However, it is just as important to notice and understand bad signs. Bad signs can be very helpful to finding ways to improve your processes.

These are some extremely common "bad signs" teams can run into when they are trying to implement agile business practices. For each one, I will dig into common causes and show how you can get back on track.

You have many, inflexible deadlines for features over the next few years

There will always be deadlines and mandates, especially in government. Executive support and good project management can have a huge impact in defending agile practices.

In agile, You have to try to minimize commitments and keep stakeholders focused on outcomes. For example, instead of committing to a series of features for a user sign-up process, commit to a date for having a mockup or prototype of a sign-up process, a date for having a sign-up process in testing, and the final date that this new workflow will be in production. This way, you are agreeing on a process and outcomes and giving your team more latitude to problem solve and find a better solution.Try to manage up to emphasize how the organization will benefit from agile approaches and show examples of what agile leadership looks like.

This is an especially hard problem for agile teams without enough executive support. If that is your situation, it is the responsibility of the product leader to try and mitigate these effects. This is more effective if the person running the project is a permanent employee and not a contractor. Vendors are essential to success, but outsourcing oversight and responsibility for projects is a gamble that doesn't often work. To increase chances of success, have at least one full time staff member devoted to the success of each major project.

If you are the product leader make sure there is some slack in the schedule when making your roadmap. Some things will go wrong, or some new need or emergency will emerge. A helpful adage for this situation is: it is better to under-promise and over-deliver.

Tasks or tickets take multiple sprints, things keep getting pushed to the next sprint

This is an extremely common pitfall, even for experienced agile teams. There are a few ways to address this pitfall, but essentially you need smaller and more frequent workflows.

Spend more time breaking tasks into smaller pieces. This may sound simple, but it is a skill that must be learned through practice. If you do not already have weekly or biweekly time set aside for agile ceremonies like backlog grooming, start there. Breaking work into smaller chunks takes time and collaboration..

One thing that might be helpful is making templates for your tickets that prompt more detail in what the task is and how you will know when the task is finished. Answer questions like: What is the user story? What is the end result? What will it look like? Have a clear, verifiable definition of what "done" means.

Spending months of research in the beginning of the project

It's very common to see people keep their waterfall plans and just replace the "requirements gathering" with front-loaded "user research." This is an improvement if you are incorporating usability research with people that will use your product or service. However, if you don't change the structure of how you work, you won't see all the benefits of agile.

It is good to take some time to understand who your product or service will serve and what problems you are trying to solve. Once you confirm that you are solving the right problem, get something useful to production as quickly as you can. You need to keep researching what your product needs throughout its lifecycle. If you only do this at the beginning, you won't be able to adjust when needs or context change.

As you build, use usability research to verify your assumptions are correct and think of new solutions to solve for the needs that arise. It is better to start something now and find out that it is wrong or unnecessary early, instead of three months from now when you realize you did a whole bunch of research you don't need. Or even worse, in three years when you have built the wrong thing.

One person makes all the decisions and architecture choices

To get the benefits of agile, you need the whole team and organization engaged in the problem solving process. While there will always be hierarchies in teams and departments, agile teams require a more collaborative decision making approach. By using the whole team to think of creative ways to solve your problems, you get the benefit of the whole team's brain.

If you have been transitioning to agile but are not seeing increased collaboration, there are a few things you can do to create a more collaborative culture. People on the team need to know that it's safe to contribute and that their opinion is valued. You will have to show people this is the case and earn their trust. You also need to make sure that you are promoting a culture where leadership doesn't mean one person is a "rockstar" on the team. Celebrate the kind of leadership that supports the talents and abilities of team members.

It is hard to make a change or roll back a change

If making changes to your systems scares you, this is a sign you need more automation and more DevOps practices. DevOps, or DevSecOps, are practices to automate creation and deployment of software.

DevOps practices include cross-functional collaboration where people with different specialties are working together to solve problems. Adding automation decreases the amount of staff time and standardizes deployment to make results more predictable, and more frequent deployments reduce risks when making changes. Finally there is automated and manual testing to ensure quality of application, infrastructure, and security.

Source control is a great place to start with DevOps practices. Make sure all your code and configuration is in source control. This means everything from infrastructure set up, to database routines to internal app configuration. Using source control for everything  is the foundation for adding additional automation. If you already have these fundamentals in place, good next steps are managing data migrations and automating deployments.

Every project can benefit from better documentation. Concise, plain language documentation of how your system works, why you have made your technical choices, and what your business requirements are. Make sure people know who is responsible for updating what documentation. Bad or outdated documentation can be more detrimental than no documentation.

Last but not least least, use automated tests. If you are looking at an established project, a good place to start is to add tests as you fix bugs and add new business requirements. Try not to make the same mistakes twice.

Large backlog of bug reports

This is a very important signal for project health but there can be quite a mix of causes.

In the best case scenario, the project can improve by implementing stricter prioritization. Make sure you are prioritizing fundamentals before new feature requests, to avoid adding to your  technical debt. Moving and growing a product quickly is sometimes necessary, but budget time for refactoring and additional documentation after any compressed delivery schedule. If you don't act proactively, you will have more technical debt to pay down later.

The cause may be that your project is just understaffed. If you try to run a large project with too few people, even the best prioritization will not allow you to meet the needs of the product or service. Try to be clear to leadership when this is the case and provide evidence that you have ruled out other possible causes. For example, explain any efficiencies you have introduced or research similar projects and what their staffing levels are.

In the worst case scenario, you need to replace your system. You are responsible for your systems and data that people entrust to you. It is better to fix something if you can, but there is a point when a system cannot be salvaged and needs to be replaced. Getting more people to work on a broken system will have diminishing returns. If you have too many "cooks in the kitchen", it will slow down your schedule and delivery cycle.

Flooded with change requests and upcharges

If you are trying to implement agile without using agile contracting methods, you may get stuck  with change requests and upcharges. This is a clear sign that you need to change your contract structure.

If you are doing agile, you will not have all of your requirements in advance. The benefit of agile is that you have flexibility to make your product better as you go. To do that, you will need to adjust your plans and not have features tied-down in advance.

It is normal to feel like this is impossible to implement when trying it for the first time. That is why it is beneficial to start with a small pilot that proves the method can work in a low-stakes environment, then learn from that process and scale up when you are ready.

We call our method of structuring agile contracts, modular contracting. When we use modular contracting, we see improved quality, lower risk, and projects delivered on time.

The fundamentals of modular contracting:

• Don't enter into contracts longer than 3 calendar years.
• Cap each team's budget for labor at no more than $10 million total; that typically means between $1.5 and $4 million a year for a team of 6--9 people.
• Instead of listing all requirements, describe your problems and goals in a Statement of Objectives. Describe user stories that deliver real value to a specific user.
• Make your deliverables working software. Reports can be useful, but what you're paying for is software code and configuration.
• Make sure that the data and code is in the government's possession and not something you'll have to pay to access later.
• Pay for work incrementally using a time and materials contract.
• Create real accountability by setting objective measures and tests. This Quality Assessment Surveillance Plan shows how you can monitor and review delivered code so that it's well written enough to function properly for the public that will be relying on it.

Here is an example of an RFP from the U.S. Tax Court that embodies this approach. This project successfully replaced a legacy system with a new one, Dawson, that has been lauded as a huge improvement. You can read more about this methodology in the in-depth 18F Derisking Guide.

You feel like you are doing the same process, but the meetings were renamed

This is a sign that you still need to implement some changes to transition away from traditional, waterfall project management. A good place to start is replacing detailed plans with a project roadmap. Culture is a huge component of agile adoption that takes time and practice. A good starting point for culture is focusing on how to make meetings more collaborative. How do you need to change your culture so that people are eager to contribute?

If you feel like something is wrong, listen to your feelings. Ask yourself: why do you feel this way? Are you out of your comfort zone or are there some doubts hanging over you?

If you feel that things are not working, talk to your team constructively, without trying to blame individuals or teams. Talk about why you think things are not working and frame the discussion around what it would take to make sure you meet your end goals.

Change is hard

It is easy to look at a wall of problems and then get discouraged, but this is not an all or nothing journey. In your projects, think about your transformation in an agile way. Try to find small, meaningful changes that you can make now and use as a foundation for additional changes. It can be good to try and implement change incrementally. By using phased approaches like pilot projects, you can increase your chances of success. Seeing an example of a working project can be an extremely powerful communication tool. It is the best way to win over well-meaning people who (for good reasons) are skeptical of new ways of working. If you can find a small team and set them up for a small success, you can set the stage for widespread change.