Agile Team - Agile Doctor

9 June, 201627 June, 2016

The Five Attributes of a Good Scrum Team

One of the best experiences I can have as an Agile Coach is presenting Agile and Scrum to people with little or no experience. It grounds me and after many years of living Agile, keeps me from falling into the Curse of Knowledge cognitive bias. Between these presentations and my daily coaching practice, I am reminded yet again at the importance of forming a good scrum team. This, along with proper backlog compilation and maintenance, can make the difference between success and endless frustration. In my experience, proper scrum team formation is the area where companies who are unsuccessful in Agile transformations fail most often.

Over the years, with the help of my teams and the many knowledgeable colleagues that I have worked with, I have distilled everything I have learned and come up with five attributes of a good scrum team. I use it much like a mantra. Those attributes are: Small, Co-Located, Dedicated, Stable and Cross-Functional. That is not to say that a good scrum team will not have other elements or that you can’t witness improvement without all five, but like the sculptor who is only done when there is nothing left to take away, these five represent an ideal essence of a good team. None of these five things can be removed without real consequences to the success of the team.

Small

I write about size at length (and mention the five attributes) in a previous post, When it Comes to Software Development – Size Matters, so I encourage you to read it for some eye-opening account of a major study that confirms this fact. Suffice it to say that Software Development is about communication and collaboration. It is complex knowledge work. In a physical, manufacturing model, adding a person to the effort would result in the expected proportional increase in productivity. In software development, however, adding an additional person merely exponentially increases the number of communication channels whereby any expected increase in productivity is quickly overtaken by the number of communication channels created. There is a reason Agilists recommend small teams. Basically, you can save money because your cost per unit of productive (and quality) work decreases.

Co-Located

Co-Location seems to be an issue with all of the companies that I consult for. We know that the best software developers can be 10 times or more productive than the least. We know that face-to-face communication is multiple times better than any of the substitutes we employ when that mode is not available. We all laugh at the You Tube video “A Conference Call in Real Life”. We know that the unacknowledged creation of technical debt will cause us financial havoc for years to come. Not convinced, I encourage you to check out my blog on the High Cost of Low Cost Software Development. And yet we still continue to source our software development to low bidders around the globe. Here’s the really interesting thing. For many years I have asked a simple question – does it work? I get two answers. The majority shake their head, laugh, and provide a solid “No”. The optimists of the group say that “We have found a way to make it work.” I also see a great deal of blogs that are titled “How We Found a Way to Make Offshore Work”, but it takes little research skills to uncover the author as someone employed by a company that works offshore. Never is there an enthusiastic “Yes.” Most would bring the work back if they could, but it appears that there is a mysterious formation in many software development organizations that continues to think they are doing the right thing by piece-mealing work to various locations. I can only guess it is accounting, but I have yet to meet anyone whom I respect who actually understands software development who would recommend it.

Dedicated

I often rail against the project-centric focus of many software development organizations. For more information, I encourage you to check out my blog “Why Project Focused Mentality is Killing Software Development”. The problem is that in projects we build teams around projects so that one, especially a key employee, will be spread over multiple concurrent projects. There are a number of very serious negative effects to doing this. First, context shifting means that every time a developer must change their concentrated area of focus they will lose 15 minutes minimum. If I am working on two different projects concurrently, there is not a huge loss, assuming that I might work on one in the morning and one after lunch, but many developers are bounced from thing to thing like so many pinballs with context shifting throughout the day. Hours each day are wasted and no project gets the attention it deserves. A better way is to create a small, co-located scrum team around a product backlog and bring the work of these multiple projects to the team via their backlog. The ability for individuals on the team to not fall prey to context shifting will allow them to focus on their work, even at times leading to a state called Flow in which developers (and athletes, artists, etc) are at their peak performance. For those interested, I refer you to the work of Mihaly Csikszentmihalyi.

Stable

Project-centric thinking also results in teams that are short-lived. We put the team together for a particular period (sometimes relatively short) of time. When the project is done, the team is disbanded. This causes a number of issues. First, every team goes through a period of “storming, norming, and performing.” This is easy to see visually when you plot the velocities of multiple teams on a timeline. You can visually see the storming period as teams learn to work together as a team instead of a collection of individuals, through very low (if non-existent) velocity. In my experience, I have come to the conclusion that I expect nearly nothing from a brand new team for the first couple of iterations. It is not until they reach iterations 3, 4 or even 5 that they will reach what is their performing velocity. Therefore, every time I break up a team, I have a very high overhead associated with the team’s “storming and norming.” Another benefit of keeping the same people on teams for a longer period of time is by simply learning how to better communicate with each other over time. Since software development is about communication and collaboration, the more time we spend together, the more effective we become in communicating. I remember reading about the notion of “hyper-productive” teams from Scott Downey and Jeff Sutherland. The interesting thing is that their “hyper-performance” did not manifest until after the team had been together for some time.

