Essential Agile

In my previous article, “The Technology Executive and the Software Craftsman,” I discussed how software developers like me who were trained in the earlier software engineering disciplines that were managed based on the waterfall model felt that there was something fundamentally flawed with the model. We knew that close collaboration between developers and clients usually yielded better results, but the formal waterfall process created barriers to that collaboration. In this article, I will explore the fundamental flaws of the assumptions underlying software engineering as managed by waterfall models. I will then discuss how Agile software development methods address those flaws by addressing the inherent design-centered process that we know as software development harnessing its people-centric and social aspects.

Engineering Software as a Flawed Assumption

While the waterfall model, when applied to software development, has taken its share of disparagement over the years, the failings of the waterfall model itself are merely symptoms of what I see as a flawed assumption about software development. That assumption being that software is engineered at all. Engineering as defined by Wikipedia is “the application of mathematics, empirical evidence and scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, and processes.” Engineering frequently assumes formal methods and disciplined sequencing of development steps. It is no accident that when the development of software is viewed through the lens of engineering that the waterfall model takes center stage as the incarnation of the software development process.

Many a long-time practitioner of software development believed that viewing software development as an engineering discipline was attempting to shoehorn a more iterative process into a formal engineering discipline when in fact the process of developing software was another animal altogether. In current software development thinking, we talk more about software as being designed rather than engineered. Part of the Wikipedia’s definition of Design states, “Designing often necessitates considering the aesthetic, functional, economic and sociopolitical dimensions of both the design object and design process. It may involve considerable research, thought, modeling, interactive adjustment, and re-design. Meanwhile, diverse kinds of objects may be designed, including clothing, graphical user interfaces, skyscrapers, corporate identities, business processes and even methods of designing.” When we view software development through the lens of design which involves interaction, collaboration, and adjustment, the problems with the engineering-centric view become apparent.

Software Design as a Better Paradigm

Engineering infers technical competence, adherence to standards, sequenced collaboration, and top-down management to enforce process and standards since those are assumed to determine timeliness and quality. Design infers technical competence, collaboration, managed discord, and servant leadership to remove obstacles to progress in response to uncertainty. So why does assuming software development is an engineering discipline so often result in late projects and dubious quality? There are two reasons. First, engineering assumes that a problem can be almost completely understood up front, and only minor adjustments will be needed on the back end of the process to account for requirements changes. Second, and in what is bound to be a controversial comment, engineering values process and standards over individual judgment and intuition. In practice, because software systems tend to be complex and involve the sometimes subjective judgments of stakeholders, we seldom have a clear picture of the problem to be solved early in the software development process. Rather, the requirements become clearer over time, sometimes taking 30-50% of the project timeline to become well understood and enumerated. Engineering processes are not tolerant of such uncertainty while design process assumes uncertainty.

Design is a better model for software development simply because the process of design acknowledges the uncertainty of requirements and seeks to adjust and redesign as needed. At this point, some will say, “but design is part of any disciplined software development process.”  To those I say, treating design as a discrete component of the software development process denies the reality of rolling uncertainty and evolving clarity of the requirements. Rather, the entire software development process from end-to-end is an ongoing design process where the understanding of the problem evolves and necessitates almost continuous solution readjustment.

Clarity Through a Shifting Paradigm

When we get used to the idea that software development is better thought of as design process than as engineering discipline, key discriminators of success begin to emerge. First, we acknowledge that project timelines cannot be established at the beginning of the project. My own experience has shown that committed timelines can only be established after about 30-50% of what will become the total timeline has elapsed. Knowing this is important because executives and managers may have differing expectations about the timeliness of software delivery that need to be managed. This is not to say the Agile methods cannot establish and meet deadlines but rather that deadlines are established well after the project is underway. This is a fundamental shift in thinking about and setting delivery expectations. Second, the role of the project manager shifts from managing to deadlines to managing collaboration and removing obstacles to success. This is a critical distinction because many formal project management methods lean toward top-down management which is not amenable to iterative collaboration. It’s important that emphasis is placed on finding project managers who act more servant leaders versus managers of milestones since managing uncertainty means that risks will arise that must be mitigated collaboratively. Finally and most importantly, viewing software development as design highlights the fact that software development is an inherently social activity where interactions between people are valued over formal processes which seek to control such interactions. I have written extensively about the necessary tensions that exist in software development that need to be managed in order to produce great software. Engineering approaches seek to eliminate these tensions using process while design approaches acknowledge the existence of tensions and harness them to produce better results.

