This is part 2 of a 3 part series on the problems large software teams face when they adopt Agile. In this part we will focus on the Product aspects. In part 1 we discussed Team and Culture. And in part 3 we will analyze the business aspects.
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: http://www.successfulworkplace.org/)
The process one uses to build products should definitely depend on the type of the product. While there are benefits of following some standard methodology, it is important to realize that when it comes to the details of product development process one shoe does not fit all. In this section we will discuss what are the characteristic of the product that makes it more or less suitable for agile methodologies.
When discussing “Team and Culture”, we said either adapt your “Team and Culture” to suit Agile or adapt Agile to suit your “Team and Culture”. However, it is clear that your Product is what it is. So, in this section think of each of the characteristic of your product and decide if Agile is suitable for it. If not, think of tweaking Agile to suit your Product.
“User Story”: bite-sized featurettes
A “user story” is a complete feature that can be delivered to the customer (the user) when completed. Before we delve into why this is a problem let’s look into how large software products gets architected for robustness, reusability and maintainability. A typical large software product may be represented by the diagram below. In most complex products a large portion of these software components are developed in-house.
Now, when we are starting and just have some architecture in mind and no software is developed yet, if we have to write a “user story” that is usable by the “user” it might need fairly large amount of software to be developed, tested and delivered in each of the layers. Often it may turn out that the very first “user story” needs a particular lower layer software to be fully developed. In most cases these “user stories” are so large that they cannot fit in a sprint and might need way too many engineers to fit in a scrum team. This is one of the first mental hurdle to cross when a team tries to adopt Agile.
Often in large software products, projects at latter stages of the product life cycle are about some smaller improvements or feature additions. In these projects, the existing stable software can be thought of as off-the-shelf software and “user stories” can be small and achievable in a single sprint time frame.
Here let’s examine one case where Agile works out pretty well.
Picture a case where a lot of the layers and software pieces are off-the-shelf. In such a case it might turn out that for each new “user story” the net new software to be developed is limited such that a typical scrum team can develop, test and deliver within a typical sprint.
It turns out that website development, especially the web1.0 kind, generally falls in this category. In the diagram above the Blue boxes (images, CSS, HTML, JS, Application) are where the new software development happens. The green boxes are all off-the-shelf software. So while the full end-to-end software is of very high complexity, the net new software developed lends itself very well to the Agile methodologies.
It’s no coincidence that this type of software projects saw highest adoption of scrum. Scrum actually originated from web consulting companies that built websites for their clients. The role “customer” in original Scrum was not really a “user” of the product; the “customer” here was the client who owned the website and commissioned the work.
Top down vs Bottom up
Should software development activity be driven by top-down approach or bottom-up approach? In top-down approach one starts from a large system and progressively break it down to a number of smaller systems. Alternatively, in bottom-up approach one assembles many smaller systems to build a more complex large system.
The answer is not simple, like most things it depends.
Top down approach works better for large software projects where a lot of the components are custom software. In these cases full understanding of the system and clear specifications of the interactions between the modules are important.
Bottom up approach is favored for software projects with a lot of off-the-shelf components.
While Agile encourages a bottom up approach, in practice a hybrid approach is what works best for most projects.
It is important to think about the product you are building and decide: which aspects are more suitable for bottom up development and which aspects are best done in a top down way.
Functionality vs. Technology
Different products differ in the ratio of complexity of functionality versus the complexity of technology. Product Owners manage the complexity of functionality whereas Development Team manages the complexity of the technology. Scrum is pretty prescriptive about the team composition. When thinking of adopting Scrum, it is important to assess the functionality vs. technology complexity of your product and make the necessary adjustment to the team composition.
Product or Technology
A very large component of some products can be deep technology. Some companies just build the deep technology that other companies use in their products. For some of these deep technology driven products the success is not driven by user inputs. These products are driven by improvements in research and one can define internal metrics to measure the quality of the product. Take the example of speech to text. These research driven projects would find it difficult to map standard Agile into their processes.
While thinking of the extremes in this product versus technology scales is easier, most of the projects are somewhere in the middle of this scale. A careful articulation of where the product is in this scale will help in picking the right process.
First time or repeat show
Agile assumes the project is new and a very similar project was never done by this team earlier. However, some IT projects carried out by IT outsourcing firms could be almost exactly the same project that this team delivered for a different customer earlier. In these cases some of the basic premise of Agile may not hold true.
An extreme case of this could be where a team only does these repeatable similar projects. These teams might find it more efficient to do upfront planning and execution.
A lot of projects will be hybrid where while it’s new, there are some aspects of the project that was done by this team earlier. Agile can still be a good process in these cases. However, it would be good to identify unknown and the new and treat them differently from the known and well understood.
Frequency of Scrum Meetings
In Scrum there is a daily standup meeting where the team discusses the previous day’s accomplishment, the next day’s plan and any blocked items. One can (and should) question why is it once everyday? Why not twice everyday or every other day? Clearly, it should not be too infrequent or too frequent. However, why does it have to be the same frequency that is right for all teams and all projects? I believe there should be positive correlation between the right frequency of scrum meetings and the average task hours in your project. Once a day probably should be the most frequent one can do this and not make the overhead dominate the benefits. But it could be once every other day if the task hours are typically large.
Having said the above, scrum meetings also bring out impediments and blocked items. If a team is using less frequent scrum meetings, it must ensure there are other mechanisms through which impediments and blocked items are brought up as and when they appear.
Duration of a Sprint
Scrum is not prescriptive about duration of sprint. Anything smaller than 1 week would be too small where the overhead will start dominating. One should always think in terms of number of weeks. Here too, there should be correlation between how large the average stories are and the right duration of the sprints.
Some products are for a highly regulated market where compliance is of utmost importance for success. For such products upfront planning, strong detailed specifications, and a full compliance validation phase in the end are strictly necessary. These type of products find it difficult to adopt Agile.
In the next blog in this series we will discuss the business and how that should influence the choice of process.
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.