Cross Functional

In some respects, cross functionality of people is a by-product of the fact that team size should be kept small. If there are 15 things I need to do to get my code into production, I obviously will not be able to do so if there needs to be an expert for each piece. The creation of “silos” is great if your goal is to create a MDD (mortgage driven development) environment. It is bad for the flow of the product. Silos create queues. Queues, if you want to deliver something quicker, are bad. I highly recommend the book Principles of Product Development Flow by Don Reinersten for a deeper understanding of queuing theory and the damage that out-of-control queues can have. This book talks about the concept of generalizing specialists. In my experience, developers are more motivated by status and mastery of new technology and ideas than any other group of people I have worked with. Creating an environment where developers are expected to know more than a single specialized domain is not only good for moving the software through the system quicker, but it also leads to greater developer engagement. A team should be responsible for all aspects of the software product and the development cycle. This cannot be accomplished without having team members who are cross functional.

Final Thoughts

An old African proverb states, “If you want to go fast, go alone. If you want to go far, go together.” In order to be successful in software development we need to understand teams and team dynamics. My many years of experience working with what I would estimate around a hundred development teams has led me to conclude that there are five basic attributes for an optimal development team – small, co-located, dedicated, stable and cross functional. I hope that these five attributes help you as you continue your quest for agility.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

18 January, 201618 January, 2016

You Have a Friend – Another Reason Scrum Works?

Scrum teams, when properly assembled and maintained, have been shown to increase developer productivity and satisfaction. Scrum teams that work are small, co-located, dedicated, stable and cross-functional. These elements are essential in working in the complex world of software development. Recently, I stumbled across another reason that may explain the gains found on proper scrum teams – friendships.

In his book, The Best Place to Work: The Art and Science of Creating an Extraordinary Workplace, Ron Friedman explains that there is a strong correlation between employee engagement and whether an employee has a best friend at work. It is important to note that employee engagement and employee happiness is directly tied to employee productivity. Additionally, engaged employees also exhibit increased focus, passion, loyalty, spend less time off the job being sick, suffer fewer job-related injuries and have less turnover. In other words, there is an excellent business case to be made for keeping employees engaged through facilitating friendships.

Of course, this begs the question of how companies can facilitate friendships. According to Friedman, there are three basic things that are necessary to foster friendships; physical proximity, familiarity and similarity. It is interesting that these are things that a properly assembled and maintained scrum team will nurture. Physical proximity is analogous to co-location. We find it difficult to bond with people who we are not physically close to. Familiarity can be gained with small teams that are kept together over time. Similarity is found in keeping the people dedicated to the effort over time. In fact, studies have shown that it takes about a year of occasionally working together to transition from acquaintance to friend, so I would recommend that it takes about four to six months of scrum team experience to achieve this friendship level.

There are two additional levels of friendship that have been studied, namely, the transition from friend to close friend and from close friend to best friend. According to Friedman, the cement that bonds friends even closer together is “a foundation of shared risk” and the ability to “reveal our vulnerabilities.”

And how is this related to Scrum? I think there are two things that could allow Scrum to facilitate these deeper bonds of friendship. The first is the retrospective. When this ceremony is done correctly, it challenges people to honestly confront issues that the team is having and the sessions can be intense, but the experience of frankly sharing can certainly increase the bonds between team members. The second thing I think could play an important role is the last aspect of a good scrum team, cross-functionality. While this may seem a stretch, my own experience with teams is that when individuals are encouraged to work in areas outside their primary focus, they increase their feeling of vulnerability. It also forges greater bonds because a person has more opportunities to support their friends and contribute to the team.

Scrum is a difficult challenge at many companies because they continue to have trouble creating scrum teams with characteristics shown to work optimally. These five characteristics are size (small), co-location, dedication, stability and cross-functionality. These are the things that are essential in combating complexity, but it appears they are also necessary to building lasting and close friendships. Perhaps one of the reasons that properly assembled scrum teams are so successful is that when you keep them together, close friendships are established and this has been shown to increase productivity and reduce turnover. I think that this needs to be taken into account when we assess our all too prevalent reliance on temporary workers and temporary project teams. Perhaps temporary teams do not function as well because we have not given people the time (and space) necessary to form friendships.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

