Problems large teams face with Agile: Business

Photo credit: Unsplash.

The business model of a company is what it is. One needs to make sure that the process it adopts supports its business needs well.

In this section, we will examine some characteristics of the business model and how they should influence the choice of the process.

(This is part three of the series. You can read the first part here and the second part here.)

Software is often delivered like hardware

System software is NOT released frequently. The delivery model for system software or enterprise software is very similar to hardware. Until not a very long time ago, software was actually “shipped” in nice cardboard boxes. Now, it’s typically downloaded from the internet.

Remember this? Photo credit: Chris Griego.

But even now, IT teams are notoriously reluctant to upgrade software running inside enterprises and often run old versions of software even when many new versions are available. So, releasing each “user story” to the customer or releasing at the end of each sprint is not even a requirement for these enterprise or system software products.

Cost of (and ability to get) meaningful feedback

Even if you adopted Scrum and started releasing stable software at the end of each sprint, do your business processes and infrastructure have the ability to make it available to the right people and get meaningful feedback? For many business models, the answer will be no. So in these cases, it is important to set the right expectations from Scrum. While it may be still a good idea to consider Scrum for some other benefits, it is important to not falsely assume feedback would come only if we built and released the software.

Another important thing to consider is whether the user feedback is from the right representative sample. If you have exactly one user for the software you are building, then you are not building a product, you are providing a service. In this case, accepting this single user’s feedback is fine. But if you are building a product for a large market, make sure to get statistically significant feedback.

Cloud-based applications like Google Search or Facebook have built in massive infrastructure to invite user feedback and measure them (often without the user knowing that they participated in these massive-scale A/B tests). Unless a business can do this cheaply, it might not be worthwhile doing this too frequently.

For many infrastructure or enterprise products, a demo might not be the right tool to solicit feedback. It might be enough to just have a clear description of the product and the benefits and use this to get the feedback needed. Sprints and Scrum could be a good technique to use on the product management side in these cases, where, in each sprint, increasingly better product documentation is created for discussions with prospective customers.

Emergent vs stable markets

Standard Scrum is more suitable for emergent markets. Emergent markets are markets that exist but are still emerging, and hence are suitable for the do-measure-adapt style of software development. Contrast this with stable markets, where a basic set of needs are expected to be delivered and scope of experiments may be limited.

Sales-driven vs market-driven

Sales-driven companies start with a quite clear understanding of the market and customer needs and all the processes are designed to help the sales team maximize profits in the shortest period.

Demonstration of progress

Market creation

Contractual obligation

Feature, cost, and schedule