Tuesday, December 2, 2014

Which areas shall you focus to improve ROI in software development?

“There is nothing quite so useless as doing with great efficiency, something that should not be done at all.” -- Peter F Drucker 

The visioneers claim software is eating the world; but what is the software, is it just a piece of coding, and what's the purpose behind it? 

Every software development project has a business purpose. It is to implement the business initiative, market needs, speedy time to market strategies, increased business value through improved stakeholder collaboration, you need to build the right thing and build it right – though the context can vary with the balance. For example, when you're innovating, you don't even know if you're building the "right" thing, so the smart thing to do is to experiment quickly and cheaply: to frame hypotheses, test them out swiftly, learn and adapt.  When an experiment fails you get to write off the technical complication; but when one works out, please remember to pay it off!

So the good first step is to ensure you know what is valuable and design your process to deliver that value. Many Agile practitioners are unequipped to figure out what the value or the right thing is. In most Agile shops that chore is kicked to the side under the heading "stakeholder collaboration," An admission that we abdicate product design and positioning strategy to stakeholders. Stakeholders are supposed to tell us what to build and then we are supposed to force them to prioritize. When it goes off the rails we always do the same thing - we blame a lack of "stakeholder buy-in" for the failure. But the right attitude for a software development team is to understand the business more and see the project from the customer perspective as well. Agile teams pretend that stakeholders have answers and that "collaboration" is the solution. Agile puts so much emphasis on the process surrounding how story cards get posted to a wall, how people work those stories, and etc. Unfortunately, as a community, you do not put enough effort into shaping what story the product itself tells through the sum of all those little cards. Agile products tend to be thought about and prioritized one story at a time, and it shows. 

Then, you can cherry-pick the inefficient areas such as testing. Until you know what is valuable, you don't know enough to say what else is value-adding and what waste is. The number one thing that you can focus on is testing and test automation. As much as 50% of the development and 70% of the maintenance efforts involve testing, those who fail to capture a test baseline and automate regressions that are used to revalidate software once changes are made to it expend extra time and effort that they can avoid. Things that you could do to put this recommendation into action include: 
(1). Embrace agile test-first concepts to define your tests and the test cases and data needed to exercise them 
(2). Develop a regression test baseline containing a set of tests developed per user scenarios to shake-down the software and verify its functionality and performance 
(3). Conduct a test readiness review before qualification testing and then place your regression test baseline under change control 
(4). Automate the generation of these tests so that they can be instantiated and replayed at the touch of a button 
(5). Keep the baseline current 
(6). Maintain a test history and use it to optimize your tests 

The Agile community shall adapt to a modern product-centered mindset. Agile has done an excellent job relieving constipation that was common in software development 10-15 years ago. Agile has not done a so well job at adapting itself to a modern product-centered (not project-centered) mindset. The Agile community must begin embracing product-centered work, and not just by letting a UX team in the door. You need to start doing your own ethnography, you need to know what to do with ethnography when you have it, you need to understand how to shape a product to maximize appeal, you need to be proactive in pushing stakeholders toward concepts audiences will like. 

The software design team must transform from being Agilists into being "product people" as well if you want to deliver better business value. And from doing Agile to being agile, that is the agile mantra which helps focus on continuous improvement to increase business value and customer satisfaction.


Post a Comment