11 January, 201612 January, 2016

Project Manager/Scrum Master: A Cry for Agile Help

Over my time as an Agile Coach I cannot even begin to count the number of times I have been approached by recruiters for a position as a Project Manager/Scrum Master. My coaching colleagues and myself often joke about this particular job title saying, “we like the title Project Manager/Scrum Master because it helps us know which jobs and companies to avoid.” Why would we avoid such positions? For better or worse, by using the title Project Manager/Scrum Master we are able to quickly infer a great deal about the company and their experience with Agile – most of it not positive.

The first thing we notice about a company using this title is that they usually have little or no understanding of Agile and Scrum. The duties of a Project Manager and Scrum Master are quite different. Not only do the two roles perform different functions, but they represent a fundamental different in the way they view the world. Project managers in Waterfall try to control projects. Scrum Masters work with Agile Scrum teams to facilitate. In Waterfall, Project Managers have responsibility. Scrum Masters, on the other hand, do not have direct responsibility as the responsibility for success shifts to the development team and Product Owner. Since the Product Owner decides the sequence of the work, a Product Owner is the closest thing to a Project Manager in Scrum. A simple Google search of “project manager versus scrum master” can provide more information on this for those who are curious.

This particular problem manifests when a company desires the potential benefits of Scrum without really understanding Scrum. Without a good understanding, people attempt to map their existing roles with those of Scrum. Let me make one thing perfectly clear. The role of Scrum Master is unique to Scrum and any attempt to map it to existing roles will only result in confusion, frustration and less than optimal outcomes. As coaches, if given the choice of coaching a complete novice as scrum master or “retrofitting” a project manager as a scrum master, we chose the former. It is not that project managers cannot become good scrum masters because many have, but in order to properly train one as a scrum master there is a great deal of work in “unlearning” much of what has been previously trained. With novices the time spent “unlearning” is non-existent.

This is why I believe that companies recruiting for Project Managers/Scrum Masters are actually making a very public plea for help. If a company truly wants the benefits of Agile, it is essential that they actually take the time to truly understand that becoming Agile through the use of the Scrum framework is a serious commitment. People must gain a better understanding of software development and how knowledge workers differ, change their fundamental thinking around projects and products, pursue organizational change and realign people around properly configured scrum teams, work with recruiters who understand the difference between project managers and scrum masters and work as partners to recommend better solutions to underlying organizational needs.

For those seeking Project Managers/Scrum Masters, I hear your cries for help. As an Agile Practice Director I would love to help you to better understand your real Agile needs, to help you reorganize your work and people to take advantage of Scrum (other Agile frameworks, methodologies and development techniques), to optimize your organization so that you can deliver high quality software in a shorter time. I am available anytime to provide the help you need. If not me, please reach out to another Agile professional so we can rid the world of Project Manager/Scrum Master for good.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

14 December, 201516 December, 2015

Do Coding Interviews Work?

I have recently come across some interesting information regarding coding interviews. If you are not familiar with coding interviews, these are interviews for technical people, usually software developers, to prove that they have the ability to code so they are sometimes referred to as programming interviews. These can be either taken as a computer-based test or frequently done as whiteboard exercises. They often take the form of brain teasing riddles or binary search questions. The premise is that these coding interviews, conducted in an arbitrary environment, are a good proxy for determining whether or not someone will perform well in the real world.

As with all things, instead of relying on our human instinct, which is riddled with cognitive biases, we must rely on science to understand true cause and effect. The science has spoken loud and clear; there is no relationship between coding interviews and performance on the job for software developers. Don’t believe me; here’s what Laszlo Bock, Senior Vice President of People Operations at Google had to say on the topic:

…everyone thinks they’re really good at it. The reality is that very few people are.

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess…

It appears to me that very often the interviewer is much more concerned with showing the candidate how astute he or she is as opposed to finding out whether or not the candidate is a good fit for the position. I recently read a blog post that stated that candidates should spend a great deal of time preparing for these coding interviews, in the neighborhood of about 40 hours. While this might be what it takes to “ace” such an interview, it still begs the question of whether the coding interview is actual predictive of the candidate’s ability to function in the position. It is not.