The Essence of Agile

Agile software development methods continue to evolve and are far from perfect. However, Agile methods more closely match the iterative and collaborative processes that align more closely with the true nature of software development. Still, engineering mindsets persist and manifest themselves in Agile shops. Agile by its very nature replaces tightly controlled engineering steps with a necessarily fuzzy set of guidelines. For example, the Agile Manifesto states the following:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I run into Agile practitioners who seem to replace the word “over” with the phrase “instead of” in the above guidelines. I don’t mention this to impugn but rather to highlight that dogma that is necessary for engineering discipline sometimes creeps into methods that are pragmatic by their very essence. Because Agile is inherently pragmatic and experimental, I find it valuable to continuously reinforce the “spirit” of Agile over its “letter.” Here are few examples.

Spirit versus Letter

The Agile Scrum method has a number of rituals that are intended to promote collaboration. Among those are sprint planning, stand-ups, showcases, and retrospectives. When we first adopted Agile Scrum at one job, we tried to be rigorous with requiring that these rituals were held in uniform ways. Over the course of time, some in the development staff began commenting on how they were not getting value from some of the rituals, for example, stand-ups and lobbied to do away with them. We went back and forth about whether stand-ups were needed. The more dogmatic supporters of Agile maintained that they were a required part of the process and that their use should be enforced. The more pragmatic Agile supporters argued that stand-ups were not needed because they were accomplished in other ways. After listening to both factions, I asked what was the “spirit” of a stand-up. Obviously, the spirit was to ensure the teams had a daily progress checkpoint. I found that while some teams needed the structure of a formal meeting because the team members worked independently, other teams worked more collaboratively on a daily basis and kept themselves more constantly informed of progress. In the former case, the team needed stand-ups to assess progress while the latter team had ad hoc stand-ups without the need for formality.

Lessons

So what are the lessons to be taken away? Software development is an inherently social process where technically competent people come together with their customers and iterate through a process that more closely resembles design than engineering. While there are some required steps needed to ensure fitness and quality, much of the Agile process in inherently fuzzy and open to pragmatic experimentation and adjustment. In Agile, one must keep in mind the spirit of the tenets of the Agile process and be careful to adhere to those intentions lest unreasoning dogmatism creep in and attempt to bend the people to the process rather than bend the process to the people. This does not mean that Agile development should devolve into an uncontrolled process. There are firm needs to enforce application lifecycle models and quality gates to ensure that best practices are followed and that traceability and validation can be maintained. But these necessities need to be balanced with the flexibility and pragmatism that Agile represents.

When a proper balance is struck between necessary practices and areas where experimentation and flexibility are promoted, you will find that your Agile teams will work more closely together to find solutions to their own problems. When teams are permitted to be experimental, they also tend to be more cohesive leading to more engaged and satisfied team members. If you focus on attending to the essence of Agile over strict doctrine, I think you will receive better results, and your teams will thank you for it.

Best,

Charlie

Agile Software Development Team Empowerment: A Holistic View

Over the past six decades, software development has evolved from what was thought to be an engineering discipline complete with rigorous methods and processes to much more of a crowd-sourced social engagement involving skilled craftsman and iterative collaboration.  Executives and managers have had to adjust their thinking from a “command and control” style where every aspect of software development was tightly timed and controlled to a “servant leader” style where the goal is to empower the team to make decisions and remove obstacles to their success. I have written previously about these  “softer” aspects of software development. In this article, I will pull together the previous concepts into to a holistic view of Agile software development team empowerment. My intention is to create a framework which can lead to more productive teams that produce high-quality code stemming from of business-focus, trust, and collaboration.

