When building software, where progress can often be invisible to the outside eye, the importance of making engineering work visible cannot be overstated. Unlike a physical construction site, where one can observe the ongoing work, software projects present unique challenges in terms of project management and oversight. This article explores the pressing need to make software engineering work visible, the key benefits it provides, and practical approaches for achieving this crucial objective.
Imagine being the main foreman of a construction company that builds residential homes. Your responsibility is to ensure that each of your crews (framing, roofing, plumbing, electrical, drywall, carpet, and so on) are doing their work well and on time. However, there is one caveat – every day you go to the construction site to monitor progress and guide your team, but you have to do it while blindfolded. You can feel things with your hands, but you’re not allowed to see the construction progress with your own eyes. You have to rely on talking to each crew member and have them describe the accomplishments and progress.
How successful do you think the home-building project will be? That’s right – not very successful.
Now let’s add another condition. Not only you, the foreman, are blindfolded, but also each crew can only see their own work. They cannot see the work of the other teams. So, for example, when the electrical team comes to install all the wires, they cannot see the plumbing already installed, which often runs inside the same wall spaces. So now when the electrical team has to drill holes into the studs, they have no way of knowing whether the drill will accidentally puncture a pipe or not.
Again, how successful will this home-building project be? How much rework will have to happen until it passes all the inspections?
Unlike building a house where one can see all of the work and immediately know the progress, software work is mostly invisible. The main exception is any front-end work with its user interface. However, often the UI is just the tip of the iceberg, beneath which lies all the front-end code and integration with the back-end, the back-end code, the data structures, any third-party integrations, test automation, infrastructure, security work, and more.
If I am the manager/leader, how can I ensure the home-building project is going well? How can I ensure that the software-building project is going well? How can I course-correct and lead the teams in the right direction with only limited visibility? The effort would be doomed for failure.
Take, for example, how a navigation system works in a car. Once the destination is set and the course is charted, the trip begins. The key part is that throughout the entire journey, the navigation system and the satellites are communicating continuously. This crucial mechanism tells the navigation system where the car is located at any given moment. It is the only way it knows whether the driver has gone off-course or not, and the only way it can suggest alternative routes and course-correct any errors in near real-time.
So if the majority of the software-building work is not easily visible, leading a software project effort would be nearly impossible without visualizing the work somehow. This is even more important for remote teams.
Making software engineering work visible is not a nice-to-have, it is a must-have. Here are some explicit benefits.
Not only can the manager/lead see where each team and individual member is, but other stakeholders can also see the work and understand the status easily, such as product owners, QA members, team leads, architects, support team members, and so on. Having such visibility in near real-time will paint a clear picture that will answer some of the most fundamental questions:
There will be fewer misunderstandings, miscommunications, and misalignments. The entire operation will run more smoothly.
When the software engineering work is visible, it will be more obvious when we are working on the wrong priorities. As an engineering leader, I have noticed that developers can easily get into “rabbit holes.” Meaning, while working on a user story, they will notice something that needs improvement. Whether it is part of the current focus or not, they will be tempted to go and fix it. Thinking it will be a small effort, they eagerly jump in. A few days later, they are still sidetracked with this innocent improvement, but now they’ve dug the hole and have to finish what they started. This directly impacts their original commitment. While 2-3 days, once in a while, may not have a significant impact, when the majority of the team does this regularly, it will add up very quickly and can slow down the entire project.
If all engineering work is not made visible, these types of “underground” efforts will go unnoticed and ultimately cause problems.
It is important to note that I am not advocating against improving code while working on a user story. The danger lies, however, when such improvements happen without intention, without communication, and without making them visible.
Having full visibility of all software engineering work will be equivalent to a navigation system knowing the coordinates of the car at all times. This will surface any off-course movements quickly and will give the team and their leader a chance to discuss and course-correct.
Additionally, we will have a clear picture of where we are focusing our team members. This will make it more obvious when we have allocated people to less important or urgent work.
When the software engineering work is visible, the leader can easily see if things are progressing well or not. They will not need to talk to their teams as much in terms of asking for status. Additionally, most software developers don’t like being constantly asked for status updates. When the work is visible, the leader can pay attention and initiate conversations only when something does not seem right.
When the work is recorded and made visible, we can measure and improve various aspects of how we build software. This is not to say that we should measure things for the sake of measuring, but there are certain metrics that are really valuable to measure. Cycle time is one of those metrics, which tells us how long it takes for a work item to move from “in-progress” to “done.”
Additionally, we can look back historically and understand where our teams’ time and effort have gone. What types of projects, features, etc. This can help to design healthier cost allocations and budgets because we will know where we are spending our money, time, and effort.
As a Fractional CTO, I can help. With over 20 years of experience in software and technology leadership, I offer part-time, interim, and advisory services to tech startups and small software companies just like yours. I’ll work closely with your team to improve visibility into your engineering efforts, streamline your workflows, and put the right processes in place to accelerate your growth.
If you’re ready to take your software engineering efforts to the next level, let’s connect. Schedule a complimentary consultation to learn how my Fractional CTO services can help your tech company.
There are various methods and tools available to visualize software engineering work. However, there are certain principles that can prove beneficial when applied. Adhering to these principles can help ensure the visualization process is effective and provides meaningful insights for the project.
While there are a number of options when it comes to software project management tools, it is important to remember that a good tool is only a vehicle for accomplishing something. How that tool is used is equally, if not more, important. Don’t fall into the trap of thinking that just because you picked a good tool, it will not take discipline from everyone who uses it in order to make it useful.
Years ago I joined a software company where all the work was invisible. While we eventually started using a real project management tool, we started immediately by using a simple kanban board on a physical wall, using paper stickies. It made a night and day difference especially for me, the newcomer, who had no idea of who was working on what. This approach served us well for several weeks until we finally transitioned to an online platform.
Another aspect of making the engineering work visible is to use hierarchies. I believe that at the very least, there should be 2 levels of hierarchy: Features/Epics and User Stories. That way, the features reflect larger chunks of work, and the stories represent the breakdown of those large chunks. I don’t believe that there is a magic number of levels, but the simpler the better. Ultimately, it has to work for your team.
When making the software engineering work visible, we first need to capture its initial state and then maintain it to visualize the progress and how it changes. It is important to note that in this effort, we are trying to make a visual copy of reality. Unlike a physical home construction site, which I can go to and physically see, I cannot see the actual engineering work accomplished at any one point. Therefore, I represent a copy of it in a visual form inside a project management tool.
Because of this, it is critical for the project management system to constantly represent reality. Otherwise, it will be useless. For it to represent reality, it means that it accurately needs to capture all the work and be maintained in near real-time as work is scheduled and accomplished.
In software development, where progress can easily become obscured, making engineering work visible is no longer a nice-to-have, but a critical necessity. By applying the approaches outlined in this article, software teams and their leaders can reap the benefits of visibility, leading to increased alignment, improved focus, better oversight, and ultimately, more successful software projects.