This is the final part of a 3 part series on the problems large software teams face when they adopt Agile. In this part we will focus on the business aspects. In part 1 we discussed Team and Culture. And in part 2 discussed the Product.
If you are interested, you can download our Free eBook where we discuss these issues and some solutions that might work for you.
(image credit: blog.luz.co)
The business model of a company is what it is. One needs to make sure 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.
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. Till not a very long time back software was actually “shipped” in nice looking cardboard boxes. Now, it’s typically downloaded from the internet. But even now IT teams are notoriously reluctant to upgrade software running inside enterprises and often run years old versions of software even when many newer 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, does your business processes and infrastructure have the ability to make it available to the right people to 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 if the user feedback is from the right representative sample. If you have exactly one user for the software you are building, then your 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 testing). Unless a business has the ability to 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 versus Stable Markets
Standard Scrum is more suitable for emergent markets. Emergent markets are markets that exists, 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 versus 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 of time.
Market driven companies start with a broad understanding of the market and the processes are designed to optimize market fit. The goal in these companies is not yet to maximize profits.
Scrum is more suitable for market driven companies. However, most companies would find themselves to be a hybrid and careful process design to support both might be needed.
Demonstration of Progress
For some business, demonstration of progress is tied to business outcome. This is mostly true in consulting, where some demonstration of progress is needed to win large contracts. Agile is a good fit in these cases.
This is one of the reasons for Scrum originating from the web consulting business.
When a product is visionary and the business is trying to create a new market, the customer voice is non-existent. While feedback to the development process is still needed, getting feedback from the market is difficult until the product reaches a certain level of maturity that make it easy to have a conversation with the prospective customers.
Some of the Agile principles in these cases needs to be adapted to suit the situation. A good example of this would be the initial days of Apple iPhone.
There could be some business cases (maybe only a handful) where the software development is done on a contractual basis. In these cases the customer might know exactly what is expected from the product and wants timely delivery. In these cases Agile might not be very suitable.
Feature, Cost, Schedule
Feature, Cost, and Schedule (along with quality) are the typical constraints of any project. Since large software development projects are inherently unpredictable, it is impossible to fix all the constraints. At least one of the constraints need to be kept floating which can keep changing as the project runs.
(image credit: Wikipedia)
Depending on the business case, optimizing for a different set of these would make sense. Standard scrum tries to optimize for cost and schedule. So in scrum (when it works well) a release is always there on time (schedule) delivered by a team (cost) at an acceptable quality, whether or not it has all the features (scope) originally thought of. Some business models will benefit from this. While some others can benefit from optimizing something else. For example deep technology products could benefit from optimizing features over quality so that a demonstration of the core features can be done to raise more funding to “productize” the technology.
In some deeply regulated markets features and quality might have to be fixed while costs or schedule or both might have to be floating. It is important to think of the business case and make a deliberate choice on which constraints to optimize in a project.
Hopefully, this blog helped you assess your company and your projects in a new light. If you have experience with Agile in large teams and want to share your experience and ideas please drop us an email at firstname.lastname@example.org.
We also do consulting with companies on project management frameworks. If you are interested in our consulting services or a half a day workshop please send us your enquiry at email@example.com.