Before I begin, there are a few assumptions I make as precursors for any software shop as follows:

Assumptions

Good Talent. Any high performing team needs to be staffed with talented staff. Most well-functioning agile teams will police their own ranks and either help to raise the performance of mediocre members or identify those that need extra help and support. This self-policing comes from a strong sense of team and focus on the development goals. If you don’t hire the best talent and then allow Agile team dynamics to work their magic, then you may be forced to resort to command and control means to reach your goals. Resorting to command and control methods with Agile teams usually produces the undesirable outcomes of demoralized teams and high turnover.

Best Intentions. Most software development staff, given half the chance, will strive to understand a align with the business goals. In cases where they don’t, it is usually traced to a failure of the culture to support employees’ line of sight to the business. We must assume from the start that both software development staff, management, and executives work from a common set of good intentions. It is when we attribute mistakes to bad intentions that software projects spiral out of control in a frenzy of finger-pointing.

Supporting SDLC and Tooling. Agile software development is adaptable to many industry scenarios. Teams need an established software development lifecycle which sets expectations for how Agile is applied and governed. Agile works equally well at any point along the spectrum from loosely to highly regulated industries. Teams also need appropriate tooling to support their use of Agile and these are abundant. Open source shops might use tools from Atlassian or HP while Microsoft shops might use Team Foundation Server. The tools are mostly fungible across target technology stacks, but it is important to use a toolset to enforce SDLC quality gates and to automate manual tasks and tracking.

With assumptions out of the way, let’s drill down on the steps toward the empowerment of software development teams.

Organizing the Teams for Success by Keeping Tensions Healthy

In the three-part series, “Designing an Accountable Software Development Organization,” I discuss the principles of organizing a software development shop for success. The very nature of software development includes the tension between project requirements, the ability to translate those requirements into high-quality working code, and the governance to ensure that it’s done in an orderly and timely fashion. It is impossible to avoid these tensions, but it is possible to design an organization that acknowledges and harnesses the healthy tension while avoiding the tensions from becoming destructive. Put another way, the tension between requirements, technical delivery, and governance are necessary to producing great software. It is entirely up to managers and executives as to whether the tensions will remain healthy or turn toxic. Software developers will flock to healthy shops and flee toxic ones.

Supporting Decision-making by Maintaining Line-of-sight to the Business

All too often, business keeps its software development staff in the dark about key business strategies, goals, successes, and failures. At the same time, we expect our software development staff to make key decisions about software requirements and their implementation to drive business success. To use an old 1950’s B science fiction movie quip, “This does not compute.” In the article, “The Technology Executive and the Software Craftsman,” I discuss treating software development staff less as vendors who simply produce a product and more as partners who share a common desire for favorable business outcomes. The goal is to create a line-of-sight from the business to software development to enable better decision-making at the closest point of impact. This turns software staff from simple doers to thinker/doers who constantly weigh the needs of the business in their decision-making process. This is best summarized by L. David Marquet in Greatness. Creating line of sight and empowering decision-making at the closest point of effect will not merely provide incremental gains in team effectiveness, but will increase effectiveness multi-fold.

Aligning Intentions and Setting Expectations Between Management and Software Development Teams

In addition to the disconnect between business goals and software development, there can also be a disconnect between the senior executive team and software development staff. In the face of this lack of understanding, software developers sometimes fail to understand how and why decisions are made. In the article, “The Technologist’s Guide to the C-Suite,” I discuss the various roles at the executive table as well as what each role is concerned about and listens for. My intention is to foster an understanding on the part of the software development staff so that they will be more effective at synthesizing requirements stemming from and evangelizing solutions to senior executives. The end result is to create better collaboration that ultimately engenders trust.

Identifying Risks, Removing Obstacles, and Continuously Improving

