When you read this post, I assume you are working in a team
or organization which has imbibed Agile and its various approaches into
practice. I see it is more mindset and
culture, than just saying it as a practice.
I have worked in team and projects which had Waterfall approach. I'm
working with teams and projects which claims to be Agile in approach.
Here is my tweet and the question of @J_teapot. His tweet is interesting and striking to
me. Hence, I write this
post. Thanks, @J_teapot for asking. I enjoyed that question of yours.
Days of Waterfall
It was in early 2000s (to be precise 2005-2007), I worked in
project which had customized waterfall approach. The build to testing were delivered in
iteration and not at the end. In the
course of project, it got adapted to Agile practices and as I remember it was
around 2007-2008. Yet the shipment of product
being developed happened once in 3 or 4 months.
This shipment time remained as is Waterfall and in Agile. If asked, why that slow in shipment when
Agile, it was business decision.
In my initial days of career, I read this in text books of
Software Engineering and Software Testing -- "Bugs are more costly to fix
when found later." The same was
said by managers to we programmers and testers.
Those were the days where no much blogs and posts in web on Software
Testing, Software Development and Practices.
Google, had just come in few years back, then. It was the period where Software was getting
into every spaces of business and daily life.
The pace of delivering software to various business space picked up its
pace. The technology platforms emerged
and so the practices.
Days of Startup Era
In the era of technology start-up that is around 2012 and
onwards, the shipment pace for "working" piece of software took cut
from months to a month and to a week.
Then the era of programmers led technology start-up came in. The idea of MVP (minimum viable product) and pitching
to investors for series of funds, all came into the news. If you notice, software was developed earlier
and, in this date, as well. The
difference is the time and how it shipped, was the business call in major than
being a tech call. I see this is
appropriate to remain in business, competition and for being relevant to needs
of customer and market. That change has
to come in quick pace.
In 2020, this is no different. In fact, the shipment pace has got much
quicker and it goes in a sprint of 14 days (including non-working days). You can refer to the train model of backlogs
in a sprint for more details. If did not
get deployed and rolled out for install, business will be impacted as earlier. Who answers for the investors?
The approach of software development has evolved and so the
testing also has to adapt. If had a
"working" piece of deployment and serving the customers with value
claimed, the team will be relieved; else, the trouble starts for team. I have been here and I know it. The MVP which claims to deliver the mentioned
value, has to be delivered. Whatever one
builds or adds to MVP, should continue to deliver value claimed. If there are bugs in shipment that can be
bearable, then still fine unless it blocks the value claimed.
I have been in state, where the value claimed by business
and MVP, not delivered after shipment and deployment. The are several reasons as multiple works to
ship one working software system. Fixing
that in few minutes and deploying it is expected besides the cost incurred out
of it. It so happens, the deployment and
roll out goes while the testing is in progress or not yet started for that
version of software. In a way, it is a
strategy and also a business call.
Ship it first - Mindset
In 2020, it is costliest if not shipped quickly; fixing few
bugs later is okay. That's a business
call and a strategy. We have to be there
on time with service catered. In my
opinion, unless the value claimed to offer by MVP and product as a whole, is
being delivered, all is in control despite the bugs in production. That said, I'm not ignorant of bugs in
production. I will continue my work in
finding them. I have evolved to adapt my
testing and skills to need of business, market and software system we build.
If asked what is right that is shipment once in months or
once in a sprint (2 weeks, usually), both are right. I hear few teams still ships once in 6 months
today as well. I work with teams which
ships in a week and in two weeks. Not to
mention, I have worked where the requirement comes from business and shipment
happens in few hours. It is all about,
where I'm here. That as well defines the
time available for testing. I'm not sure
what today's Software Engineering and Software Testing books say about fixing
bug later. Fixing later is not a habit
but a situation needs today when it comes to business. I wish, when a testers being technical and
understands the business side, it adds value much more to the testing, team, business,
organization, customers and to the product.
To summarize, it is business and market demand that has kept
the shipment in a sprint. Prioritizing
the blockers (and bugs -- know & unknown) for shipment is a skill which a
tech (programmers & testers) team has to groom in my opinion. I see this is adapted in service industry and
as well in the tech product organizations.
