Delta Matrix | High Productivity And Exceptional Quality Are Just Half The Story
1694
page,page-id-1694,page-template-default,siteorigin-panels,ajax_fade,page_not_loaded,

 

High Productivity and Exceptional Quality are Just Half the Story 

 

Written by Ned Kremic 

Many organizations are embracing the agile process framework, looking for the “magic formula” for higher productivity and an exceptional quality. 

The delivery teams control both productivity and the quality. Short iterative and incremental deliveries guarantee the higher productivity, and by integrating the quality into the development process, those teams have historically achieved much better, if not the outstanding quality. 

 

Although it sounds great, this is just one part of the story. 
The other part, and probably the most important one is to achieve faster time to market (TTM) 

 

Let me explain this, as many organizations still believe that TTM is purely dependent on high-productivity. Not so, and as you will see shortly, for your own benefits it is best to treat them independently! 

 

The product owner owns the product backlog. Therefore PO will determine the list of most important user stories that she absolutely needs for the upcoming release, as those stories are the major driver for maximizing the ROI. 
Hence, the time-to-market (TTM) directly relates to those most important stories. Once they are done and the product is stabilized, it could be released to the market. 

 

However many organizations are not taking advantages of this simple framework. This is how it typically works in most organizations that are undergoing the agile transformations. 

 

Delivery Teams are Transformed to be Agile

The freedom was given to development teams to organize the agile development. In better cases, the team is composed of all necessary resources needed to deliver the feature. If everything goes well, the promise of now big buzzword agile will be “somewhat” meet. Teams will be more productive, and during the stabilization period (integration, SFT and UAT testing) there should be around 75% less defects than before for the typical size of that particular project. 
Fantastic !!! - But, is it? 

 

For Senior Product Stakeholders and Business - "The Business as Usual"

It sounds ironic that leadership would embrace the transformation to agile for development teams, but in most cases they themselves will not try to change anything. 
Still their wish list (requirements) will be bucketed in the large chunks, where everything is needed for the particular release.  
Even worse, the releases will be tied to the traditional corporate release schedules, in most cases on 3,6,9,12 months deliveries. 

So, what are we missing here? 

I will repeat once again: The paramount of agile delivery is to maximize the return on investment (ROI)

Therefore the focus with each iteration is to deliver the potentially shippable product that will maximize the ROI. 

Second, once you have ready product with all the features you need for this release, release it as soon as possible via Continuous Delivery (CD) mechanism. Do not limit your benefits being on the market early, just because there is an administrative or process burden that releases must be tied to the corporate release schedule.  
Many large enterprises such as Amazon.com, SalesForce, Google have transformed their release schedules to support the Continuous Delivery (CD), why can’t you? 

This is how product owner could improve the two most important process items that will help shorten the release time-to-market (TTM): 

 

Define the Most Important or Most Used Features That will Maximize Your ROI, and Only Focus on Them

What defines the features that must be prioritized high and delivered with the early iterations? 
Exactly those features that will maximize the ROI! But, please be realistic, not all features on your wish list are the ones that will maximize the ROI. 
If the Product Owner (PO) team do the proper marketing assessment, they would inevitably come to Pareto principle conclusion (80/20), that 80% of most commonly used features are delivered with 20% of code. Actually in software this ratio is even more compressed. Based on the study “The Most Frequently Used Features in Microsoft Office”, only five commands (paste, save, copy, undo and bold) account for 32% of all the command usage in Microsoft Word. 

I guarantee, the same will apply to your product as well. Therefore it is in your best interest to carefully examine your wish list, identify the most commonly used features, or the ones that will maximize the ROI, and then adjust and prioritize your user stories based on that. You release list will be much shorter, therefore with high-productivity and high-quality you will be able to achieve much faster TTM. 

For more information and in depth analysis, please see: 

 

The Release Schedule - Continuous Delivery vs. Release Calendar

Is it possible to produce the “potentially shippable product” at the end of each iteration, when we know that that product will not be released for the next six months?! 
If we know that the product will not be shipped until the next release, which is 6 or 9 months from now, the human mind in us will automatically adopt to the false sense of security “there is plenty of time”, and will not produce the potentially shippable product at the end of each iteration. Some smaller deficiencies or not completed features would be OK to miss, integration will be delayed and technical debt would accumulate. 
We will again be in time-crunch at the end of the release cycle! 
Therefore try to avoid at all cost delivering the agile implementation with the waterfall-cycle release schedule. You are losing the maximum benefits that agile continuous delivery could provide. 

The second part is that many organizations have long release cycles, sometimes 6 or 9 months. 
Therefore, even if your product ownership team is diligent and have prioritized the most important features for the next release, and your delivery team have managed to develop and test it, your organization might not be able to deploy it! 
That may have tremendous consequences if you are in highly-competitive market. Just administrative release schedule burden may kill your best chance to beat your competition and capture the critical share of market faster with the rapid TTM delivery. 
As I have mentioned before, many organizations that have completed their agile transformation have changed their release management process to better match the advantages offered by agile delivery. 
It is time for you to do the same. If your productivity and quality have improved, don’t stop there! 
Complete the full transformation cycle and enjoy all the benefits that Agile can bring you. 





Ned Kremic is Project Management (PMP) and Agile/Lean (CSM/CSP) Consultant based in Toronto, Ontario.

His mission is to help progressive organizations seeking high-impact results, to radically improve productivity, time-to-market and quality for software development. 

He was instrumental in building and leading the high-performance teams that were utilizing the best technology practices, combined with advanced agile software development processes and achieved outstanding results that outperformed not only the traditional projects in corporate portfolios, but rather the industry average performance results of the other agile projects.

Your best chance to succeed with transition to Agile/Lean development and management process and achieve exceptional performance results is with somebody who has successfully done it over and over again.
Explore this site, and if you are ready to go from good to great, and you think that Ned might be right for your organization to show you the way to get there, please give us a call.