A Conversation with Marjorie Toth on the Importance of Team Collaboration for Agile Product Development

Marjorie Toth Presentation
Marjorie Toth presenting agile at AACC

Invetech has adopted agile methodologies for in vitro diagnostic (IVD) instrument development, transforming the product development process to achieve more resolved product solutions, improved development predictability, and consistency in meeting development schedule targets.

This article is the final installment of our three-part series featuring discussions between Rob Danby (Vice President of Diagnostics at Invetech) and Invetech team members sharing their insights and learnings from applying agile methodologies to instrument development projects. In this article, Diagnostics Program Manager Marjorie Toth discusses team collaboration and transparency—a key element of the agile process.

Rob Danby: Can you tell us about yourself, your role at Invetech, and a bit about your personal experience using agile for product development?

Marjorie Toth: I am a program manager within the diagnostics group at Invetech’s San Diego office. I’ve been with Invetech for about two years, and have run at least three different projects that have used various pieces of agile development. In my most recent project, we used all the elements of agile, from establishing visual management in an Obeya workspace, to using customer-centered design and rapid iteration and prototyping.

Rob: What is an Obeya workspace as it applies to agile product development?

Meeting Room, or ObeyaMarjorie: “Obeya” is a Japanese term that just means “big room.” At Invetech, we apply this concept by finding ways to bring all the aspects of the project together in a single area at the start of a new program. This includes co-locating all the core project team members and moving all the key resources into one area. We also try to designate spaces in the Obeya for people that may not be working on the project full-time, such as our clients or the contract manufacturing representative. By having spaces where they can then come and work with the team on a day in and day out basis, they can be part of the program even if they’re not 100 percent dedicated to just that project.

The Obeya also provides an area to display critical information about the product development project, such as: key risks, key functionality, what’s important to the customer, the value proposition, and key differentiators. Often referred to as visual management, posting this essential information in the Obeya workspace allows the team to be immersed in the product and the project, and keeps them aware of the things that are most important to making the project successful.

Rob: What are some of the biggest benefits that you’ve seen from co-locating the entire product development team?

Marjorie: One of the key benefits has been the informal communication that happens. Someone just overhears two people talking about something that they either have an interest in or can contribute to. They will just pop up out of their desk and join that conversation; whereas in a more formalized waterfall type of product development approach where you’re scheduling weekly team meetings, you might not think to involve people that are tangential to a project or aspect of the project that you’re discussing. You lose that benefit of someone who just might have the key idea because you didn’t think to invite them to the meeting.

Rob: In situations where co-location of all the team members isn’t possible, how do you incorporate them?

Marjorie: When we have teams that aren’t necessarily able to be co-located—and certainly in a lot of cases we have Invetech associates in our Melbourne office that are part of a project team running out of our San Diego office, and vice versa, and we have our client team—what we’ve tried to do is make the best uses possible of technology. In some cases, that could be setting up meetings through WebEx or Skype for daily stand-ups so that the team members in Melbourne can participate remotely. This allows them to be able to see, to the extent possible, what’s happening live.

With our clients, a lot of times what we’ve tried to do is duplicate the master schedule at their site so they also have a visual representation of the entire schedule of the project. Even though it’s not necessarily “live,” we can replicate the activities that are happening so that visibility exists in both areas.

Rob: Can you tell us a bit more about the master schedule and how it is used?

Marjorie: The master schedule should be a representation of the entire schedule of the project. At the highest level, it should include key milestones such as when specific prototypes must be done, when certain testing needs to happen, or when design reviews should occur. Below that is information about the various work streams, the activities it’s going to take to achieve the key milestones, and the interdependencies.

For example, in a typical product development team, you have hardware, software, electronics, mechanical, manufacturing and process development. Sometimes you also have the assay, or the science piece. The master schedule allows you to see how they all interact—not just between each function, but also in delivering a subsystem. So rather than just saying, “The electronics group is going to design this board,” you can focus on, “What is it going to take to get this optic subsystem up and running?” That involves the electronics boards having to be ready, cables having to be ready, the software having to be ready, all the mechanical components having to be ready, and more importantly, it must all get put together and tested. The master schedule enables you to visualize these functions and how key modules interact with each other in a single work stream.

Schedule Board

Displaying the master schedule in the Obeya allows the team to see, not only what am I focused on today, but what’s the next thing I’m going to have to worry about. It provides a more holistic view of what has to happen in the overall project.

