ITMPI FLAT 003
Main Menu
Home / Authors / Blogging Alliance / Agile Is an Ingredient, Not a Recipe

Agile Is an Ingredient, Not a Recipe

BloggingAllianceButton

Picture a scrum team: seven developers, plus or minus two, rigorously following the ceremonies in the Scrum Guide. They maintain a product backlog prioritized by business value, with estimates of effort created by the team. They generate a burndown chart for each sprint, and they know their velocity. They limit the daily scrum to 15 minutes, conduct a retrospective at the end of each sprint, and have a checklist for their definition of done. They have automated regression and performance testing and they build daily. And finally, after more than a dozen sprints, a business decision has been made to actually ship the potentially shippable product.

Getting to Market Requires More than Agility

Unless you are developing a new webpage for the corporate intranet, you have competition. You have to out-perform those other folks in the places the customer sees, not just in daily scrums and retrospectives. You must make it possible for a customer to see, understand, and develop an interest in your product. You must make it possible for them to enter into a business relationship with you. You must make the benefits your product will deliver both visible and accessible. And remember: value is in the perception of the person making the purchase decision.

Is It a Product If No One Buys It?

Despite the old saying, better mousetraps don’t sell themselves. They don’t deliver themselves, support themselves, or automatically replace whatever the customer previously used. Thus, a marketing department tries to identify potential customers and ways to reach them, while a sales team reaches out to establish relationships with decision-makers. Sales support folks prepare demos and FAQs. Someone prepares technical material that supports the customer’s decision to adopt the product, while someone else may gear up to assist the customer with implementation. If the product has a feature set robust enough to require training, then someone has to prepare that content and various job aids. Some attorney must prepare a license and contract for service and support that will be acceptable to customers.

Each of these things must be ready at the same time the decision to ship is made. And each of these specialists who aren’t product developers has their own methodologies and timelines, and they don’t necessarily align to the scrum team’s sprints. They need to develop their own plans. Every change to the delivery date adds cost to their efforts. Every change in what will be delivered causes rework. Someone needs to keep them informed and manage their expectations. And based on the Scrum Guide, that won’t be the scrum master or the product owner—it needs to be someone focused on getting to market, like a project manager.

Does It Matter Who Buys the Product?

If the goal is to sell to the global market, translations will be required. If the software collects information that some government deems sensitive, then controls must be demonstrable. If the product is software as a service (SaaS), then provisions must be made for access controls and security assessments, as well as continuity of operations and failover. And once you have actual paying customers, you will have to manage their expectations about updates, from coming feature enhancements to the level of effort required to take them up.

Product support takes the product from initial sales to widespread adoption. It requires both strategic vision and tactical excellence, and it is about establishing a “business as usual” rhythm for the product. This is why operations management is so important to software firms—someone has to scale product support at exactly the pace required to both support existing customers and absorb new ones.

Agility Requires a Stable Foundation

Just as gymnasts need their balance beams, parallel bars, and pommel horses anchored to a solid floor, so does an agile product development team require a comprehensive set of services in order to bring their product to market and keep it viable. Agile methods may work in some areas but not in others, and that’s OK. What matters is the ability of the organization to bring each of these disparate skills and activities together at the point in time when the market is ready. And that takes a management team that can drive not just collaboration, but commitment to a common cause.

 

For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager

Are you involved in a data conversion project? Then check out Dave’s indispensable book: The Data Conversion Cycle

About Dave Gordon

Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management. You can view his blog at The Practicing IT Project Manager by clicking the button below.

Check Also

What Problem Does ITIL Solve?

IT needs speed, speed, speed. ITIL is associated with structure, structure, structure. But to think …

Leave a Reply

Your email address will not be published. Required fields are marked *