Release Cadence: You’re Not Agile If You’re Not Shipping

I’ve spent the last 3 years exploring the in’s and out’s of different Agile frameworks and methodologies.  I’ve worked with large commercial firms, government contractors, and small ISVs to adopt one set of Agile practices or another.

In the beginning things are generally amazing.  There’s a new level of transparency, excitement and shared motivation.  At some point, though, the question always comes up: Are we ready to ship?

This is the moment where organizations either head down the Scrum-erfall path or learn what Agile was meant to be:

…satisfy the customer
through early and continuous delivery
of valuable software.

The Path to Scrum-erfall

Unfortunately, too many organizations have taken hold of the rules and ceremonies of Kanban, Scrum, XP, and the rest, but ignore these two principles:

  • Working software is the primary measure of progress.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a
    preference to the shorter timescale.

Does Shipping Heal All Wounds?

On March 4th, I opened what I hope will replace the State of Agile report: Release Cadence Report.

logo-verticalThis survey and publication was created to refocus our industries attention back on shipping software frequently to the delight and benefit of our customers, team members, and companies.  It is an attempt to relieve our software developers of ineffective anecdotal stories of Facebook and Flickr shipping dozens of times per day.  Instead I want you to have the evidence to take to leaders in your organization so that you can have a serious conversation about the implications of release cadence.

Please take 10 minutes and complete this survey and you will receive an early copy of the report.

Take the Survey

You can also get yourself or your organization listed as being part of this movement by referring your coworkers, peers, friend.  Sign up here and be a part of bringing shipping back to Agile.

Adaptive Problems Require Responding to Change Over Following a Plan

Feedback was recently posed on the community forums regarding the Webster-ish definition provided for Scrum by Ken and Jeff.  If you don’t recall from the Scrum Guide, the Scrum Overview definition reads:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Mario Čop, in his feedback, suggests problems cannot be adaptive.  He provides some definitions of his own to remove the subjective influences around the words “adapt”, “adaptive” and “problem.”  In the end, Mario says:

I’d say that the process of solving problems can be adaptive. When solving problems you can have adaptive approach and adaptive execution of it, but it makes no sense saying that problems itself are adaptive.

Whether successfully conveyed or not, the intent is that complex problems are not always clearly understood.  As we approach and attempt to solve a complex problem, our understanding of that problem becomes clearer.  What this means is that as we examine a problem, our understanding of it adapts.  In this way we must reevaluate both the problem and the solution.  Continuous planning allows for this dynamic where a plan alone constrains learning.

Scrum’s Sprint, as I’ve said before, provides a balance between space for creative problem solving and focused decision making.  The outcome of a sprint allows us to reevaluate our understanding of the problem space and whether we are taking the product and organization in the appropriate direction.  Here we see how we can utilize the Scrum framework to embody the Agile value of Responding to change over following a plan.

Scrum Fundamentals Recording Available

Leading up to an open enrollment Professional Scrum Foundations on October 10th, I gave a 1 hour lunch webinar on the fundamentals of Agile and Scrum.  I’ve just published this out on Youtube for anyone to watch.  Let me know what you think.




There is a lot of misinformation out there that comes with a strong movement like Agile. It’s been coopted by some, but the vast majority see these opportunities as a way to make sure the 8 hours they spend away from their families is spent wisely. That’s where I fit in.

With that in mind, I believe very much that Scrum, like many things, can be used for both good and bad.  When used well, it provides a safe zone for sustainable, creative teamwork.  When used poorly, it sucks as bad if not worse than waterfall/ad-hoc.

I don’t teach Scrum such that teams go back and simply use it to manage work.  Many don’t get beyond that, but in my courses, webinars, and conversations we talk about the human factors, theory, and sustainable practices that make Scrum work.  This is the legacy I want Deming, Scrum, Agility, and others to be remembered by.  Not velocity and commitment.

Passive Aggressive Commit Messages

If anyone tries to tell you Twitter is a waste of time, they have the wrong circle of followers.  Today I posted this gist somewhat facetiously asking if the following was an acceptable commit message.

Refactoring done earlier didn’t execute acceptance tests. This makes me wonder why we even have acceptance tests. The acceptance tests (and the bug they surfaced) are fixed. Ugh. Professionalism people. Please.

imageI say somewhat facetiously, because I actually copied it out of my almost submitted commit command. I was really close to sending it and that would have probably been the end of it.  It’s unlikely anyone would have noticed it, especially the person I was directing this passive aggressive comment towards.

Follow My Own Advice