This is where the cognitive biases come in. It appears that there is a great deal of the illusion of control, which, as humans, we are highly susceptible to. We think that somehow we are able to ask some questions and magically be able to determine how one will perform on the job. I would expect there is a bit of confirmation bias because we are subject to cherry-picking our evidence to support our previously held views (i.e. coding interviews are effective) and a similar bias called choice-supportive bias which is the tendency to remember one’s own choices as better than they actually are. I am certain that a whole host of other biases can be brought forth which not only explain why we think coding interviews are effective when there is evidence to the contrary, but also the stubborn way in which these have continued to persist in spite of such evidence.

In my career I have taken a few of these interviews and I may have my own biases since I don’t recall ever getting a job offer after one of these interviews. I remember taking one many years ago on SQL and ETL. I had been doing SQL and ETL quite successfully for over a year and knew I could perform very well in the position.

Nevertheless, the test was taken not on my own computer, but a computer that I was wholly unfamiliar with, a laptop with a built in mouse. I remember that I had some frustration just with the configuration of the computer I was using. I also remember that the majority of the questions I could have easily answered had I been able to use reference materials like I would be able to do in the real world. It felt like the test was measuring how well I could fix my parachute after I had been thrown from the plane. It did not measure how I would perform on my job, but how well I had memorized simple syntax that is probably not worth memorizing.

I know there are those who will say that one should remember such commands, but given that the average programmer contributes five lines per day to the final product, does it really make that much sense? Perhaps it would be better to fill one’s mind with other more important things? What I do know is this – had I been offered the position I would have outperformed many who would happen to ace this test because I have a wealth of experience outside of the ability to memorize coding syntax.

In a recent blog post I wrote a tongue-in-cheek title, “Accenture Ends Annual Review (and Admits Earth Orbits the Sun)”. Of all my dozens of blogs (I have posted over 100 over the years), this was perhaps the most provocative of them all and certainly the most popular, with literally thousands of views. In this case it took literally decades to finally admit what science has taught us with respect to annual reviews. Therefore, I expect that coding interviews will be with us for some time to come, but at least I can look forward to the day when I write the blog “Company X abolishes the coding interview (and Admits Earth is Round).”

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

19 October, 2015

Stop the Sprint Slop and Shot Your Zombie Stories in the Head

One of my loyal supporters last week requested I write an article about “sprint slop” and I am very happy to accommodate any requests. Before I could begin it was important that to understand the request because this particular term is not ubiquitous. A Google search for “sprint slop” returned few links and those returned were associated with skiing and not Agile or Scrum. Nevertheless, I had a good idea of what was meant by the term “sprint slop” and was able to isolate the meaning to refer to those stories that move from sprint to sprint and are not completed. I have also referred to such stories in my agile coaching practice as “zombie stories” since the never seem to “die”.

“Zombie stories” are a great indicator of team maturity, the origin of which is mostly related to either stories that are too large, poorly written and poorly refined or teams that are pressured to plan more in a sprint than is possible or are victims of “false” dependencies. In most cases, the root cause of the above is related to poor understanding of Agile Scrum from the business, particularly in relation to expectations of the product owner and the amount of time that is necessary to devote to the processes associated with the scrum framework.

The scrum framework consists of ceremonies for each sprint – daily standup, planning, review, retrospective and refinement (new term – originally referred to as grooming), which can be broken into backlog refinement and story refinement. If we were to look at the time that is necessary for all of the these ceremonies for a two week sprint (which seems to be the most popular timeframe), we would have something similar to the table below, with the total time between 9.5 and roughly 12 hours:

Ceremony	Time (in Minutes)
Daily Standup	150
Planning	60
Review	60
Retrospective	60
Refinement	240 – 400
TOTAL	570 – 730

Refinement of the backlog (and stories) for future iterations is estimated to be between 5 and 10 percent of the current sprint. It is during this time that we gain a greater understanding of the work that we are going to do in the future. In my agile coaching I break the refinement into backlog refinement and story refinement. Backlog refinement consists primarily in story identification, effort and value estimation, and sequencing of the stories – basically understanding the work that will be done in the next iteration. This happens as the beginning of the sprint in anticipation of the future sprint. The story refinement happens after the sequence of the stories is understood and consists of a deeper dive into the stories, one at a time in backlog order, generating a good story description (As a..Iwant..So that), generally understood acceptance criteria (my teams use BDD) and preliminary implementation tasks and estimates that are used for Sprint Planning ceremony.

