Post Agile Companies

Post Agile. I first heard the term several weeks ago in Chicago. It was used to define companies who had started up from 2005 onward. Companies who had been versed in the Agile Manifesto, who understood Lean Principles, to whom agile was second nature. These are companies doing Scrum – Daily Standups, Product Backlogs, Scrum of Scrums. They are doing XP – Pairing stations, Test-Driven Development, Onsite customer. They have acceptance tests and weekly deploys. They have a fancy wall, or a fancy tool, and it shows all of their stories.

Over the past several weeks I’ve talked to several organizations who fit into the “post-agile” world. From the outside, they have all the appearances of “getting it”. I’ve seen Behaviour-Driven Development and iMacs. I’ve seen pairing stations, bright open workspaces, and index cards galore. And you would think after seeing all of that, I’d be overjoyed at the state of agile! It’s made it! It’s crossed the chasm!

Yet, after each organization I worked with, or talked to, I left a little more depressed. Sure, these were interesting places. Sure they were wildly successful. But the more I talked with them, the more I could see train wrecks waiting to happen – paths being taken that were only going to lead to long nights, crappy deploys, and the loss of the very thing that is making them leaders – agility.

Company A – High Cholestorol Will Kill You

The first company worth noting has all of the appearances of agility. The developers work in a big open workspace. The organization has adopted Scrum, and has Scrum of Scrums. They do weekly releases. All the developers have 27″ iMacs. In the past couple of years, they’ve grown beyond their wildest expectations. But the more I talked with their developers, their staff and their CTO, the more I couldn’t help but think of the arteries of the body when you eat high cholestorol. You might look really healthy, even exercising regularly, but inside the artery walls plaque continues to build up until, one day, blood can’t get through, or the plaque breaks loose, and you find yourself dead.

Some of the “Fried Eggs and Bacon” signs I saw:

• Executive Meetings were deemed as having a lot of waste in them. The suggestion had been made to ensure that each executive only give updates on things that were relevant to the group as a whole, or things they needed help on. Sounds innocent enough, right? Except this: If what they are working on is not relevant to the entire group, then activities which aren’t vital to the company won’t be exposed, and will continue to grow unchecked.

  As an example, let’s say the sales department introduces a new incentivization program where their employees get bonuses based on how often they talk to customers. Because bonuses are involved, they develop a shared form which contains information about how the customer is using the system, how it is configured, and sales opportunities. Meanwhile, the product development team has begun a process of canvassing existing customers to understand more about their habits and how they use the system. Since both of these appear to be localized uses of the information, it may be possible that neither group knows about the other’s efforts. It’s only when customers are getting contacted by two or three separate people asking slightly different but similar questions that it is discovered.

• Even though the site has an international presence and highly targeted categories, there was no way to do A/B testing of different layouts, information schemes or other changes. If it was made for one, it was made for all. Unfortunately, this was seen as a limitation of the platform they wrote, rather than a business concern that could be addressed in small chunks. They saw the need for A/B testing, but had simply thrown up their arms saying it couldn’t be done. Anytime you say, “It can’t be done” you are really saying, “I’ve found a limitation but I don’t have the knowledge and/or experience to figure out how to adapt the current platform to do that in an incremental way. So I’ll just wait for it to be a crisis.” While crisisies are great motivators for change, it’s not a good way to introduce vital features into your core business technology.
• While pair programming was possible, it wasn’t encouraged. Like many organizations, it was seen as Ok to do sometimes, but not a daily way of working. This is a shame because judicious use of pair programming – especially early on – helps ensure a high bus number. In the short time I spoke with this company, at least two separate people were identified as being vital to critical processes. This is completely unacceptable in any organization, and especially for startups.

What stuck me the most was that this was an organization that appeared to fit squarely into the “post-agile” frame. But instead what I saw were cargo cult adoptions of very good practices that missed the real need for agility.

Company B – Going the Distance