I’ve blogged recently about recognizing signals (here and here).  Obviously, I’m not following my own advice.  I need to go and find out why this person doesn’t care about the acceptance tests and either convince them they are important or find a better way.

Uncomfortable Part

Rather than be passive aggressive in silence, I need to have the discussion.  It’s not going to be comfortable, but I have something we can both agree on: we both want this to be successful.  If we can keep the conversation focused on the success of this project, we can find an understanding.  If I use the same tone in our conversation that I’m using in this commit message, well, it’s not going to go well.

Fortunately, I wear big boy pants (when I go to the office) and I’m willing to get over a little uneasiness for the sake of my creation.  Do it a few times and it gets much easier.

Simple Solution

It turns out this was able to exist in our codebase for a few days, because we aren’t running our acceptance tests as part of the build. I plan to remedy that tomorrow.

Beyond the Agile Programmer: Innovative Teams

This past week, I had the opportunity to attend the Midwest UX conference in Columbus, Ohio. I was incredibly happy to see AIS sponsor the event. While we work hand-in-hand with some great design teams for projects like the Vogue Archive and Rolling Stone Archive, getting directly involved in the UX/UI community is part of our attempt to bring this knowledge and experience in-house. (More on that to come!)

Choosing sessions at a conference is rarely easy, but I knew immediately which session would start my day. Without any hesitation, I headed for Building a Design Culture by Brad Colbow, the awesome Illustrator and comic. Brad presented at CodeMash earlier in the year and he easily lived up to my expectations.

In this session, Brad described his experiences as a designer engaged to build a great user experience in the context of a broader team.  I was interested to see how Brad’s thoughts and experiences as a representative of the design community overlapped with those of the Agile community which has composed mostly of programmers.  I wasn’t disappointed.

The Execution Gap

Maybe it’s the lack of even a single artistic bone in my body, but the word design suggests innovation; the creation of something new and exciting. Having personally worked with some amazing software designers and design firms, I relish the anticipation that comes with endless possibility and unbridled imagination.

I’ve also experienced the drudgery of endless implementation, sheen-dulling corner cutting and pride-killing Who Moved My Cheese reviews. After months of hard work, the excitement of the filled a kickoff gathering has given way to finger pointing and, at times, ship jumping.

It would seem that the challenge is not innovative ideas, but the execution of those ideas. 

Execution is everything. ~ Robert Jordan

Brad is quite well known and respected for his design and artistic talents. No doubt he brings a lot to the table for a team or organization looking to bring a great experience to products.  For this reason I find it quite telling (and entertaining) when he describes the engagement process like so:


While Brad and his team may hand over pure gold, without his skill and eye on the in-flight product, the result is often a not-so-happy rendition. The gap, he points out, is engagement with those executing his designs in the medium of code.  No doubt customers have a similar response when their ideas don’t quite live up to the gloss of a SOWs or project proposal.

But how can we avoid such a letdown? How can we avoid the deterioration of our vision over time?

How does Scrum enable a culture of Innovation?

Scrum Teams are Cross Functional

Brad was quite open and honest in saying he does not have the answer. Instead, he shared his experiences. He’s found that the interests and practices of those championing Agile in these same organizations are in alignment with his own.

In Scrum, we explicitly call out the need for a cross-functional team. Scrum’s “Development Team consists of professionals who do the work of delivering a potentially
releasable Increment of ‘Done’ product at the end of each Sprint.” (Read more) This is often in contrast to organizational structures based on skillset.

Scrum Sprints are a Safety Zone

In his 2005 A Survey of Organizational Creativity, Wayne Morris of New Zealand found that two of the top three Factors that facilitate or enhance organizational creativity are 1) Time, and 2) Space/resources to pursue ideas. Creativity, a necessary ingredient to innovation, demands space. Space to experiment, learn, fail, and refine. Space in time, environment, and pressure.

Scrum maintains the Sprint to act as both as risk mitigation and a safe zone for creativity. Within this timebox the Development Team has full freedom and authority to attack a problem or goal with all its ingenuity knowing that at the end of the Sprint they must have a working product to demonstrate. Interesting that this simple concept can provide safe space, while also limiting the months of unproductive spin seen on traditional projects.

Create Your Culture of Innovative

By providing clear goals to teams composed of the skills necessary to bring a product to market, providing sufficient space to execute, and inspecting the actual, functioning results at regular intervals we can build a culture of sustained delivery and innovation.

What would happen at your organization if you put together a team with Marketing, Programmer, Designer, and Sales all represented, and gave them a goal of delivering a working increment of software in 30 days which solved a profitable need? It’s quite possible in fact.