Agile Product Development [How To Approach Design & Architecture For A Product]
Almost all IT companies have moved or are moving to Agile\Lean development. Do you know that Agile was first proposed and used in manufacturing industry. Interesting right? Can we ever think of a good's manufacturing company has anything to do with Agile? What would an incremental development mean to the manufacturing world because a good to be delivered has to be delivered completely. We cannot think of a car gets delivered without interior because product owner decided so. Or a wall clock gets delivered without hour hand. Then where is the relation between Agile and manufacturing industry?
Being software industry people, we are thinking or can think of above funny cases, however for manufacturing industry, Agile is not about for e.g. a ready to ship product after every Sprint in Scrum. But Agile for them is to be able to respond quickly to customer needs and market changes while still controlling costs and quality.
How is that possible, well that's the magic. And apart from the Lean manufacturing leverage, most important element of this magic is Modular Product Design(MPD) i.e. designing products in a modular fashion that enables them to serve as platforms for fast and easy variations of products.
Let's jump back into software world of Agile. When a SW product company decides to go agile, does it really understand what they are really committing to? I have my doubts. Moving from traditional SW development to Agile\Lean development is not only limited to training your people on Agile and convince or force them to follow Agile processes. Neither it means that you can suddenly move to Agile development for all your existing SW products. It is a commitment from company management after understanding how it will get implemented and what is the investment cost. Yes moving to Agile is a costly affair if one wants to do it in true spirit. It starts with analysis of product from all angles, current market, new market, life stage of product, wish list etc. This data helps in determining what model of Agile if only possible can be used for this product.
Then the next stage is architecture and design study. Does the product meet the Agile standards for the design. Will it sustain the new feature addition and up scaling? You are very lucky if the answer is yes. But 90% of time the answer will be a big 'No'. And no one can be blamed for this because we cannot see the future. We just need to think, now what. Most of these products are either in CPE(Continuous Product Enhancement) phase or in support phase and hence are the candidates for KANBAN. However if we are talking about a relatively fresh product in market where there is lot of sale value and also expect frequent customization requests from clients, then we definitely need to invest in re-architecture of the product to convert it into a MPD. This becomes costly affair hence note that not all products a company has can be candidates to move to Agile.
We talked about moving to Agile for existing products in market. Now let's talk about building a new product with Agile vision. A relatively simple challenge. Company has analysed the market, and decided that we have to go for Agile to be there all the time for all the kind of requirements from customer. Now-a-days it is a simple decision. In almost all domains, market is becoming dynamic, customer retention is the highest challenge. Today's customers are very demanding and are not afraid of changing products just like that. They always want something new, they want somewhat more. Best example could be the smart phone SW. Forget about applications, here OS itself releases new flavors\updates every quarter. They have to do it.
Although there is a school of thought who believes that like the functional increment a design can also evolve incrementally. I have my reservations on that stand. Suppose you are delivering say 2-3 user stories in first Sprint which does not involve all sub-systems in overall system, what kind of design you think you will be putting in place? Answer is a makeshift one. In next Sprint you get exposed to few more sub-systems, so existing design needs to change. Now what? Of course you can take a stand, "That's what Agile is all about. Freedom to change anything as and when required", make sure your PO is on your side. For a PO from Sprint 1 to Sprint 2, what really matters is incremental demo. What new functionality is added? How many times do you think, following excuse will work:
An incremental design means, being able to develop a module when it is required and then just sliding it in, with minimal wastage. And this is only possible to achieve if you have architecture layers and sub-system communication figured out and full modular system design chalked out.
With this preamble, it is now a given that we are going to need a MPD. Product owner works hard on adding epics, splitting Epics into user stories and adding acceptance criteria in place. Team who is going to work on the product works on getting requirements clarified. Minimum Viable Solution(MVS) epics and user stories identified. This all generally happens in Sprint 0 of the release. If it is the first release of a SW product, most important thing is to get the MPD in place and get it right. This includes the architecture framework layers and the different sub systems of the different layers. As the term suggests, MPD should have following attributes:
When you think you are done with design, team should check it against all the above characteristics by taking some hypothetical situations. Note that, the architecture that you are putting into place is the backbone of your product and with Agile it becomes further critical to get it right first time (at least 80% close to final). Gone is the era of waterfall life cycles where you wait for a load of new feature requirements to declare a release and then an year or more to actually deliver it. You could take the liberty to change your design\architecture completely keeping UI layer transparent. Adapting to Agile, you don't get this liberty to revamp your design\architecture once the product is released to market. You will be forced to release frequently to market with few in demand customization or new features to be able to cope up with competition. Hence apart from above virtues you also need the following things\decisions in place to get you MPD right:
To churn out above information we need elaborate discussions with Product and\or Program Owner and a buy in from company management. Some of these things may appear tangential to topic but they are not, they have direct connection with your product design. With disrupting speed of technology advancement, products now-a-days have a lot shorter market life than what it used to be say 10-15 years ago. Wise companies kill their own product before a competitor does it. And they do it by introducing a replacement product good enough to lure your own customers.
So to cut a long story short,
Does Agile SW development also means Design can be developed incrementally as we progress in a release?
No, not at all. We need a comprehensive MPD in place before you start development. This may sound little anti-Agile, but it is not. Rather this design becomes the base for smooth Agile product development. Stronger the base, you can keep replacing the design blocks without fear for collapse or mishap. If design is not thought through one, leading you to often bulldoze and bore into it, you know you are asking for trouble.
Being software industry people, we are thinking or can think of above funny cases, however for manufacturing industry, Agile is not about for e.g. a ready to ship product after every Sprint in Scrum. But Agile for them is to be able to respond quickly to customer needs and market changes while still controlling costs and quality.
How is that possible, well that's the magic. And apart from the Lean manufacturing leverage, most important element of this magic is Modular Product Design(MPD) i.e. designing products in a modular fashion that enables them to serve as platforms for fast and easy variations of products.
Let's jump back into software world of Agile. When a SW product company decides to go agile, does it really understand what they are really committing to? I have my doubts. Moving from traditional SW development to Agile\Lean development is not only limited to training your people on Agile and convince or force them to follow Agile processes. Neither it means that you can suddenly move to Agile development for all your existing SW products. It is a commitment from company management after understanding how it will get implemented and what is the investment cost. Yes moving to Agile is a costly affair if one wants to do it in true spirit. It starts with analysis of product from all angles, current market, new market, life stage of product, wish list etc. This data helps in determining what model of Agile if only possible can be used for this product.
Then the next stage is architecture and design study. Does the product meet the Agile standards for the design. Will it sustain the new feature addition and up scaling? You are very lucky if the answer is yes. But 90% of time the answer will be a big 'No'. And no one can be blamed for this because we cannot see the future. We just need to think, now what. Most of these products are either in CPE(Continuous Product Enhancement) phase or in support phase and hence are the candidates for KANBAN. However if we are talking about a relatively fresh product in market where there is lot of sale value and also expect frequent customization requests from clients, then we definitely need to invest in re-architecture of the product to convert it into a MPD. This becomes costly affair hence note that not all products a company has can be candidates to move to Agile.
We talked about moving to Agile for existing products in market. Now let's talk about building a new product with Agile vision. A relatively simple challenge. Company has analysed the market, and decided that we have to go for Agile to be there all the time for all the kind of requirements from customer. Now-a-days it is a simple decision. In almost all domains, market is becoming dynamic, customer retention is the highest challenge. Today's customers are very demanding and are not afraid of changing products just like that. They always want something new, they want somewhat more. Best example could be the smart phone SW. Forget about applications, here OS itself releases new flavors\updates every quarter. They have to do it.
Although there is a school of thought who believes that like the functional increment a design can also evolve incrementally. I have my reservations on that stand. Suppose you are delivering say 2-3 user stories in first Sprint which does not involve all sub-systems in overall system, what kind of design you think you will be putting in place? Answer is a makeshift one. In next Sprint you get exposed to few more sub-systems, so existing design needs to change. Now what? Of course you can take a stand, "That's what Agile is all about. Freedom to change anything as and when required", make sure your PO is on your side. For a PO from Sprint 1 to Sprint 2, what really matters is incremental demo. What new functionality is added? How many times do you think, following excuse will work:
"Oh you know what dear PO, with the user stories from XYZ Epic we planned in this Sprint, the design needs to be completely revised. We have added few TRs (Technical Requirements) for that hence we would only be able to deliver 2 out of 4 stories as we originally planned."
An incremental design means, being able to develop a module when it is required and then just sliding it in, with minimal wastage. And this is only possible to achieve if you have architecture layers and sub-system communication figured out and full modular system design chalked out.
With this preamble, it is now a given that we are going to need a MPD. Product owner works hard on adding epics, splitting Epics into user stories and adding acceptance criteria in place. Team who is going to work on the product works on getting requirements clarified. Minimum Viable Solution(MVS) epics and user stories identified. This all generally happens in Sprint 0 of the release. If it is the first release of a SW product, most important thing is to get the MPD in place and get it right. This includes the architecture framework layers and the different sub systems of the different layers. As the term suggests, MPD should have following attributes:
- Plug-in\Plug-out modules
- Easy customization support
- Extendable\Scale-able
- Open SDK\APIs
When you think you are done with design, team should check it against all the above characteristics by taking some hypothetical situations. Note that, the architecture that you are putting into place is the backbone of your product and with Agile it becomes further critical to get it right first time (at least 80% close to final). Gone is the era of waterfall life cycles where you wait for a load of new feature requirements to declare a release and then an year or more to actually deliver it. You could take the liberty to change your design\architecture completely keeping UI layer transparent. Adapting to Agile, you don't get this liberty to revamp your design\architecture once the product is released to market. You will be forced to release frequently to market with few in demand customization or new features to be able to cope up with competition. Hence apart from above virtues you also need the following things\decisions in place to get you MPD right:
- 5+ years road map of your product in market
- Release after release what kinds of customization requests you expect
- What size of client base you desire to generate.
- When will you like to declare end of life (EOL) for the product.
To churn out above information we need elaborate discussions with Product and\or Program Owner and a buy in from company management. Some of these things may appear tangential to topic but they are not, they have direct connection with your product design. With disrupting speed of technology advancement, products now-a-days have a lot shorter market life than what it used to be say 10-15 years ago. Wise companies kill their own product before a competitor does it. And they do it by introducing a replacement product good enough to lure your own customers.
So to cut a long story short,
Does Agile SW development also means Design can be developed incrementally as we progress in a release?
No, not at all. We need a comprehensive MPD in place before you start development. This may sound little anti-Agile, but it is not. Rather this design becomes the base for smooth Agile product development. Stronger the base, you can keep replacing the design blocks without fear for collapse or mishap. If design is not thought through one, leading you to often bulldoze and bore into it, you know you are asking for trouble.
Comments
Post a Comment