The second company doesn’t fit into the “post-agile” company, since they’ve been around longer than 5 years, but as with our first company, have many outward signs of agility. The developers all do Test-Driven Development, and even Behavior-Driven Development. They do frequent releases. They have never missed a release date in 4-5 years. But yet, there were serious signs of cargo-cult adoption:

• Pair programming generally wasn’t encouraged. As with Company A, it’s allowed to solve some short term issue, but not at all encouraged as a normal way of working.
• The developers and QA department are separate entities, reporting to different managers. Generally this means that each department has differing goals. In practice, this usually means that QA is not seen as vital to the release cycle, but more of a “they’ll do the best they can with the time they have”. I generally frame the question like this: If you have a QA department, then you are already saying that the output of your development team is not good enough, and must be verified by an entirely different team. Think about that. Does the marketing department have a separate QA process team which verifies all production? And if they do, is something *ever* released without it going through that process? What about HR? Or Sales? In fact, the closest might be finance, but even then, it’s done via an auditing process. QA should be an integral part of your release process – so integral that they should all be on the same team.
• A further concern was that the Development and QA departments were physically separate from one another. Alistair Cockburn has materials and slides which show the costs of not having people collocated. QA and Development play such an important role together that the thought of them not being physically located together is frightening from a cost perspective.
• Incremental Improvement. This is also known as the boy scout rule. Every time you touch a piece of code you should make it a little better than how you saw it. This is especially vital when you have classic ASP pages which are 10-30kloc. Yes, *k*loc. Per page. You will never be able to just sit down and rewrite that. Only through slowly adding tests, slowly refactoring methods, slowly improving will you get to a state of understanding and safety that lets you slay it.

Of course, as I mentioned this was not a “Post-Agile” company per se. They had legacy code issues and other challenges. However, if you are claiming to be agile, then you need to tackle core issues and never be content to be happy with where you are. This is the principle of Kaizen and is reflected in many agile methodologies, most notably “Inspect and Adapt” from Scrum.

Company C – Shifting Sands Are Not Good Foundations

The final company was a brand new start up. I had the chance to meet several times with the founder and talked about technology, practices and methodologies. I found several interesting elements:

• The language choice was made without anyone else being involved. He had decided on Java, rejecting .NET and Ruby in addition to other languages. I found this interesting because what they seemed to need was a rapidly building Web platform with key areas being able to be optimized for high performance. Java can certainly fit into that, but so can many others, and locking a technology choice seemed very strange. Thankfully I sold him on Ruby on Rails, and he was willing to look at people who had both skill sets. The key here is to not limit your technology choices from the get-go. You’ll need all the flexibility you can get, and if you are hiring engineers with the understanding that they are the best and brightest and doing the best thing for the company, if they want to suggest a new framework, one should at least be open to talking about it
• Pair Programming, and Test-Driven Development, were rejected flat-out. I found this interesting because, again, as a founder making those kinds of decisions seems to be allowing oneself to be driving too deeply into the “How” of accomplishing business goals. It was also a sign that there is still much work to be done to truly bring agile over the chasm
• Similarly, the concept of a coach working with the team didn’t gain much traction. While it’s important to have hands-on people at all levels early on (“Architects must code, and so should coaches”), it is important to set solid practices from the get go. If you think you know the best way to write and produce software, and aren’t open to other approaches – even if they challenge long held assumptions – then any concept of “agility” is locked into whatever your world-view is. The narrower you hold that, the narrower the playing field your team has, and the less agility you can have.

When you are first starting a team, the practices you set early on are what define your identity for a long time to come. As my good friend Corey Haines says, TDD should be what you *fall back* on when things are reaching crunch mode. If you don’t set that early on, you only end up dug into a hole which is nothing but waste to get out of.

Your Organization

So look around your organization. Yes, even those of you who think you are in a “post-agile” organization. Do you understand the *principles* of what you are doing? Are you challenging wastes and deficiencies? Are you constantly striving to see where principles and practices make sense and stretching to try new things? If not, then you aren’t being the best you can be. So stop that. And start bring great.