Screw SCRUM: Guide to Building a Truly Agile Organization

Screw SCRUM: Guide to Building a Truly Agile Organization - Interview with Tyler Hartley (Director of Software Engineering, Johnson & Johnson)

Becoming an agile organization has its own set of challenges.

If you want to embrace the agile approach to incrementally improve your product, you have to transform the mindset of the entire organization. That means changing the way teams approach problems as well as the way success is measured while delivering valuable iterations that benefit customers.

Tyler Hartley, Director of Software Engineering at Johnson & Johnson, shares his thoughts and experience on agile organizations. He talks about common mistakes made in agile organizations, each department’s role in an ideal setting, facing challenges and recognizing success.

This blog post is written based on episode 66 of the Level-up Engineering podcast hosted by Karolina Tóth.

This post covers:

• Defining agile
  • Agile organizations - The spaceship example
• How to spot an agile organization
  • As a customer
  • As an insider
• Agile organizations in practice
  • Set goals
  • Product focus
  • Define roles
• Leaders’ role in an agile organization
  • Welcome change
  • Focus on milestones
  • Don’t expect perfection
  • Encourage vulnerability
• When not to choose agile for your organization
• Agile products - Story from J&J
• How to overcome challenges
  • Know the frustrations
  • Define success metrics
• Typical mistakes of making an organization agile
  • Forcing rituals
  • Limiting agile to engineering
• Becoming agile - J&J’s story
  • SCRUM ceremonies revamped
• Recognizing success in an agile organization
• About Tyler Hartley

How do you define agile?

The agile movement kicked off in 2001 with the agile manifesto. It emphasizes…

• individuals and interactions over processes and tools,
• working software over comprehensive documentation,
• customer collaboration over contract negotiation, and
• responding to change over following a plan.

Most people associate agile with SCRUM ceremonies, but there’s more to it. Agile means different things in different environments. The essence of agile is to respond to change quickly, because you can’t predict every change or issue you’ll run into during a project.

It doesn’t mean you can’t make a plan. Agile is about making a plan but knowing it will change over time. You have to welcome those changes, because they will improve the end product.

Do you need a spaceship?

If a customer wants a spaceship, it’s impossible to deliver that in an agile fashion if your measurement of success is a deadline.

As an agile leader, you should first find out what the customer wants with your product. It might turn out that they don’t need a spaceship; they just want to cross the country quickly.

So, in the next sprint, you can build a bicycle. It’s not a spaceship, but the customer may find value in it. Then you can make small changes—add a motor or another wheel, working towards the perfect product in an agile way.

What does an agile organization look like?

Customer POV

If you are a truly agile organization, you’re constantly iterating and improving your product, and your customers recognize your efforts. It’s crucial to measure customer satisfaction by metrics applicable to your business, and to see if your target audience recognizes you as a constantly evolving business worth their trust and money.

Insider POV

Changes are for improvement

From the inside, a truly agile organization resembles an amoeba: it’s constantly changing shape based on its environment. It never remains the same for a long time.

The reason is that you have to define the minimum lovable product, then you gather input from all stakeholders, including sales, marketing, design, engineering, and the customer. Based on this feedback, your engineers can keep iterating the product to add value.

Small mistakes are easy to fix

When you make small incremental improvements in the product, the penalty for making the wrong choice is small. You'll quickly find out that you messed up. Negative metrics can guide you, so failing can be valuable, because it tells you where not to go.

Agile doesn’t have an end point

Being an agile organization means constant change, constant work, and constant evolution. This endless growth also means that there is no agile Nirvana. There will always be things to improve, changes to react to, and methods to rethink.

How can we put the agile philosophy into business?

Shared philosophy

A shared philosophy is crucial—your business won’t be able to thrive if everyone focuses on different objectives. It’s not only up to the engineers to create an agile environment; your sales and marketing teams also need to react to the small iterations quickly. If you want agile to work, the entire organization has to follow the agile philosophy.

Product focus

Although product, design, and engineering teams all play different roles in the product development process, good ideas can come from anyone at any stage.

Everyone has to be dedicated to the product. The job of product managers and engineers go hand in hand. A small code change can have unexpected effects on different parts of the product. It’s crucial that engineers understand the code and the impact it’s intended to have on the customer.

If your engineers have end-to-end ownership of a feature, deep understanding of the product is essential. When they are single-handedly responsible for writing, testing, and deploying a new feature, they must understand the intent behind it.

When your team is strongly product-oriented, changes are welcome, because everyone is working towards the same goal. That makes an organization truly agile.

Clearly defined roles

An agile organization must have clearly defined functions, and people must understand the role they play. If they are concerned with other people’s tasks, or if they are unsure of their own role, you can’t make progress and react to changes quickly. Ideally, the departments’ roles are the following:

Engineering

People on the engineering team write, test, and deliver code.

Design/UX

People on the design or UX team receive feature requirements, and they collaborate with the engineering team to model how that requirement is going to land in the user experience.

What can leaders do to create an agile organization?

As a leader looking to create an agile culture, you must drive the processes that lead to a more agile organization. You can encourage certain behaviors to support this shift in mindset.

Welcome change

Changing requirements can be emotionally hard, especially if you learn them late. They invalidate hard work that has already been done.

However, don’t be frustrated about missing a requirement. Be glad you found out about it, and encourage your team to do the same.

Focus on milestones

If you’re focusing on deadlines instead of milestones, you are doing the opposite of agile. This doesn’t mean that deadlines and commitments are useless; it just means that they’re not accurate measurements of success for an agile organization. As an agile leader, you should measure the incremental value for customers instead.

Strive for “pretty good”

Don’t expect perfection immediately. Agile means striving for pretty good. As your customer base is evolving, your product will improve as well, and so will your team and their practices. “Pretty good” provides a stable starting point from which you can iterate later on.

Be vulnerable

Agile creates a constantly changing environment. That can be stressful at times. As a leader, you should lean into vulnerability—it’s one of the most valuable skills your team has to master. Other people's stories on leadership can also help you achieve this mindset. 

Know that there’s an effect between team and product: if you want your product to improve, your team must constantly do the same. Without a well-organized team lead with empathy, it’s impossible to make decisions or changes in your product smoothly.

Is agile always the most beneficial working method?

There are cases when the Waterfall or Spiral approach is more suitable, depending on the product you’re building. If you have to deliver something that you can’t incrementally update later, like the Mars Rover for NASA, you only get one chance to get it right, and you have to plan accordingly.

In terms of software engineering, some 1.0 launches are hard to manage in an agile way. It’s because you don’t have an existing product to improve upon, so there is nothing to add new features to.

Make sure your team doesn’t get into bad habits during the initial phases of product development. Once you get to the 1.0 version of the product, you’ll be able to iterate and become a truly agile organization.

Agile products - A story from Johnson & Johnson

We worked with a recording hardware for operating rooms. We were consulting surgeons in the process of building a software for it. They were the key opinion leaders, and they told us what features they needed.

Our team was working on a video recording feature, and we thought that including a passcode would be useful. Surgeons would have exclusive access to the recording tool, and they could ensure that they were the only ones who could start and stop the video.

The feedback we got was an unequivocal no. They told us that they wouldn't care about pushing buttons in that high-stress environment, and that they would probably put the passcode on a sticky note on the device, making it pointless.

We removed the feature because it didn’t add value. It only created friction.

That feedback led to an ongoing philosophy that these services must aim for zero friction and zero effort.

How do you overcome the internal resistance when trying to go agile with your organization?

Know the common frustrations

Most people are uncomfortable with agile due to the lack of predictability. You can’t plan months ahead, let alone give people a 2-year roadmap. Even the success of each small product iteration is hard to measure, and that can cause frustration.

Customize success metrics

To see the added value of each iteration, you must pay attention to agile deliverables. Success metrics need to be tailored to each feature, because you can’t measure different things with the same set of criteria.

Define the success metric for the engineering team, and set up an analytics engine to gather data and an analytics team to dissect that data. That way, you’ll be able to provide a clear picture to your team, even with the inherent unpredictability of agile.

What are the typical mistakes an organization can make when going agile?

Forcing unnecessary ceremonies

The most common misconception is that agile is a set of ceremonies. In reality, you don’t have to do any of the SCRUM rituals in order to be agile.

Limiting agile to engineering

Your entire business has to be agile, not just specific teams. Engineering is the heart of a software engineering company, but all departments must have the same work philosophy, with the same goals in mind in a truly agile organization.

What's the story behind J&J building an agile organization?

In the field of medical devices, agile isn’t the most suitable method most of the time. There were many different needs and inputs that we needed to include in our product, so we used the Waterfall method. We thought that we had to plan out the entire launch and then work according to that plan.

Things weren’t going as planned: we missed deadlines, we discovered gaps, and we had to make unexpected changes. It came out in our retrospectives that we had issues understanding all the input and we needed help.

After that conversation, we hired a business analyst whose job was to gather all requirements and inputs from stakeholders. This helped us define deliverables and achieve a consistent velocity, so we could project out the perfect Waterfall timeline.

But instead, this started us down the path of becoming an entirely agile organization.

SCRUM ceremonies at J&J

We also reviewed the SCRUM ceremonies we followed, so that we would benefit from them.

Stand-ups

We moved to having stand-ups three times a week instead of five. We didn’t have major updates every day, and collaboration was strong enough on Slack throughout the week, so daily stand-up updates weren’t necessary.

Sprints

Two-week sprints remained useful. We still had to plan and groom out the work.

We started measuring progress in points instead of hours. A point translates to half a day’s work. Each sprint, we gave 15 points per person, and compared them at the end of the sprint to see if the workload was well-distributed.

Retrospectives

Sprint retros are one of the most important conversations. They help your team look back on what went well and what didn’t. Retros also help in tracking improvement, disclosing recurring issues, and addressing any ideas or problems.

What are the signs of your organization becoming truly agile?

Although agile doesn’t have a specific end destination to reach, you can tell whether your team has embraced it or not. When you have psychological safety within the organization, and everyone is brave enough to welcome questions, to make changes, and to be vulnerable about the frustrations they have along the way, you have reached agile Nirvana.

When your organization is truly agile, your product is based on functionality and customer feedback. You retire useless features instead of sticking to your initial plans. You are ready to respond to changes quickly and effectively.

In that environment, people are collaborative, the product is constantly evolving, and your customers recognize the added value. This is why it’s important to become an agile organization. When you, your employees and your product all become agile, you can reach this ideal state.

About Tyler Hartley

Tyler had two major transitions throughout his career: he shifted from biomedical engineering to software engineering, and then from being an individual contributor to becoming an engineering manager. He’s passionate about building functional teams and creating harmony within them.

He’s been Director of Software Engineering at Johnson & Johnson for 3 years.