Rob: How does agile differ from a more traditional product development process?

Marjorie: Primarily, it differs from a standpoint of the cadence of how the project is run. In a “waterfall” or more traditional/sequential product development approach, you typically have a master schedule that’s often done in Microsoft Project, probably on a monthly basis. You’re likely just looking at that schedule to assess the status of the project and maybe making a few changes.

With agile, it’s all about sprints, which are set periods of time during which specific work has to be completed and made ready for review. Within each sprint—which could be anywhere from two to four weeks—you’re keeping the broader schedule in mind, but focusing on the dynamics of what’s happening in that shorter period.

This agile method allows for a “plan-do-check-act” cycle that is so important in things like lean and continuous improvement. Within each four-week period you’ve accomplished tangible things and you have a chance to put your head up and say, “Has anything changed?” and then plan the next four weeks.

Rob: Why has Invetech adopted this approach to product development?

Marjorie: I think primarily because it helps to improve the predictability of a project. Invetech has always been very interested in reducing risk for our clients and focusing on early risk mitigation activities. Agile methodologies support that effort quite well by using rapid iteration and prototyping, as well as customer-centered design principles, to make sure we’re developing the right product at the right time. In addition to that, designating an Obeya workspace and using visual management helps improve communication, collaboration and transparency amongst the team which, in my experience as a program manager, are essential for a project to be successful.

Rob: With this agile approach to product development, how does the management team stay up-to-date with the project process?

Marjorie: Using agile methodologies has really helped to improve transparency to management. In a more traditional approach, oftentimes you would have a more formal executive review maybe once-a-month where you present the project status. The team spends hours figuring out how to condense a month’s worth of activity into a PowerPoint presentation that’s at a high enough level to give the management or executive team a sense of what’s happening with the project.

With visual management, everything is out in the open and posted in the Obeya. Whenever the project sponsor or executive management wants to see what’s happening with the project, they can just walk into the Obeya area and they should be able to, within five minutes, get a sense of, is the project on schedule? What are the key activities the team is working on? What are the key risks? What are the actions? What’s the team doing to try to address something that has happened?

From my perspective, this approach is more reassuring because there isn’t a lot of time spent trying to put together a status presentation, and more importantly, it’s a dynamic thing where whenever the executive is interested or has time, they can stop by and see what’s happening. They don’t have to wait for a scheduled meeting.

Rob: A lot of what you’ve described must represent a significant change for many members of the team. Do you have any recommendations for getting all the team members on board with this new approach?

Marjorie: You’re right. It is a completely different way of operating, and some people have a harder time adjusting than others. Some of it is training to make sure that people understand why this is important, and more importantly, how it is going to help. How is it going to help us to be more successful? How is it going to help improve the communication? How is it going to help make their jobs easier? I think once you communicate that, you can overcome some of the initial reluctance.

However, you may still need to provide additional support for people that are struggling and you should try to better understand their concerns. Is it just because it’s new? Is it because it’s causing problems or slowing them down in some fashion, in which case you may have to make adjustments on the fly?

What I would suggest is that you take it slow, and keep an eye on what’s going to make this the most productive for the team. It’s the gentle relentless pressure of saying, “This isn’t an option. We are going to do this. However, we want your participation and involvement in figuring out how to make it the most effective for this particular project.”

Rob: Do you have any lessons learned or pitfalls to avoid that you would share with other companies looking to adopt agile for product development?

Marjorie: I would say two things. Don’t try to do too much all at once, and make sure that the team is involved. There is often a desire to implement things from the top, and while management involvement and support is critical to this, in a lot of cases, what you really need to do is find a champion that’s part of the team. You need someone who has the respect within their peer group, so that this isn’t just another management initiative.

What I have seen is the potential for having even myself as the program manager come in and say, “Okay, we’re going to do agile. I’m going to put up the master schedule. We’re good. You guys just follow this.” It’s much more effective in my experience to start small. Maybe have the program manager lay out the concept, and a straw man of what the program schedule could look like, but then get the team to participate in saying, “Alright. What activities would we have to do in order to make that happen?”

One last thing I would add is that it’s okay to make mistakes. In my last project, we had to re-do our master schedule four times. Each time we found that although it got us to where we needed to be, as we started using it, it just wasn’t exactly what we needed. After a few iterations, we were finally able to figure out as a team the right level of granularity and the appropriate level of detail of the specific tasks so that everybody understood it and could actually use it.