Custom Blogger JS

Friday, April 1, 2016

Why Developers are More Productive When They're NOT Programming.

Executive Summary:
Having your development team involved in strategy sessions, requirements gathering activities, and operations shadowing, will greatly reduce defects, reduce total project costs, and improve your overall delivery times.

Image Source:

When I started out in technology, I worked for one of the Big 4 systems consulting firms (previously the Big 8 at that time :).  Our projects were generally made up of 40 – 50 team members with about 2/3rds of the team involved in actual development activities. These projects lasted a long time and demanded a lot of hours.  Sitting behind our terminals in rows of office cubes, one of the running jokes we had was that it felt like being on a Viking ship with everyone rowing as hard as we could, while the task-master, our project manager, cracked his whip and bellowed, “Keep coding! Keep coding! Keep coding!”.

Can you picture it? We did, all the time. I honestly don’t recall hitting many of our deadlines or getting much of our work into production, but I do recall spending a lot of time dealing with endless bugs, the majority of which were not related to broken code, but rather code not meeting the actual requirements.

One of the biggest takeaways I had during this period, was how management assumed that the more time we spent coding and testing (QA), the faster we would reach our goals.  Yes, we billed our clients by the hour, but I don't think that was completely management's  motivation here.  As opposed to generating tons of hours on something that never seemed to get done, our direct management would have much more prefered we completed our work, and on time, so that our clients would be happier and provide even bigger and better things for us to work on.  We all wanted the same.

Having run the gamut of SDLC roles as a developer, an analyst, and project manager, I gained a greater and greater appreciation for agile processes and techniques, but also realized that as vital as handing off stories to the development team for coding and testing were, there were several activities that developers could do to be even more productive and improve the success rate of our projects; and none of these involved doing the actual coding and testing.

Here are a some of the lessons I learned:

1) Have developers attend business strategy and requirements sessions
With advent of lean and agile development techniques, it seems like we are doing this already. For example, in SCRUM, we include members from both the technology and business/product teams in sprint planning and release planning sessions.

While I agree with this approach wholeheartedly, a big issue that often crops up here, is that by the time we reach this stage, and by design, developers get a very narrower view of the requirements, often insulating them from big picture objectives. When developers lack the big picture, it often leads to potential misunderstandings resulting in product defects that aren't caught until QA steps in.

One way of mitigating this, is to involve developers in the strategy and requirement sessions. In the same way that some business team members attend sprint planning sessions, and are generally asked to just observe, why not allow and encourage your development team members to follow the same protocol in business strategy and requirements gathering meetings and sessions?

By including your development team members in requirements gathering meetings, strategic planning sessions, and meeting with business subject matter experts, developers will gain a better understanding and broader context of the project and the organization's business objectives. I'm not suggesting your entire development team run around and attend every strategy and requirements session, but where feasible, encourage them to attend a broad spectrum of these and try to have at least one development representative.

Your development team's exposure to these meetings also provides the opportunity for minimizing future technical-debt. A broader understanding of requirements scope can result in catching design decisions earlier that would have resulted in solutions architectural impacts further down the road. Developers with more insight into the overall process and objectives also gives them greater ownership of the solution and the ability to suggest more effective and far reaching solutions than may have been thought of before.

2) Observe the Actual Business
Your development team should also have the opportunity to visit and/or observe the area of the business that the project is serving.  One of the clients I worked with had service representatives run delivery routes to load and unload their product from city wide distributed kiosks.  Having rode along with one of the reps during a very frigid winter day in Chicago, I noticed that there were several tasks that required them to remove their gloves, not only slowing down the process, but making it very uncomfortable for the rep.  Since that ride-along, every time I attended process and interface design sessions, I couldn’t help but think how cold it could get, and how important it was to make any new process, user interfaces, and new hardware reconfiguration, as fast and easy to interact with, and be able to perform as many of these tasks as possible while wearing gloves! Doing so would make the reps happier, more efficient, and benefit the business to boot. A win-win.