Once we have a well-organized and well-informed software development team, we move onto the nitty-gritty of developing software. As mentioned in the introduction, software development management is transitioning from a traditional “command and control” style of tight control to a “servant leadership” style of team empowerment and removal of obstacles. With a well-functioning Agile software development team, the obstacles to success are frequently external to the software development effort itself that manifest as inefficiencies in the development of software. The obstacles may be related to requirements instability, churn on architectural design, unmanaged tensions between groups, or any number of other issues. In the article, “Better, Faster, Cheaper: Picking Three,” I discuss a model for managing risks to the timely delivery of software in Agile projects. The purpose of the delivery risk model is to identify obstacles to team efficiency as early as possible them work to mitigate those risks. When the delivery risk model is applied judiciously, the end result is higher quality code, more timely delivery, and less time spent fixing defects later, i.e., better, faster, and cheaper. The delivery risk model is an essential part of any servant leader’s toolkit. Without it, risks accumulate and snowball precluding the opportunity to head off problem while they are manageable. Further, the delivery risk model is a gateway to continuous improvement efforts where teams learn from and correct mistakes rather than get punished for making them.

Before concluding, there are some management caveats follows:

Management Traps

Sprint Micromanagement. Agile software development is by definition a highly iterative and self-correcting process. This works when teams are permitted to make mistakes, be honest and transparent with themselves and their management about issues, and work to correct those mistakes. A “command and control” mindset often drives managers and executives to micromanage Agile teams at the sprint level by holding teams strictly to burn down goals and punishing teams when they do not meet those goals. This is a grave mistake since it drives Agile teams to artificially pad estimates, limit transparency, and hide mistakes. Rather, I recommend setting interim delivery goals spaced throughout the project and have executives and managers hold teams accountable for those deliverables. The team should then be allowed to experiment and adjust their own processes within the sprints to improve velocity and quality without fear of punishment. Obviously, the teams need to deliver the agreed-upon functionality for the interim deliverables and may need to push harder to do so. But if the team is permitted to control the progress of sprint, they will usually willingly find a way to meet the interim deliverables.

Agile Dogmatism from Above. Agile methods are a fluid and changing set of guidelines stemming from the original manifesto. Agile software development is designed to adapt to the business and technical challenges at hand. In a strange twist of irony, I have encountered managers and executives who take a dogmatic approach to Agile methods and strive to impose strict doctrine around process and procedure. I recommend starting with a well-defined Agile process then listening to the teams about what’s working and what’s not. Experimentation and adaptation are at the heart of Agile, and the team should be allowed to make adjustments within reason. Depriving the team of this opportunity not only stabs at the heart of the spirit of Agile methods but disempowers Agile teams to influence their own destiny.

Agile Dogmatism from Below. Agile practitioners can sometimes be dogmatic as well. One of the  more persistent narratives I’ve heard says that Agile is not about committing to or hitting deadlines. My response continues to be, “Any software development methodology that cannot deliver on a predictable timeline does no good service to the business.” Another chestnut asserts that Agile is about producing software rather than documentation when, in fact, Agile values working software over documentation but does not preclude the need to produce documentation. As from above, there is a certain irony about dogmatism when applied to Agile by its practitioners.

Conclusions

Developing truly great software has never been easy. Software is among the most complex things produced by humans. Its complexity stems from the vast number of states that a software product can assume. In short, the “soft” is software assumes complexity and flexibility. Getting software right is as much a social engagement as a technical one. There are vast tomes and training materials about getting the technology right but woefully little guidance on addressing its social aspects. In this article, I have endeavored to highlight the social aspects of software development and provide a framework for getting best from the skillful and well-intentioned professionals who develop it. In the end as with any social endeavor, we get better results when people are fully engaged in a trusting, collaborative environment. Great software happens where talented people and great software development culture intersect, and that’s what empowerment is all about.

Best,

Charlie

Designing an Accountable Software Development Organization Part 3: Roles, Organization, and Culture