When I have witnessed “zombie stories” and “sprint slop” it has been generally the teams inability to take the proper amount of time to refine the stories for future work and by not using tasks and hours to better understand the implementation of the stories. I know my particular way may be somewhat controversial since the trend these days is to not do estimates, either for tasks or stories, but in my experience the ability for teams to become predictive (ie complete 90% or greater of planned work) is something for mature teams and tasks and hours are a necessary step to help the team truly understand what they are capable of accomplishing. The detail work forces the team to consider how they will implement and will give the team more information on the true size of stories and places they might be able to break the story into smaller pieces.

In some cases, where the detailed work is done and the team still is unable to complete high percentages of the work, then the problem can be related to pressure from the business. Sprint Planning should be based in reality, but when timeline expectations are placed on a team, their natural inclination is no longer to make estimates and predictions based on their best understanding of the work, but based on the expectations of how much work “needs” to be completed.

The last reason I see for work moving from sprint to sprint is dependencies. Again, this is more an indicator of maturity level and an inability to write proper stories, than actual “hard-stop” dependencies. A “hard-stop” dependency is one where no work can be accomplished unless some other work is completed first. In software development I usually find that these are the more hardware-dependent stories. It is really difficult to deliver working software if I do not have the servers with which to deliver the software to.

However, my experience has taught me that most of the stories teams think are dependencies are, in many cases, not. These I call false dependencies and proper utilization of an INVEST acronym in writing stories will go a along way to breaking these “false” dependencies. For example, if there are two different team working on the same feature, one that is doing the backend services and one that is doing the front end UI work, then there appears to be a dependency of one team waiting for output from another team. This is a “false” dependency. There are two ways to address this issue. First, I can change the teams so that they follow the guidance that all members necessary for software functionality are on one team. Second, I can create three different stories that would allow the teams to operate somewhat independently – one for the service mocking the front end, one for the front end mocking the service and one for integrating the two stories. While not ideal, it allows for much quicker feedback on the work and allows the teams to schedule a chunk of work that they can accomplish in a single sprint. This can even work sometimes with hardware dependencies. I currently have a team that did their integration locally to a laptop while they waited for the real hardware to be delivered. Again, no optimal, but it did represent a way for the team to deliver into an environment that allowed for faster feedback and it is particularly this feedback that is missing from “sprint slop” and “zombie stories.”

One word of caution about team commitment and expectations. When I received my CSM training all those many years ago, I was taught that every story (100% of the work) should be completed by the end of each sprint. I remember the instructor saying something about developers “chopping off their arms” and “banging them on the keyboard” if it was necessary to get the work done. I did then, and still do not, believe that this is what is meant by commitment and have railed against the 100% expectation ever since. As with all things in life there is the ideal and the acceptable. My three boys are all still in various years in school, but my expectation from all is that they try their best to get 100% on every test, but I find that 90% or greater (an “A” these days) is acceptable. I preach the same with my scrum teams. Of course, we plan each sprint so that we can complete 100% of our work, but I find that 90% or greater on a consistent basis is acceptable because it shows maturity in planning and predictability in implementation so that longer term planning is possible.

The thing to always keep in mind is that Scrum is a framework that will shine a light on those things in your current environment and system that are not optimal. Scrum also gives you the framework to continually improve and solve underlying issues. “Sprint slop” and “zombie stories” are merely another example of the systemic symptoms Scrum will shine a light on. If you follow the framework properly it will also give you the ability to fix the underlying system so that you can be “sprint slop” and “zombie” free.

6 October, 20156 January, 2016

The High Cost of “Low Cost” Software Development

I recently spoke with some software development professionals about the economics of software development and how Agile Values and Principles, when properly applied through a framework like Scrum, could improve a company’s bottom line. One thing we discussed was that so many companies who develop software are ignorant of the economics of software development and the Total Cost of Ownership (TCO) of software development. Companies often try to save money by choosing the lowest cost software development option. My friends referred to this as sourcing software development on price alone. At the new division I manage, 10XP Solutions, we call this the high cost of “low cost” software development.

What is the high cost of “low cost” software development? This is the tendency for people involved with financial decisions regarding software development to put too great an emphasis on the cost of software developers. I have recently coined the Law of “Low Cost” Software Development that states, “In the absence of additional information and a lack of understanding of the economics of software development, the choice of software developers will be based on cost alone.” Unfortunately, in practice this law leads to an overall higher cost of software development.

