Creating software is an act of aggression, or at least it can feel that way at times. If you have been building software for any length of time, you’ve probably experienced this phenomenon. There are disparate teams with their own goals, agendas, stakeholders, requirements, deadlines and project trackers and each team is out to accomplish its own goals in its own way. Rather than working toward a common goal, each team powers forward on their own, making design and implementation decisions that impact the entire project without regard for the other project teams. Each team fights some battles and either gain or lose some ground. In the end, everyone suffers and the underlying problem may or may not be solved.

This isn’t a new problem, and no, this isn’t another acronym-laden recipe for instant success – there are plenty of those out in the wild for better or for worse. Formal rules and methodologies can be beneficial, but only if you get buy-in from the entire organization and from each individual project team. Processes are only useful if every single project team and their respective leads are willing to participate. Rather, what we need is a more informal approach to working together, not a prescribed process or methodology, but rather a baseline behavioral agreement about how our different teams will interact with one another to ensure mutual success. It’s not a formula, but rather a PACT.

I Smell an Acronym

I said there wouldn’t be acronyms; I was wrong about that, but in all honesty this one is accidental. Earlier in the year I gave a presentation to the development team at Method on how I was managing one of our Enterprise projects. While the presentation was mostly focused on a specific method of tracking everything I possibly could in regard to the project, I outlined some of the general principles behind my philosophy of running large-scale projects. There were four main tenets and, although I had them out of order, our Director of Engineering saw the hidden acronym and called it out during the presentation. Just by accident, PACT happened to be perfect, not just because the letters fit, but because it’s exactly what I was trying to convey to the team. Building great software requires an agreement between all parties to behave in a certain way and to follow a common set of guidelines.

Guiding Principles

So what are the principles of our PACT? Well, unsurprisingly the first one is a “P” word, and not just any, but one of the dirtiest of “P” words in the age of Agile: Preparation. That’s right, I’m suggesting that teams must be prepared to be successful. It’s a concept that elicits groans from every under-40 developer and project manager. You’ve probably already had a mental image of a giant waterfall and months of gantt chart creation and stakeholder meetings. That’s not the kind of preparation I’m talking about; we’ll dig into that more in a bit. Next is “Adaptation”, which hopefully makes you feel a lot better about how this started. However, I don’t mean Adaptation as in being Agile and building iterative releases, but rather as in being flexible and accommodating to your team members and external teams. Next is “Communication” which is a critical and alarmingly absent concept in most of the Official-Methods-for-Doing-Things-Well. Lastly we have “Trust”, which totally blows the nice flow of “-ation” words, but in my opinion is the most important part of the PACT. Unfortunately TPAC isn’t a real word and it sounds more like the name of a rapper or a series of antibiotics you take after a weekend of poor decisions in Las Vegas while on vacation with your friends. Where is this going again? Oh yeah, successful project principles, let’s dive into that a bit more.

Preparation

Again, stay with me here, I’m not proposing that we spend three months outlining every detail of how your project is going to run. Remember, we’re not trying to define how projects will run per say, but rather how we, as functional units of an organization, will work together to accomplish a common goal.

“A goal without a plan is just a wish.” ― Antoine de Saint-Exupéry

Preparation doesn’t necessarily mean creating a giant, cascading waterfall of documentation, stories, diagrams and milestones. Preparation is also ensuring we have the information, tools and mindset to succeed. Preparation in the context of our PACT is much higher-level than the project specifics. Our preparation begins with ensuring that we have a clear set of goals in mind and that they are clearly communicated to our teams. It also means that we have to form our teams with our objectives in mind. We then have to make sure those teams are empowered to succeed, that they have the necessary resources to accomplish their goals, that we have the necessary tooling, licenses, software and that our teams are empowered to make decisions that directly impact their project goals.

Imagine you’re sending a few employees off to a trade show event. You rent a booth, send giveaways and marketing materials along and ship your displays ahead of time – everything seems to be in order. But as it turns out, no one took care of travel arrangements, your employees aren’t allowed to use the company credit card to book rooms or flights and every hotel is booked solid for the entire week of the event. No one who plans events would take this approach because without your team, your booth and displays are worthless. It’s amazing, but this is how thousands of software development projects start every year. Teams don’t have the ability to provision server resources, they can’t authorize software purchases, or worse they can’t even decide what resources they want to use. This approach to running projects breaks every principle of our PACT. You have to prepare to succeed. When you find you need resources you need to be able to adapt quickly. When blockers are found they have to be communicated and you have to trust your team members to make the right decisions given their goals. All of this is rooted in preparation – you have to plan to succeed and empower your teams to meet your collective goals.

Preparation isn’t a bad word, it’s just gotten a bad reputation in the software community. No project will succeed without some up-front planning and preparation. However, planning shouldn’t be focused on the minutiae of the project details, but rather on enabling the team to succeed.

Adaptation

There are some great quotes out there about how plans and preparation are fine until you get into the real world, but I believe that one of the true sages of our generation put it best:

“Everyone has a plan ’till they get punched in the mouth.” – Mike Tyson

No one should live their lives based on the Philosophy of Mike Tyson, nonetheless it’s a solid quote and perfectly illustrates the type of Adaptation that we need in our PACT. Still, Tyson leaves a bad (bloody?) taste in my mouth, so let’s try something a bit more highbrow:

“No matter what the work you are doing, be always ready to drop it. And plan it, so as to be able to leave it.” – Leo Tolstoy

That’s better. It’s a bit more wordy, but again a perfect way to put the “Preparation” part of the PACT into context with the type of “Adaptation” that we’re talking about. Adaptation is intrinsic to running a successful software project and it’s absence has been the pitfall of methodologies that have been in place for decades. Unless you’re building very small, very focused products, the likelihood of requirements, environments and conditions to change is inevitable. Teams have to be able to adapt to changing scenarios quickly and with minimal impact on external teams, deadlines and other interests.

Adaptable != Agile

Before we go too far down the path of Adaptability, let’s clarify that this isn’t necessarily synonymous with “agility” or the Agile Methodology. Of course running an agile project is desirable and often offers a clearer pathway to success than the alternatives, but adaptability in the context of our PACT is a bit different. Rather than being a prescribed formula with Planning Sessions, Grooming Sessions, Standups, Scrums, etc. it’s a behavioral pattern that team members need to adopt. Adaptability is being willing to circumvent processes or change your scope (within reason) without making an enormous fuss. Adaptability is being willing to play a different role or stepping in to help a team that’s shorthanded for a week. Adaptability is being willing to change your API contract because of a last-minute use-case that arose. Adaptability means being willing to bend, break or change any or all of the rules when the need arises.

In the context of our PACT, being Adaptable means being a good team player and not a stickler for detail. Sometimes you have to get a few people together in a room and hack through a solution, or get with the QA team and work together to get a story over the final hump to completion. That said, being adaptable doesn’t mean you have to be a pushover and make terrible decisions just to get something out the door. Adaptability works hand-in-hand with communication and trust – you don’t want to erode the trust that exists in or between teams by constantly making compromises that lead to a lower-quality product. If being adaptable starts to spiral into the pit of workarounds it’s time to communicate your concerns and get your team(s) back on track.

Communication

“Bad news doesn’t improve with age.” – Shannon Hager, Method Engineer

I didn’t have to reach out too far to find a great quote for the all-important principle of Communication. Right before that presentation I gave to our team at Method, one of my team members said this to me over Slack in regard to our current project. It immediately became a slide in my presentation because the quote is so poignant and perfectly illustrates the reason why communication is so critical. Regardless of the politics of your organization, how you feel information will be received or how it makes such-and-such a person look in the eyes of others, our job is to communicate to our teammates, project stakeholders and leadership as soon as information important to the success of the project is available.

There are many types of communication that are important to a project. We have to share as much as possible. Tools like Slack, HipChat, Google Hangouts or other messaging and/or video conferencing systems are indispensable, particularly in geographically diverse teams. However we first have to create an environment or culture in which communication is unencumbered by politics and formality and in which all parties participate, including leadership teams. Communication barriers are one of the biggest inhibitors of success – I’ve seen it time and time again and it’s maddening. Unless every team member feels empowered to communicate critical information to any other team member, regardless of position or hierarchy, information critical to the decision making process may not be available.

Communicating Without Fear

Communication in the context of our PACT could be an entire blog post; it is so essential to the success of any project that you could likely begin and end a book on “Principles of a Successful Software Project” and do nothing but talk about communication. Within that book, there could be an entire chapter dedicated to the last sentence of the above paragraph. Let’s look at that again in case you skimmed the last section:

Unless every team member feels empowered to communicate critical information to any other team member, regardless of position or hierarchy, information critical to the decision making process may not be available. – Me, right up there above this blockquote

Leadership cannot make decisions without information. Let me say that again in a different way: If you hide things from the boss, your project is likely to suffer and it will be your team’s fault, and more accurately, your fault. That sounds over-the-top, but it’s true and bewilderingly enough, organizations structure themselves in a way that makes it very likely that bad news will be hidden from the very people whose job it is to mitigate trouble scenarios. Creating an environment where leadership insulates itself from the day-to-day often means that leadership is protecting itself from anything that can be perceived as negative. As a result, leadership is limiting its ability to be successful. More specifically, leadership teams make a conscious decision to fail by being blind to or even perpetuating a culture of fear within their organization.

Creating an environment in which team members feel empowered to communicate directly with stakeholders, and in which communicating information that could be perceived as negative is celebrated would do more to boost the success rate of software projects than any other single act. Leaders need information to succeed. Good leaders solve problems and turn challenges into successes. The very best leaders aren’t offended by people pointing out problems, but rather recognize the value of that information. Without having all of the information available, leadership is unable to do the precise job that they are tasked with doing. Imagine a navigator not telling a ship’s captain about an approaching storm – it would be unthinkable, yet we do precisely that every day in the corporate workplace.

Contextual Channels

Think of all of the various types of communication that are important to the success of a project: requirements, priority, implementation details, deadlines, expectations, demos, deployments, planned and unplanned outages or downtime, defects, effort estimates, employee schedules, etc. It’s easy for information to get lost in the shuffle. It’s important to provide appropriate channels for different classifications of information. Again, tools like Slack, HipChat and other messaging systems make this easy, but we have to think of our traditional project tools as vehicles for communication as well. Implementation details, diagrams and flow-charts need to live in a Wiki. Requirements, estimates and defects need to be in a tracking system. Employee PTO and vacation time should be tracked in a way that facilitates Sprint planning. Communication is absolutely essential to our project, making sure we facilitate communications in contextually relevant ways is one of the things we should consider as part of our “Preparation”. Team members shouldn’t fight against these tools, but rather see them as avenues in which information travels.

Trust

“The best way to find out if you can trust somebody is to trust them.” – Ernest Hemingway

There is no better explanation of how “Trust” should work within your team than in that quote from Mr. Hemingway. Trust should be implicit. That old adage, “you have to earn my trust” is just awful, and we have all likely had more than one manager or project leader start projects with that type of skepticism. In truth, you rarely earn or value the trust of that manager because they began the process by doubting you and created an adversarial condition from the start. If you want to build cohesive, gelled teams in which the members have mutual respect for one another, you should’t start out expecting to be let down.

Trust is an underlying current throughout our PACT. In fact, you may have noticed that each principle requires the others in order to work smoothly. You can’t have an open communication channel between stakeholders, team members, project leaders and all other team members unless you trust one another to communicate frequently, honestly and with some measure of tact. Likewise, you can’t prepare to achieve goals if you can’t trust the information you’re working with. Trust is intrinsic in our PACT because it’s the foundation on which every principle is built.

When trust begins to erode, and it will happen from time to time, it’s indicative of a breakdown in communication. Only in rare cases does an individual or a team have an ulterior motive or a desire to work against the project goals. If you start to feel that a team cannot be trusted, you have to communicate that concern and work on ways to mitigate the problem. Again, this is where it’s helpful to have an open line of communication to leadership. Resolving problems and mitigating cross-team problems is a function of management, but they can’t do that if they don’t know a problem exists or that trust has begun to erode.

But We’re an Agile Shop

Don’t worry, you can still use your Capital-Letter-Methodology-of-Choice, no one is suggesting that you change your process for managing the day-to-day tasks of running a project. That is, of course, unless you’re using Waterfall. In that case we are suggesting you change because nothing ever works out the way you plan. Again though, our PACT is not a methodology for running a project. It’s not a substitute for Scrum, Kanban, Extreme Programming (XP) or other Agile methods.

If Agile and other methodologies were military strategies, PACT would be the Geneva Conventions. Rather than being a way to attack a problem, they are behavioral guidelines by which we all mutually agree to abide.

What Do We Do Next?

Avengers Assemble! Get your team(s) together and discuss the PACT. Agree to succeed, to trust one another and to communicate effectively across all available channels. Make a commitment to one another to be adaptable and to work closely together to ensure that you achieve your collective goals. Make a commitment to leadership to share information regardless of the consequences and get assurances from them that there is nothing to fear from communicating important information. Finally, share your PACT with every new team member, contractor and third party that interacts with your team. Let everyone know that your collective goals are more important than your process and your hierarchy and let them know that they already have your trust – it doesn’t have to be earned.