In part 2 of “Designing an Accountable Software Development Organization,” I discussed creating a vision for the software development organization that serves as the desired end-state. I explained that levers and tensions exist between the organizational components of the end-state model as well as how they could be harnessed to drive stakeholder behavior in healthy directions. In this third and final article. I will show how to align the roles and organization of a software development organization with the levers previously discussed. Finally, I will enumerate a set of behavioral guideline that help to keep healthy tensions healthy while avoiding unhealthy tensions.

Roles and Organization

As a software engineer by training and education, I have always believed in a pragmatic “form follows function” approach. With few exceptions, I’ve been fairly successful when applying it to organizational dynamics or software development organizations. My goal then is to define roles and align organizations along the natural lines of the levers I previously defined. This way, I assign authority and responsibility that is inherent within the vertical domains directly to directors and their organizations. This alignment encapsulates authority and responsibilities within the discrete organization and assigns leadership to a single director who manages his/her team, negotiates healthy tension-related issues with his/her peers, and provides me with a single point of contact to report on the status of the lever under their care.

In my software development organization, I have defined three key organizations: product management, technical delivery, and operations. The roles flow from the responsibilities and authorities defined earlier:

roles

I have made a few accommodations to a straight one-to-one alignment based upon the mission and skill sets. First, because my mission is to create a next generation product while maintaining and supporting the existing product, I have created two technical delivery teams. I found it prudent to ring-fence development staff within product domains to avoid having staff distracted by issues outside of their respective domain. For example, when I have had product teams intermingled, there was a temptation to divert key next generation product staff to solve knotty problems within current product domain. All too often, this proved a distraction to the mission of developing the newer product that I sought to avoid. Second, since the roles of risk tracking and process adherence are closely related without having inherent tensions between them, I collapsed both roles into an “Operations” domain and leverage the project managers in both roles.

Culture and Ethos

Now that we have defined the roles and organization along the lines of the levers, it’s time to turn to the management of tensions. The essence of developing great software lies with balancing the various forces at work within and between the organizational components. I have designed my organization such that healthy tensions bubble up to the director-level within each organizational role while minimizing the occurrence of overlapping unhealthy tensions. However, where there is tension, there is the opportunity for conflict. In keeping with my goals of engendering communication and trust, I have a simple set of rules for dealing with this that focuses on rules of engagement as well as encouraging professional maturity and development.

As described in the levers and tensions section, I make the responsibilities and authorities of each role explicit. I take a “carrot and stick” approach to describing the behaviors I expect and those that I wish to avoid. I set clear expectations for the directors as in the following example:

ethos1

Setting clear expectations about authority and responsibility boundaries is frequently reinforced within the organization. The directors understand this and set development goals for their staff accordingly.

When inevitable conflicts do occur, I prefer to set expectations for appropriate means of resolving them. At the risk of sounding “preachy”, our business partners and peers expect and deserve to be engaged in a respectful and dignified manner even when disagreements arise. If a software development organization is to communicate effectively and engender trust, I believe that a high level of personal integrity must be maintained in interpersonal relationships. If we don’t behave appropriately, then we have little right to expect trust and respect in return. We have all seen recent reports where a major automobile manufacturer was caught cheating on emissions tests after marketing their engines as clean. This was a clear example of where a technical delivery organization broke the trust with their consumers by acting with low integrity. Consumers are correct to no longer trust their claims.

I provide a simple set of guidelines for engaging staff, peers, and their managers. I again mention behaviors I expect that those I wish to avoid:

ethos2

I think most of these speak for themselves. I would like to comment on “taking the high road” a bit further. There are political issues and rivalries in any organization. Frequently, it is easy to take the approach of “fighting fire with fire.” I reject this approach for the simple reason that while such an approach might be emotionally satisfying, it will almost inevitably lead to regrets. Regret, whether in personal or professional affairs can be emotionally corrosive and ultimately self-defeating. I try to avoid situations leading to regret whenever possible.

Getting Results