One example I use frequently involves the concept of technical debt. Once I was asked to write an article on technical debt. When my article was published, it was stripped of a definition of technical debt because the editor believes everyone in software development knows what technical debt is. I protested, but to no avail. Nevertheless, I still maintain this assumption is not only incorrect, but it is fundamentally dangerous. I have found the number of people who make decisions affecting the creation of software who do not understand, or may have not even heard of, technical debt remains shockingly high.

For those uninitiated with the concept, technical debt was invented by Ward Cunningham as a metaphor to explain the real cost associated with short-term decision-making and shortcuts taken in software development. A classic example would be the first time code is shipped and market forces dictate that speed to market trumps all other concerns. Cunningham’s conception would be that technical debt would be a conscious decision made with the trade-offs known. Over time it seems that technical debt has morphed because these days a great deal of debt accrued by organizations is unconscious. In other words, they are creating technical debt with little or no awareness. In these cases technical debt is like high blood pressure – a silent killer.

There are now ways to quantify technical debt. The CRASH Report calculated the cost to remediate technical debt concluded that the current levels of technical debt average $3.61 per line of code (the amount is higher for Java code at $5.42). As technical debt increases so does the complexity of the code and the difficulty in making changes to existing code. This means that new features added to existing code will take much longer to develop. How much longer? A study by Dan Sturtevant at MIT, entitled “Technical Debt in Large Systems: Understanding the cost of software complexity” found that complex (technical debt-laden) code resulted in:

Up to a two-fold increase in the amount of time to enhance software (50% decrease in developer productivity)
Up to a 310% increase in defect density
Developers working on poor quality code had up to a 10x increase in employee turnover

How these translate into hard dollars may be difficult to determine, but we can certainly infer that defect laden code increases the maintenance cost, QA cost, tracking cost, defect reporting cost, and costs related to poor customer satisfaction. The most surprising finding was developers working on poor quality code had a greatly increased amount of turnover. There is as obvious hard cost for replacing already difficult to find developers, but also untold morale cost for those who remain.

Total cost of ownership (TCO) addresses the total cost of software development from inception to sun setting. In 2011, the CRASH report stated the total cost of ownership for software code was $18/Line of Code (LOC). Of this, it is generally accepted that the majority of this cost is related to the maintenance of the software after its initial creation, with estimates ranging from 60-90%.

Because the majority of our cost involves maintenance it doesn’t make a great deal of sense for us to spend our effort trying to pare down the initial cost of development by employing lower cost developers. If we use less expensive resources, we could expect technical debt to increase. As technical debt increases, so too does the cost of maintenance. If we assume a slight increase in technical debt (50%) which results in maintenance negatively impacted by only 33%, our “low cost” resources have now actually cost us $4.92/LOC more. In contract, an approach that focuses on higher quality, while a little more expensive in initial cost, results in overall savings.

Strategy	Average	“Low Cost”	High Quality
Initial Cost	4.50	2.25	6.75
Technical Debt	5.42	8.13	2.71
Maintenance	13.50	18.00	7.50
Total Cost	23.42	28.38	16.96

There are other factors to consider in addition to just initial cost, technical debt and maintenance. Many people employing the “low cost” software development model are rarely paying attention to another hidden cost – the cost of delay. Frequently a trade off is made between cost of developers and productivity with lower cost developers being less productive. This results in software products that take longer to produce and deploy.

Of course, because these developers are lower cost, one could always just throw more people at the problem, which is often done. However, adding more people to solving software development problems does not result in a corresponding increase in productivity and obviously eats into cost “savings”. There are many who believe doubling the number of people results in a doubling of productivity. This is an example of applying mechanistic thinking to knowledge problems. There are numerous studies indicating increasing the size of teams results in productivity increases much lower than expected. Therefore, “low cost” development leads to longer cycle times and a higher cost of delay.

While it may be seductive to think that you can save money on software development by using “low cost” developers, it rarely results in overall cost savings when considering TCO and cost of delay. The cost of delay and technical debt are generally hidden costs (at least on the balance sheet). Over the years I have had numerous discussions with software development professionals (CIO, CTO, Development Managers, Product Owners, etc.) regarding the “low cost” software development models and there is nearly a universal befuddlement over why the model continues to flourish. Unfortunately, many people making financial decisions regarding software development resourcing simply do not understand the nature of software development and TCO. If they did, my guess is that they would make drastically different decisions.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS