Delivery Principles: An Exercise in Shaping an Agile Methodology

Within our organization, the journey toward agility spans over 15 years. We've been teaching, practicing and modifying our approach over time as we scaled from a small independent development shop to a 500-person strong group of software solution consultants. With all things related to scaling an organization, there are challenges. Maintaining the mindset of agile software development is no exception.

In recent years, we've expanded to have multiple offices across the country and abroad. We believe it is essential to begin by staffing these new offices with a few current employees to cultivate our culture in the new space with new team members. Cultural osmosis from our veterans had been better than documentation at instilling the appropriate mindset within new team members. As the office grows, we know it will take on a life of its own with traditions and customs, but to work together effectively at scale, we can't rely on osmosis to teach and reinforce the things that made us successful in the past.

Necessity meets innovation

To demonstrate how the osmosis started, here's how our agility journey began:

1. Consultant meets customer.
2. Consultant is awarded a contract, and the team members develop the solution in isolation from each other.
3. Consultant's team finally integrates the code pieces, preparing for the final deployment.
4. Consultant is at a loss when it doesn't work as expected.
5. Consultant spends the next two months working on fixing the mistakes that could have been avoided by continuous integration and deployment.

After this incident and our gained experience in failing (the best teacher), our leadership began to explore the concepts and principles of continuous delivery. The very same customer referenced above worked with us on an additional project in the following months, and we adjusted to a more frequent delivery model with small changes and regular demos of working software. We began to see the value of delivering early and often.

Culture begins to shift

The transition to "early and often" for delivery was a significant culture shift. Some of our cultural parsing problems were around test-driven development (TDD), which is relatively easy to explain but hard to implement. Not all tests exercise the most important pieces of an application as expected. Being able to tell what's important before code gets written is challenging. 

Our teams understood the process conceptually but lacked a shared ethos. We needed help with our mindset and practice of TDD and ended up supporting a training course that we then taught to all our developers. We still regularly hold this class today, and it hasn't changed much in the past 15 years.

Years after, paired programming became the norm, and we began to adopt more and more agile-leaning activities like Kanban and aggressive release cadences. However, our teams often implemented the new practices in isolation, and team members would later switch to a different project with completely different norms. It began to cause friction with our veterans who looked at their unique experience as "the way it was supposed to be."

Recognition of a different approach

With significant variability in our projects, it was challenging to come up with a set of core ideas that should (and could) dictate the way we work based on what we value. Given that difficulty, we would point to what was already written down (agile principles) and leave much of the details open to interpretation. Our growth continued, and we were close to a breaking point – there was no clear path to describe how we communicated with our customers and how we communicated with each other. 

How we communicate: The customer interface

The first challenge we decided to tackle was a consistent way of communicating with our customers, which we called the "Customer Interface." We knew that we had difficulties communicating progress and risks on our projects to our stakeholders, so we began to define the output and cadences required to keep our delivery from being unpredictable or too aggressive for our customers' tastes. Our objective was to state expectations for customer communication ("the what") and allow the team to handle satisfying the criteria ("the how"). This approach was a significant step toward thoughtful rigor – flexible yet consistent. 

How we deliver: The delivery principles

Within the agile principles, there are several assumptions made that are implicit. A few that go unstated: co-located teams, IT/stakeholders working for the same company and a shared set of defined norms to work within. Without those luxuries, the rules change ever-so-slightly. We've been able to experience those changes under a wide range of constraints and situations. 

Our delivery principles have taken the agile principles and shaped them into something that works well with our business model. Creating these modified principles was not easy. It took approximately one thousand hours over 18 months for an interdisciplinary team to craft. 

As we translated the agile principles to delivery principles, some changes we made were:

• Face-to-face communication replaced with the "right" communication: While still very valuable, face-to-face communication just wasn't as critical compared to the "right" form of communication (depending on context). We provide ways to identify what the right way is, and how often it's happening. This clarity was incredibly important for our distributed teams and stakeholders.
• Technical excellence facilitates a successful handoff: Technical excellence does enhance agility, but it also aids in the long-term maintainability of a project after those that made it (us) hand it off to someone else (our customers).
• Prioritizing healthy teamwork: Leadership support of self-organizing teams being a given, we've chosen to focus on the idea that the best outcomes are produced through healthy teamwork and all the ways that can be encouraged.

Accountability to the framework

We knew that no single person could be able to objectively evaluate our teams in a way that was fair and consistent. Instead, we let the team members do this themselves with a "delivery check." Our team members evaluate their team's performance relative to our delivery principles, and the results are discussed and facilitated by an agile coach to uncover ways to improve the way they work together. 

The team's ratings and results are shared with leadership to provide awareness on how well our teams are functioning. These results may trigger auxiliary support in the form of additional staff, specialized help/skills, team composition analysis and other assistance. We pay attention to changes in those delivery checks over time as an indicator of improvement.

Reality check

This program was not easy to implement. Our delivery principles took approximately two years to polish into a well-oiled and understood process that we still iterate on today. Different voices and diverse perspectives of our teams and roles were instrumental in producing what is challenging to write down: this is what "good" looks like for all of us. 

With varied teams and different outcomes, defining what "good" means is very challenging. While it may be tempting to rally around one metric to identify team success, story count or burn-up charts would not suffice. We have not forgotten Goodhart's Law. To ensure that each team had the support it required, they needed the autonomy to know when to ask for help and how to ask for it.

Coming soon: A deeper dive

There's more to share about the changes we made and why we made them, and we're excited to share the process that we went through. Stay tuned for more information on the customer interface and delivery principles by following our Application Development topic area.