So what results can you expect from a truly accountable software development organization? In my most recent experience, the software development teams saw positive quantitative and qualitative results over a three-year period. The teams’ on-time delivery went from hitting the mark less than 60% of the time to achieving on-time delivery over 90% of the time. The software quality as measured by post-delivery fixes increased by over 75%. While we applied the Agile Scrum methodology to an inherently risk-averse business domain, we have consistently passed client audits with only minor findings.

Qualitatively, our business partners report that they are more consistently satisfied with the software solution. This increased satisfaction has led to increased confidence in the software development organization. The software organization itself has developed a new confidence and sense of satisfaction knowing that they deliver high-quality solutions when the business needs them.

My experience is limited to software development and infrastructure technologies and I have applied the above techniques within those domains. However, the principles of empowerment and alignment should apply to any business domain. I would love to hear back from those who try their hand at the application of these principles!

Best, Charlie

The Technology Executive and the Software Craftsman

keep-calm-and-collaborate-for-great-software

Back in the Day

As a technology executive, I’ve been around software development for over three decades. Those who entered the development workforce as developers in the 1980’s as I did were typically educated as and thought of ourselves as software engineers. We were taught structured methodologies of the day based upon the writings of notables like Yourdon, Ward, and Mellor. We were drilled in development techniques including data hiding and encapsulation focusing on the disciplined used of data structures and algorithms with the aim of making our software more flexible and maintainable. The development tools of the day consisted of compilers, assemblers, linkers, and loaders and little else. Often, we were not only developing software but we were simultaneously developing better tools to help us develop that software. Simply put, we were not only developing software products but were also developing the tools to fill the gaps in the tool sets of the time. In spite of these hindrances, we managed to produce fairly robust code.

Using these methods and tools, we were often employed in medium to large scale projects using traditional waterfall project models which valued rigorous documentation to communicate requirements, design, architecture, code structure, and test cases. Those of us who worked on military projects were exposed to such software development standards as DOD-STD-1679A and DOD-STD-2167. I was involved in military, medical, and financial software projects. In spite of our best intentions to “engineer” software following the models and standards of the day, many projects were delivered late, only partially met the requirements, and were fairly bug-laden. As software engineers, we intuitively knew that something was fundamentally flawed with our methods and that developing great software was more iterative than we were taught. However we often felt at a loss to know how to change things. We knew that close collaboration with our clients and subject matter experts often yielded better results since we could better understand user needs through such collaboration, but the waterfall process created barriers to collaboration in deference to formal documentation and methods.

A New Breed

In the intervening years, I have seen development tools mature to a point where they enable better productivity through means of integrated visual IDEs, real-time code analysis, and automated unit testing tools. The tools not only enable developers to manipulate code and resources better but often do tedious tasks automatically and offer helpful guidance to produce better code. In fact, many recent tools support the ongoing refactoring of code to ensure quality and maintainability as the features and functions of the software evolve over time. This helps reduce the entropy that often seeps into software products making them bloated and unwieldy to maintain over time. In short, the tools have evolved to not only reduce the friction between developer and code but have become an ally in producing high quality code faster. In addition, more iterative development methodologies arose as development teams realized that tight collaboration with the customer was a key project success factor. Today, the various flavors of Agile (with a capital “A”) development are the de facto standards for most software development since it acknowledges the inherently iterative process needed to develop great products that are better suited to the business needs.

As the development tools have reduced the friction between developer and their code and Agile development methodologies brought developer and customer into tighter collaboration, I have seen a change in the ethos of developers. Under the guidance of technical experts and mentors like Robert Martin (aka Uncle Bob) and others, developers are trained, or maybe more accurately indoctrinated, in a new way of thinking about software development which focuses on the delivery of well-crafted, high-quality code. This goes well beyond traditional training in techniques and methodologies to a level of almost Zen-like devotion to fitness and quality. Having read some of the materials by modern day software gurus like Uncle Bob, I have found a theme where some developers see technology executives as a hindrance to the crafting of great software. This is almost a “we’ll build great software in spite of the obstacles placed before us by our managers” feel to the discourse. Developers are now challenging and entreating the business to support them in building the best products possible because they care about their craft to which they put their name! This new breed refers to themselves as “software craftsman” and with good reason. As craftsman, they understand that software is only partially engineered. They understand that truly great software development is an organic mix of close collaboration with their customers to guide the application of the technology and tools. In short, this is what many developers from “back in the day” intuitively understood but could not instantiate into real solutions for software development shortcomings of the day. It has been and continues to be my privilege to work with these craftsmen. I find myself in admiration of their dedication as I reflect on the earlier days of software development.

