Laws of Software Development

In speaking with people about the complexity of software development, one comparison I’ve often used to describe it is to relate software development to physical engineering. Engineering can rely on physical constants that can be expressed as formulas or constant numbers. For example, the tensile strength of AISI 1018 mild/low carbon steel is 53,700 psi. Standard gravity is defined as 9.80665 m/s2. Engineers can rely on numbers such as these to design and build objects.

In software development, complexity arises because there are very few (arguably zero) constants that we can rely on. At any given point, something can fail or not preform to specification. Life would be far easier for software developers if we could rely on a network connection always operating at a certain speed, or a CPU operating at a certain capacity, or a database never failing, or a file system never becoming full…the list goes on of the failures that could occur.  But we cannot rely on these failures not occurring and we must build in the ability to handle these failures, and this drives up complexity. Not having a defined set of laws to operate by makes it all the more challenging.

Interestingly, we find that the reverse is often true with the softer side of software development. Over the last few decades, numerous rules, laws, and heuristics have emerged from software project management that describe the nature of software development. I thought it would be fun to highlight a few of them – let me know your experiences in the comments!

Eagleson’s Law

Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.

Brook’s law

Adding people to a late software project makes it later.

Galorath’s 7th law

Projects that get behind, stay behind.

Conway’s Law

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

Hofstadter’s Law

“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”


Context-adaptive devices

We are seeing growing trend in mobile platforms is to attempt to be relevant in the context in which you are using them, driven mostly by platform-specific virtual assistants but also by applications that are using platform capabilities such as geo-fencing.  One example every day that I see is Google telling me every morning around 8:30 what my current commute to the office will be, and if it’s longer or shorter than the day before.  Towards the end of the day, I get a similar message on my Android phone telling me about how long my commute home will be.  It’s able to do this because it knows it’s a pic1business work day, that I’m at the office, pic2and it’s about time for me to head home.  It takes into consideration the traffic conditions to give me the information that I need, at the time I need it.  I get similar messages from Cortana on my Windows 10 machine.

So this is great…but…mobile platforms need to take this concept much, much further.  What I experience in my life is that I need a mobile device that can adapt itself to where I’m at, what I’m doing, and what kinds of apps and services I need to best support what is going on at that moment.

For example, on a weekend – especially a weekend I’m out of town with my family – I don’t need immediate access to my email.  (I most often remove the Outlook app icon from my homescreen so I’m not even tempted to open it!)  I don’t need my Slack app, or need to be notified about new messages.  I don’t need easy access to Office apps on my device.  I do need quick access to messaging apps, my camera app, maybe a few social media apps, and my photo gallery.  And I need to prioritize battery life, because if I’m away for the weekend, and likely, I’m not near a power source.

During the week, at least between 7AM and 9PM, I need my device to be in “business mode” – I want notifications from business-focused apps, and I want quick access to my email and my calendar to stay connected to what’s going on with work.  I care less about social media apps, my camera, or photo gallery.  I want my device in “high performance mode” – typically I’m near a charging source, and often my device sits on a wireless charger when I’m not using it anyway.  Battery life is less a concern, so let’s max out the usefulness of the device.

There is no reason that my device cannot learn from what it knows about me to adapt itself, or at a minimum, allow me to create a set of rules which govern what mode it is currently in.  Our devices know all about us – it’s time that they start truly adapting to the context in which they can be most useful to us.

Where should Scrum Masters report?

I have heard this question perhaps twenty times over the past several months.  “What part of the organization should Scrum Masters belong to?”  “Who should their manager be?”  At best, the root of this question is to find the part of the organization that will serve the role of Scrum Master optimally, providing the best possible leadership, coaching, and mentorship for those in that role.  At worst, it’s a question to determine a “land grab” of people for organization political power.  For those reading who serve as an agile coach for an organization, you have no doubt heard questions such as this one from those looking for prescriptive advice to solve a problem driven by complex variables.  As it turns out, there is no single right answer, but there can be a best answer given the scenario.

Often, there are not many choices from which to answer this question.  You may have the IT department, a PMO, or perhaps you are lucky enough to have an “agile center of excellence” group.   The major variables you should be thinking through are organizational culture, experience and mindset of management in those groups, and the ability of that group as a whole to promote a positive learning experience for Scrum Masters.

If your IT organization has a very agile and lean mindset, and is focused on not just technology delivery, but on high-performance process and has a culture of mentorship…that might be a good option.  I’ve seen this work.

If your PMO has thrown out the mentality of waterfall project management, has leaders that embrace and evangelize agile and lean thinking, and your Scrum Masters are former Project Managers…that might be a good option.  I’ve seen this work.  (ProTip: look at renaming that department if this is the case.)

Maybe you have developed a formal “agile center of excellence” group within your organization that is wholly focused on helping the organization adopt agile culture and practices…that might be a good option.  I’ve seen this work too.

The bottom line is that the Scrum Master role (and for many, is a full-time job) needs to be a part of an organization that helps people learn and thrive to the betterment of the entire company.  Find the best possible group in your organization for people in that role to live and grow in, and your experience with Scrum will be that much better.

The Software Project Model is Broken

*cross-posting from LinkedIn*

Yes, I went with a provocative headline to grab your attention.  It must have worked because you are reading this.  So don’t stop now – let me put some ideas forth to stimulate discussion and thinking.

