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 post covers:
The agile movement kicked off in 2001 with the agile manifesto. It emphasizes…
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.
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.
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.
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.
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.
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.
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.
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.
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:
People on the engineering team write, test, and deliver code.
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.
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.
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.
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.
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.
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. 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.
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.
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.
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.
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.
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.
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.
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.
We also reviewed the SCRUM ceremonies we followed, so that we would benefit from them.
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.
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.
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.
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.
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.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.