The following story is not wholly based on any singular
experience but rather a conflation of multiple real situations in order to
create a compelling enough story to discuss. (Any resemblance to real life
people or products is largely coincidental.)
Premise
Product A has a pretty strong team who work on it. Everyone
on the team has been specifically recruited because they’re good at the
technologies it uses. They are all experienced in the tech stack and though
some of the devs would like to rewrite sections of it they are mostly bought
into it’s worth. It is the primary focus for most of the Developers, Business
Analysts and Testers in the team and they commit as much time to it as
possible. The more experienced members of the team are passionate in improving
the quality of the code in Product A, taking every opportunity to get newer
members of the team involved in their endeavor.
Product B is ostensibly owned by the same team as Product A.
None of the strong developers work on it and it is primarily coded by those
with less programming experience. It is written in a very different tech stack to
that of Product A and as such only a small portion of the team are interested
in understanding the languages and technologies used. At least one of the
developers in the team refuses to look at the code at all, arguing that the
amount of context switching required is unreasonable. It is difficult to
improve the code because the stronger developers are reluctant to get involved
in it.
The Product Owner is in constant communication with
stakeholders and works closely with Business Analysts, Developers and Testers
to shape Product A and set a strong roadmap. Changes are undertaken with as
much understanding as possible of the scope and the dependencies involved. If
bugs arrive they are prioritised to get them fixed as quickly as possible. The
Product owner is occasionally frustrated at having to spend time on refactoring
Product A but understands it is the cost of doing business.
It is difficult to get the team’s product owner interested
in Product B. He has been told that it belongs to him but he resents spending
money on something that doesn’t seem to help him achieve any of the wider organizational
goals being set for him by the management team. Product B is intrinsically
linked with Product A and almost all of the changes that come in are caused by that
of Product A. The Product Owner gets frustrated if people discuss bugs in
Product B and frequently brings up the possibility of scrapping it altogether
arguing that his team would have more time to spend on Product A without
Product B. As Product A grows, Product B becomes much bigger too and is
frequently accused of being unwieldly and difficult to run. It is rarely
discussed if Product B is actually helping to improve Product A, which should
be the intention.
Everyone understands what Product A does and why. It was
largely designed by a couple of developers who had built things of a similar
size in the past and even though one of them has now left the team people agree
that some of the foundations seem to work. Only one or two people understand
how Product B works and in fact it was largely designed by a developer who
hasn’t built a piece of software this large before. There is a similar Product
(Product X) which was written by a developer who has since left the team and so
it has been decommissioned. It performed similar functions to Product B, but no
one understand how it worked and when there were problems in it is was decided
to simply replace it. This took a great deal of time and effort and delayed the
development of Product A.
A lot of time and effort goes in to understanding how
successful Product A is proving to be and a great deal is invested in coming up
with new ways to improve it. It’s actually quite difficult to measure what
success means for Product B and occasionally some of the Developers who never
touch Product B will get frustrated with its existence and the fact that they
need to consider it when they make changes.
Conclusion
Is it any surprise that Product B is a failure? The game has
been rigged against it. I’m betting that it was obvious within the first couple
of paragraphs that Product B is an automated test suite.
I think sometimes people don’t treat their automation tests
like their other software, but if you look at it as just a different product it
all becomes almost absurd how we act towards it. It is sometimes a product
without a clear roadmap or obvious metrics. Dependant on another product, with
frequently only testers working on it who let's face it, are rarely hired for
their software development skills alone. It is rather more likely that they’re being
expected to be good at a whole host of other things at the same time.
If we accept just the premise that Product B is worthwhile
what could we do to try and solve this problem?
·
Try and get all of the team to love both
products.
·
Find out if Product B is actually providing
benefit to Product A and in fact what benefit would be worthwhile.
·
Discuss what would make Product B more tolerable
for the Developers to work on, as it’s currently only the testers who work on
it.
o
Maybe building Product B in the same languages
as Product A as possible to facilitate reduce context switching.
o
It could even be an idea to try the risky
approach of allowing Product B to incorporate shiny new technologies that get
the strong developers interested.
·
Try and identify what success means for Product
B and always optimize for success.
·
Try and get everyone in the team to understand
and agree on what Product B does and how it can improve Product A.
·
Maybe limit the scope of Product B and accept
that it can’t do everything. This may help it to be considered alongside
Product A when changes are suggested so the Product Owner grows to understand
that it is part and parcel of making changes. In time you may even get the
Product Owner to appreciate the benefits it gives him to Product A.
No comments:
Post a Comment