First of all, I’m not the only person who thinks that this headline has some merit.  My friend Chris Sheridan posted on this topic last year.  Other very smart people have also published pieces declaring the project model dead.  There is a“#NoProjects” hashtag on Twitter.  (Because you need a hashtag for a movement like this)  So I’m definitely not alone and completely off the ranch with this thought.

There are two fundamental issues that we are seeing with the concept of “software projects”, especially as they exist in today’s world of agile software development.  Perhaps the concept of a “project” fits far better with a waterfall approach, but as our industry transitions to agile development, the concept of a project starts to confuse the situation.

First and foremost, software – and especially custom software – is often not thought of as a long-term investment in a capability or service.  It’s most often viewed as a large one-time expense to the business, because it’s typically fairly expensive to pay for during initial development of the product.  (Note: I’m ignoring the financial perspective of this via a cap-ex model.)

Secondly, projects (of any type) by their very nature are defined to have a beginning and an end, and are temporary.  Even the Project Management Institute defines projects this way.  So why are these two concepts causing issues?  Let’s explore…

Why do we use software in business?  There are several subtly different reasons, but at the end of the day, it is either to enhance productivity and drive down costs, or to provide a service or capability to customers to generate revenue.  And to be competitive today, companies need to provide a continuous flow of new value to customers.

We already know that software is not a one-time investment…it’s like a pet.  Yes, you pick it up from the shelter, get a leash, get some food, pay for a vaccination, buy a bed and some toys, and quickly you are out $500…and then you buy food every week for the next 12 years…pay thousands in vet bills…buy hundreds of dollars of toys…pay hundreds in boarding fees over the lifetime of the pet.  So while you think you have a high initial investment, you actually end up paying far more over the lifetime of the pet than you did when you got home with them.  It’s very much the same with software.  While the initial investment to get that first product out the door seems high, it is going to be less than the ongoing investment.  Yet we focus on the cost of “the project” – that initial investment, and we often ignore the larger lifetime cost.  Companies also tend to ignore the competitive nature that innovative software solutions bring.  As I wrote earlier, to be competitive, companies need to continually invest in their solution to bring new features and capabilities to the market.  Projects with end dates don’t work well with the need to continuously provide value to customers.

This slides into the second issue: the end of a software product comes when the true end of its lifespan has arrived.  The end of a piece of software is not when the “project” is over – it is when that software is fully retired from service.  When it’s uninstalled from servers, removed from desktops and devices, and deleted from app catalogs.  Until then, it’s costing you money to run and maintain.  The end of a software “project” is when you want to stop investing in it – not when you reach some arbitrary or estimated date.

So what are companies doing to re-think “projects”?  Companies doing innovative work in a continuous flow model have re-thought the concept of “projects” to an “investment streams” model.  We are seeing great success with organizations who have re-aligned their delivery teams by portfolio/product areas, which map to business investment streams. If there is a new capability or product your company wishes to invest in, it is smart to think about the level of investment that you are going to put into the capability over the life of it, from the first day to the last. After all, if it’s a great product, your users are going to be demanding additional capabilities – so don’t be stuck in a project mindset!

New Role at AgileThought

For the first time in 12 years, I have a new job title: Chief Solutions Officer. Since 2004, our company has changed in massive ways, and so has our industry. Companies are buying services and technology in ways not envisioned over a decade ago. My focus will be on defining and building new services and offerings for our clients to enable them to keep up with the rapidly changing industry. I’m fortunate in that I’m not doing this alone. We have an incredible team that I’m going to lean on in a big way. I’m excited to get started, and great things are to come!

Agile Reading List

Since 2011, I’ve published a software development-focused reading list.  These are books, that in my opinion, should be read by people directly involved in delivering enterprise software, which is my primary perspective.  I have refreshed it every few years, and it’s again due for an update.  However, I’m doing something different this year, which is to break the list out into some specific recommendations based on a persons skill or role on an agile team.  Perhaps you focus your time on writing code – you are going to have a different base of knowledge than someone who is in the role of Product Owner.  This isn’t to say that there is not value in reading any book on the list – I do believe there is value in reading about others perspectives – but I wanted to segregate because there are some “must reads” for some roles.  Finally, this list really is aimed at those who are trying to learn (or refresh themselves) about agile.  If you are an experienced agilist, it’s likely you’ve read a good portion of these books.  So without further ado:

Anyone involved with Agile software delivery

Doesn’t matter your role – if you are directly involved in Agile software delivery, these are must reads. 


User Experience

These recommendations come highly from a few people directly involved in delivering user experience-focused products using Scrum.  They are not mine directly, but I trust the opinion of those who recommended them.

Testers / Analysts

Is your focus on the team about delivering a product but you aren’t writing code?  Are you focused on working with your product owner to envision a solution, groom a backlog, do exploratory testing, and release a quality product?  These are for you.


Have to worry about your Agile development team shipping software all the time?  Get in sync with these two classics. 

Product Owners

Executives/Organizational Leaders

Agile Coaches/Scrum Masters

I actually think people in these roles, especially a coaching role, should read every single book on this entire list, so they understand the principles and thinking around all roles. 


Here are a few other random recommendations not directly related to agile, but come extremely highly recommended from those whose opinions I trust. 

I’m sure there are many books that are very worthy of being on this list.  Our industry is blessed with talented and passionate people who have great ideas to share through the written word.

What are some books you’ve read and would recommend to others?  Comment below!