Vendors versus Partners

So as the developer ethos has changed and evolved into that of the software craftsman, the mindset of the technology executive must also evolve to better leverage the ethos and skills of their software craftsmen. A former executive colleague had a saying, “Squeeze a Vendor, Hug a Partner.” All too often, technology executives see their development staff almost as vendors whom they engage to produce a product. I must say that I have been guilty of the same outlook. Treating developers like vendors often means that developers are given the requirements and access to subject matter experts and then set loose to come up with a solution. The technology executive then monitors progress and squeezes the vendor to deliver the product as efficiently as possible. In short, “squeezing” vendor relationships often lack trust and that shows through to the software development “vendor.” All too often, the technology executive is left disappointed as the solution falls short in features, quality, or delivery timelines. Based upon my own experience, there were two simple reasons for this. First, the technology executive was squeezing the development staff to hit a timeline without arming the development staff to make the right tradeoffs needed to deliver quality software. Second, the developers did not understand the full context of the solution they were asked to develop including such things as market forces at work, sale pipeline pressures, the competitive landscape, and any other number of factors influencing the making of good business decisions. Like a vendor, they were only told as much as the technology executive thought they needed to know. Based upon the information available, the developers did the best they could.

Now let’s contrast this to a partner relationship. Partnerships are based upon the alignment of intentions and motivations between parties. Partners share the full vision of the goals to be attained with the hope that they can arrive at mutually beneficial solutions. Partnerships are based upon trust that each party has the others back and that success will be achieved through the mutual nurturing of the partnership. Partnerships aspire to add value to both parties in a “rising tide lifts all boats” ethic. Partner relationships are for the long term while vendor relationships last for the duration of the product delivery.

Believe it or not, technology executives and software craftsmen share the same intentions. They both want the best product possible, they both care deeply about the fitness of the solution to meet the customer need, they both want a sustainable high quality outcome, and they both want to avoid putting their name on a poor outcome. In short, when the technology executive and software craftsman come together as partners, they find that they want the same thing!

A Call to Action

So how can a better partnerships between technology executives and software craftsmen be forged? It’s really quite simple and can be explained in two words: Communication and Trust.

The technology executive needs to arm the software craftsman with the information required to make the best decisions possible based upon the true business need. Simply communicating requirements is insufficient. The technology executive needs to engage the software craftsman in a continuous and ongoing dialog about the business including a transparent discussion of the opportunities and challenges facing the business. I think you will find that the your software craftsman will eagerly absorb and digest this information and use it to design and develop better solutions that transcend the boundaries of the requirements to make their solutions more fit for a broader business scope. I hold periodic meetings, usually over lunch, where I brief the senior technical staff on the state of the business and how their solutions fit in. We have spirited discussions and action items resulting in improved development methodologies, tooling, and product features to help achieve superior results. This has been like a bit like letting the genie out of the bottle. With a little effort and trust, software craftsman can produce magical results!

The software craftsmen need to make their executive partners understand that they care deeply for their craft and demonstrate that they are aligned with the goals of the business. The technical staff needs to understand that it’s healthy to challenge the business and bring executives to the notion that it is not only a good idea to include the technical staff in the business dialog but it’s essential to the development of the best possible products!

Only through a true partnership between executive and craftsman can superior results be achieved. As a result you’ll get side benefits in return: a new sense of trust and satisfaction. Aren’t those at the heart of what both technology executives and software craftsmen desire?