3) Business Analyst Pairing
Analysts do the best they can to capture and write complete and accurate sets of stories and user acceptance tests. But analysts are human too, at least most of them. Requirements get missed, are sometimes written unclear and/or inaccurate.  By pairing one or more developers with a business analyst during the initial requirements gathering activities, developers can get clarifications on business processes even before any release or sprint planning sessions, provide a safety check on what's actually captured, and have someone to reach out to whenever they have questions.  This also enables your development team to more readily question and challenge requirements during sprint planning, potentially catching incorrect or nebulous requirements before they get into the code.

In Steve McConnell's Code Complete, he found that reworking defective requirements consumes 40-50% of the total cost of a [software development] project. And that.. the earlier a defect remains undetected in the development process, the more expensive it become to correct [Figure 1] .

Figure 1 - Code Complete: Cost of Defects Introduced Vs. When Fixed

Even more striking, McConnell found that 60% of all defects exist by design time.

In other words, at the time the requirements are being translated into a design, there are already significant defects. Meaning, the requirements themselves are inaccurate and/or the translation of these requirements is inaccurate.

It seems obvious, but as a developer, being involved in the requirements capture process and having a better understanding of your requirements by design-time, rather than waiting for QA to validate them, will greatly reduce your project's duration and overall cost.

Studies from McConnell book also found that every hour you spend on defect prevention will reduce your repair time from three to ten hours. That's a pretty big savings!

While we tend to think of software projects as a lot of people sitting around and coding, if we are truly agile, we want to ensure we place as much value on defect prevention activities as we do on the actual product creation activities.

But what can be done if your development team is NOT or will not be involved in the business requirements gathering processes?

Three additional impactful methods for defect detection are design reviews, code reviews, and mockup/prototyping sessions.

Design Reviews  are early stage team presentations/reviews of how the solution will be designed to meet the business requirements and comply with established project design standards. 
Code Reviews are on-going informal reviews via pair programming and/or formal code reviews to ensure the code meets the business requirements and complies with the project development standards.
Mockup/Prototyping SessionsA method for technical and business teams to review product requirements together via the use of low to medium fidelity mockups/prototypes.

According to McConnell, formal design reviews, code reviews, and prototyping, can each detect between 35 – 80% of defects (Figure 2).  But even more effective, by combining all three of these methods together, defect detection dramatically increase to a rate beyond 90%!

Figure 2 - Code Complete: Defect Detection % by Detection Technique
Values are High to Low Range & Average.

Even with great processes in place like SCRUM, if we continue to rely on QA to iron out all of our issues on the back-end, we will end up sailing into some very stormy weather.  Including developers in strategy meetings, involving them in operations, pairing them with analysts during requirements gathering sessions, and incorporating design and code reviews, are relatively easy ways to minimize the defects before they get to QA.   Although a little more time consuming, implementing prototyping sessions is another great way to bring both the business and tecnical teams together to clarify requirements and reduce defects.  And by combining multiple approaches, overall projects costs and delivery time can be reduced significantly.

I recognize how hard it is to change the mindset, structure, and processes of an organization, but if we truly want to be agile, we need to be open about the range of activities team members are involved in and can be involved in.  Don't be afraid to experiment, this is the purpose of retrospectives, just be sure to try things incrementally.  Not everything  you try is going to be a success, but those that are successful will propel you further and farther to a better place.

So, the next time you feel like you are stuck in vicious circle of coding and testing the same functionality over and over again, just think of that Viking ship I sailed on.

“Keep coding! Keep coding! Keep coding!”.

What methods do you use to eliminate defects and improve your agility? It would be great to hear from you.


  1. Some observations showed that there are a lot of methods to determine your ideal productive hours of day! It is well-demonstrated in the article recently published at! May you have a happy reading!

    1. Hey Paul, thank you for your feedback and the great article link. Based on the time of your post, I'd guess you are a night owl, just like me! Much appreciated.