At our July TechDebate in Chicago, the panel discussed the value and challenges of agile development methodology from several different perspectives. After the event, I had the opportunity to have a follow-up conversation with the event’s moderator, David Radzialowski, owner of Third and 10 Product Consulting.
Sphere Software hosts a series of TechDebates around the world. For more information or to register, visit www.techdebate.org. Also, we’re always on the look-out for debaters—if you have something to say, let us know at https://techdebates.sphereinc.com/debater-registration.
Can you tell me a little bit about both Third and 10 and Product Camp Chicago?
DAVID: Third and 10 helps clients fix their product strategy and product execution problems, ultimately helping them launch their products. A lot of our clients are companies that don’t have a product organization. In some cases, they are technology experts and don’t truly understand how product works or why product is important. They get themselves into trouble because they are not following good product practices, so we step in and help them out. In other cases, they are services companies that want to “productize” some portion of their service, but don’t know where to start.
ProductCamp Chicago is a separate but related initiative. I started it in 2008 as the Midwest’s version of the Silicon Valley original. Since then, we have hosted ten “unconferences,” each with great keynote speakers and timely, original attendee-generated-and-selected content. The idea behind the unconference is simple. The attendees of the original ProductCamp were tired of attending conferences with speakers whose presentations were thinly veiled sales pitches. If they were going to take a day out of their busy schedules, they wanted to learn about the current trends in the practice of product management, hear unique approaches to common product problems, and gain knowledge that they could apply the very next working day.
What are some of the typical product management challenges your clients face, and how do you approach helping them?
DAVID: We work with two types of companies. The first type is a company that is already in the software business. The second type is a company that is getting into software either as some type of implementation or is including software as part of the evolution of its product or service.
Companies that are already software companies risk getting buried in their processes and having their processes become their output rather than the product being their output. However, the velocity of their output and the magnificence of their processes do not matter if they are not solving customers’ problems. In these cases, I first reframe the discussion around results rather than output.
Companies that are not software companies but that are implementing software or are including software in their products for the first time typically need a lot of education on agile and why it’s important. It takes a long time to truly understand agile because it can be a painful process. Agile is unpredictable and a companies that conduct rigorous planning activities have a hard time with that.
But as I always explain, although the agile development methodology is not a great process, it’s the best we have. You don’t spend months assembling requirements and then creating a product that no one is happy with. Maybe someday something better will come along, but for now, agile is a lot better than waterfall methodology for delivering value to clients.
How do you explain the value of agile development methodology to people who are unfamiliar with it?
DAVID: I’ve found that the best way to convey the value of the agile development methodology is to walk through examples of problems I have experienced using a waterfall approach. For example, a number of years ago I was working on a large development project. The team ended up building three different versions of the software and it failed in the market three separate times.
Members of the product team were defining requirements in a vacuum. Months later, we had developers implementing these requirements in a vacuum. There was no rapid iteration, and when the customer finally saw the product a year later, they were not happy with it. While our product and development teams were hunkered down in their silos without good communication across our organization, much less with the customer, the customer’s needs had changed.
For those new to agile, I also stress the idea of quality over dates. The client must become comfortable with the dates being forecasts, not deadlines. Companies also must be comfortable with the idea that they need to provide a run rate of capital, not a lump sum budget. There is no fixed bidding in agile. Rather, the question is whether the organization is getting the value they want for what they are spending right now. The scenario cannot be “I give you X money and you give me Y product a specified number of months later.”
There is a disconnect between agile and traditional financial reporting. How do agile organizations manage this?
DAVID: I have not seen a lot of companies manage this well. I understand the need to make investors and bankers comfortable. The companies I’ve observed manage this tension most effectively make an estimate to present to their investors, but they use a run rate of capital with their employees. They try to cushion the blow as much as they can with investors when a product falls behind forecasted time frames or when they need to ask for more money. But this dynamic is a very big challenge because you can’t have quarterly delivery commitments while calling yourself agile.
How can product and technology teams best work with one another?
DAVID: Product managers need to have at least some technical acumen if they are going to be working on a tech-heavy product so they can effectively communicate with the technical team. There is a natural dissonance between technology and product teams, but I think this is a good thing.
Technology teams want to build high-quality, highly reliable systems. They often want to do things that won’t add product value or address customers’ needs but will make the system better. Product people are always pushing for new features, but an unstable product that doesn’t work well will not be accepted by the market. While building resiliency and performance into the product is great, a high-performing product that doesn’t meet the customer’s needs will not be successful. A feature-rich product that doesn’t work will also fail. So, the tension between features and product performance is a very healthy thing because it balances those two factors.
Our company, Sphere Software (https://sphereinc.com), is the sponsor and organizer of Techdebates.org and also finds great value in these follow-up discussions with industry experts. Sphere is a technology consulting and solutions company. Everything we do is designed to accelerate your business, remove technical constraints and eliminate staffing bottlenecks.
