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.