2020: It Is Costliest If Not Shipped Quickly - Fixing few bugs later is okay!

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.