Taking on product not adequately developed beforehand
Hi everyone,
I have followed discussions on this forum for quite some time and can only say that from your detailed answers you really learn new things and approaches to problem solving. Overall great site and great help for the community.
Right now, we have a challenge as follows and would like to get your opinion if we are on the right path and suggestions for improvements:
- we, as external consultants, as a complete team of 8 have been outsourced by one company which is trying to get more agile.
- they have been working on some complicated product 1-2 years ago, developed it but not properly as it has many problems within.
- now have their own small team solving burning issues as they arise on everyday usage of that product (doing Kanban) but no structural changes to the product itself.
- plan is that we get there and start parallel work, having been served with several issues that need work on. Issues are quite old or they are mostly performance spikes/bugs or user stories with a connotation no point doing it separately from overall configuration - whole configuration should be tackled properly.
- in a very short transition, we had a chance to discuss the product and particularly presented issues with stakeholders and some people who were previously involved with that product but are keeping distance from it by saying we do not know much about it, we inherited that as well.
- stakeholders would like something to get done but they are stuck with the product which was not adequately developed previously, so are automatically limited in their wishes.
- in short we cannot get to people who worked on development of that product previously, it has many drawbacks, and stakeholders knowing for those drawbacks, even though they may want something much more are limited in their wishes, conversation spins arround served issues, which in reality do not make much sense as it is building on something that was not adequately build before.
Our approach:
- We got together as a team, discussed it and agreed that we should not go and do back re-engineering of the product or at least not for time being.
- We should get one or two small pieces of those presented user stories, simplify them (try get out something that makes sense doing under current circumstances if anything at all - at least just investigate previous architecture) and try working on that at start just to get us going, to start investigating, to dig deeper into the structure of the product, architecture done previously etc. (start with Kanban) - have few developers good in architecture within team.
- Hopefully, developers will get information on structure, previous architecture, from which point, most likely we will observe the previous product as a prototype, we hope to start working on our own architecture and start going from there with scrum hopefully with few 'functional' requirements on board.
- Hopefully at this point, we would be able to approach stakeholders, knowing more as to what we are capable of, and source needs/ functional requirements / business goals from them and start getting to the product Goal as a guiding star for future work.
What is your opinion? Are we starting it right?
You've inherited other people's technical debt, but you don't know how much they've got, and they have no real plan for paying it back. It's therefore difficult to even describe it as technical debt; it might be better to describe it as a technical liability. Significant chunks might need to be written off, rearchitected and started again. That's the strategy you seem to be favoring now.
Perhaps an alternative is to turn the issues with the existing product into real technical debt, where the rework to be done is quantified and qualified on the Product Backlog. Before you can establish a strategy for remediating technical debt, you need transparency over how much is actually there. This would cost time and money. Would your client pay it, in order to obtain that transparency, or would they rather start again? Has that brutal conversation really been had yet?
You are absolutely right Ian, we have two options and we would have to decide which way to proceed. Even though the first option of re-architecting it and starting it again seems now as the right way forward and is a more "clean and attractive" option, the second option may also be viable.
Brutal conversation :) has not happened yet. We were thinking of getting to know the product better by starting to dig deeper into it hoping to have soon just "rough estimates" on the surface as to the amount of technical liability within the product, learn about architecture and then have that conversation with client.
Bearing in mind that the product is "complicated" in nature, we are sort of reserved as to what proportion of time to devote on investigation into technical liability but anyway I guess, we would have to investigate previous architecture to have something on the table when we sit for that conversation.
When you say it costs time and money, we cannot quantify it and break it down into costs without spending significant time on it. What is your experience with this investigative work into technical liability / where should we draw the line / what is just enough info to have adequate conversation and decide how to proceed (and avoid going wrong way)? Is there a best practice in this regard, any frame just roughly to follow or we just go based on our feelings and rough estimates when we feel comfortable to discuss it?
The first line you should draw is to have a Definition of Done for the Product, the observation of which would ensure that any future increments would be fit for release. The DoD is your bulwark against more technical debt accumulating, and it will help to give transparency over the kind of rework which is likely to prove necessary, even though specific instances of technical debt are not yet enumerated on the Product Backlog.
I worked somewhere that had a similar problem but it didn't involve outside consultants. We just had this part of our product offering that was thrown together haphazardly and put into production. The original thought was to see if anyone would use. It was purely an experiment. But no one expected that 80% of the user base would start using the experiment within weeks. It became one of the most used part of our product. It worked ok for a while then started to show problems and there were requests to integrate it with other parts of our product.
What we ended up doing was for every requested or needed change we did our due diligence. If there was rework or rearchitecture needed, it was added to the Product Backlog as stories to support an epic of delivering the requests. We realized that we were dealing with Technical Liability (as @Ian Mitchell so aptly phrased it) so we addressed it piecemeal. Even as an outside consulting firm you could do something similar. They are paying you for your expertise and expect you to deliver quality work. Craft your Definition of Done in a way that makes it clear to people you won't be patching if it will not meet your quality standards.
Thank you both for very helpful insight and direction.
Hi everyone,
It's a good thing I stumbled on this particular topic. My company has been dealing with a similar issue for a while, and all your inputs have been quite insightful. Truly, we learn everyday. Thanks once again
Hello everyone,
I'm in a similar situation: a 3rd party created a product in a year (they don't work in agile ways and there were no quality control so rumor says it barely works) and we (internal) need to take this product over (2 week timebox). We know very little about the product and we haven't seen the code yet. Approaching this w/o any strategy would be bold to say the least. I try to come up with something as the team is clueless how we should proceed. Daniel's and Ian's advices will help me out no question...but are there other practices we could use, questions to ask?