Developing a Culture of Meaning for Software Teams

“This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity.”

“To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind.”

Building a successful software development team is a challenging task. Not only do you need to find individuals who are skilled in their craft, but they also need to have a certain mindset and approach to their work. They need to be idealistic and creative, but also able to think critically and pragmatically. They need to see their careers as a calling, not just a job.

Finding these kinds of people is difficult, and they are often in high demand. They regularly receive offers from recruiters and have a wide range of opportunities to choose from. As a result, to attract the best talent, you need to offer something that they can truly believe in.

This means having a clear and compelling vision that speaks to the hearts and minds of potential team members. This vision needs to be real and have integrity, and should be backed by a leader who is not just a salesperson, but someone who genuinely cares about the people who choose to follow that vision.

Many organizations try to attract talent by talking a big game and manufacturing unauthentic ideals, values, and visions. They try to show how “cool” they are by engaging in imitation innovation. But this kind of behavior can only fool people for so long if it is not truly part of the organization’s DNA.

To truly land the best talent in the industry, you need to have a cause or idea that people can rally behind. And you need to create a culture that aligns with the way that technology professionals want to be treated. This means moving away from traditional command-and-control structures and towards a flatter, networked organization that is in line with the modern knowledge economy.

Software has and continues to drive the modern industrial revolution, and as a result, it is at the forefront of shaping modern organizational culture. Instead of trying to fit technology professionals into existing corporate structures, organizations should strive to create cultures that align with the values and goals of the people who work in technology.

To do this, organizations need to prioritize autonomy, mastery, and purpose in their culture. They need to trust and empower their team members to use their skills and experience to build great things. They need to provide opportunities for growth and development, and create an environment where people can learn from each other and push the boundaries of what is possible.

Of course, creating this kind of culture is not easy. It requires a commitment to change and a willingness to challenge the status quo. It requires leaders who are willing to listen and learn from their team members, and who are willing to adapt and evolve in response to feedback.

But the payoff is worth it. A culture that aligns with the values and goals of technology professionals will attract the best talent in the industry. It will foster innovation and collaboration, and it will enable your team to build great things together. And in the end, that is what truly makes a software development team successful.

Advertisement

Estimates, commitments, and targets in software projects

“Many people don’t even know that there is a difference that has led to countless project failures.”

Most people have never learned what good software estimation looks like or how to communicate it effectively.

The importance of understanding the difference between estimates, commitments, and targets in software projects

In my previous article, I discussed the inherent complexity of doing software estimation and the phenomenon of discovered complexity. Beyond this complexity lies another problem: poor communication. Most people have never learned what good software estimation looks like or how to communicate it effectively. Business people involved in software projects often view estimation as the domain of the technical team and make no effort to understand its nuances. Technical team members, on the other hand, often rely on gut-feel estimates without understanding the importance of clear communication.

As a result, estimates are often treated as commitments, and commitments are communicated as targets. Many people don’t even know that there is a difference between these concepts. This lack of understanding has led to countless project failures and eroded trust in the software development process.

To clarify the differences between these concepts:

• An estimate is a best guess at how long something will take, based on the information available at the time. As I explained in my previous article, estimates are inherently flawed and will change as more information becomes available and problems are solved. A good estimate should be plotted against a probability curve to quantify the uncertainty and risk surrounding it. Rather than communicating a single point estimate (e.g. “I think this will take 6 months”), it’s better to communicate a range (e.g. “given what we know, this could take anywhere from 6-9 months”). Thinking of estimates as a range of possibilities reduces the stress of having to be perfectly right and accommodates the inherent ambiguity and uncertainty of the software development process.
• A commitment is a promise to deliver functionality at a certain level of quality by a certain date. It’s critical to realize that estimates inform commitments, but commitments should never drive estimates. The working position should be that the estimate is flawed and commitments should be based on the most pessimistic estimate, allowing for additional buffer time. If the estimate is not acceptable, business stakeholders should prioritize the project and make the hard choices necessary to give it a quantified chance of success.
• A target is a single-point hard deadline, usually driven by external factors such as a product launch or a regulatory requirement. Targets are not based on estimates or commitments and are often imposed on a project team without their input. Meeting a target can require significant compromise on scope, quality, and/or timeline.

In summary, it’s essential to understand the purpose and value of software estimation and to communicate estimates, commitments, and targets clearly and accurately. By doing so, we can avoid the frustration and trust erosion that often results from project failures.

Project Delays: Why Corporate Companies Struggle with Accurate Estimation

“‘The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – Bollinger, T

At the heart of this problem lies the phenomenon of discovered complexity.

Accurate estimation is one of the biggest challenges in software development. It’s a problem that has plagued the industry since its inception, and it’s one that elicits strong opinions from everyone involved in a project.

Every company has its own collection of horror stories about projects that have slipped catastrophically or seem to perpetually overrun their budgets and timelines. These delays can result in lost jobs, damaged careers, and, most importantly, destroyed relationships.

For some companies, this is such a common occurrence that the destruction caused by poor estimation has become the norm rather than the exception. In these environments, the trust between business and technology may be so eroded that any attempt at coming up with reasonable project estimates is regularly abandoned.

Instead, these companies are bombarded with unrealistic business demands that are labelled as “critical deliverables,” even though they are based on no quantifiable reality of effort. These “immovable” business targets are often arbitrarily tied to people’s KPIs, even before the feasibility of the work is explored. The recipients of these KPIs are typically people with no experience in software estimation and no understanding of the differences between an estimate, a target, and a goal.

At the heart of this problem lies the phenomenon of “discovered complexity.” For some reason, people view software development as a mechanical task similar to an assembly line in a factory. However, as research has shown (even mathematically), “the creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” In other words, software development is a creative process that requires a lot of thinking about unknown problems that constantly arise. These “accidentally discovered” problems can lead to more subtle and indirect problems that also need to be solved. This is called “accidentally discovered complexity.”

In simpler terms, at any given point in time, you don’t know what you don’t know yet, and there’s no way to predict how long it will take to figure it out when you do discover it. In this world, how can you accurately estimate how long something will take? At best, you can make a reasonable guess based on the information you have at that moment. But even this is problematic because the information you have about the problem domain changes and develops as the project progresses.

Given this, it seems virtually impossible to accurately estimate these creative tasks. Therefore, it’s essential to follow an iterative development methodology that includes a constant feedback loop for estimates. If you’re not continually re-estimating how long a piece of work will take based on all the new information you learn, you’re putting your project, and more importantly, your organizational goals and commitments, at risk. Do that often enough, and you’ll see the consequences unfold.