Update: It's been modified slightly. Read the official announcement and the follow-up instead of this post.

As some of you know, one of my most popular talks is "Agile Companies Go P.O.P.". What you probably don't know is that this talk is actually an introduction to a full day training course I give on this topic. So far it's been a lot of fun and I cover everything from the space shuttle (which you've seen from the slides), to the Feudal era (which you haven't). However, there is one topic I don't cover enough and I think it's time to point it out: agile sucks, but it sucks less than the alternatives.

To explain this, I should explain POP a bit. P.O.P. stands for "people, organization, and process". In my original research, I had broken this down into "people, organization, and tools", but "Agile Companies Smoke P.O.T." was clearly going to limit my target audience.

In the full-day POP course, I give an introduction to the topic, explain how to hire and retain Agile people, break Organization into "Beliefs" and "Management" and then go into Process and implementation. I particularly like the implementation section because I give companies tools to visualize their company becoming more agile over time.

However, when I get to the "process" part, I have to give the caveat that it's actually the least interesting part of the process. That's because if you have the right people and the right organization, you'll be able to develop a process that works for you. However, Process doesn't spontaneously occur. It's something that you create over time and customize to fit the needs of your company. In fact, every agile methodology explicitly encourages you to customize it to your needs (and then people complain that it's not agile. bah!) Currently in the agile world we have a bewildering array of agile processes and ideas:

• Scrum
• XP
• Kanban
• Scrumban
• Crystal
• Kaizen

... and so on.

Scrum and XP are great for development teams, while Scrumban and Kanban seem to do better on the operations side (where fixed development cycles don't match well with black swan events). Also, when a company decides to go agile, it can be very intimidating to choose a methodology. Scrum seems simple, and then you need to decide if you want a Certified Scrum Master. You start watching videos about creating an effective Scrum retrospective. The sprint planning meetings drag on and people get frustrated. And what the hell is a backlog refinement meeting?

And yet, while I've worked with many agile (and not-so-agile) companies, there is one style which is not mentioned frequently and seems well suited for small teams. It doesn't seem to have a name, though some people mistakenly call it Cowboy Coding, so I call it SOC Agile (SOC: Stream Of Consciousness). It's dead simple and can serve as a nice transition to a more formal methodology.

We have three primary development categories: Cowboy, Waterfall and Agile. Cowboy coding is one that many new companies start with. It does a brilliant job of allowing experimentation and very rapid development, but often risks knowledge silos, technical debt, conflicts (two developers creating work that can't integrate with each other), and a generally bus-sensitive code base.

If the company doesn't get shot by the cowboy coders, development starts to get more structured. Org charts are introduced, processes spontaneously appear (and combust) and the company begins the long, inexorable march to Waterfall, though more and more companies are recognizing Waterfall pitfalls and adopting agile techniques. It's successful enough that non-tech companies are beginning to look at agile.

And you still have XP developers complain about pair programming. You have Scrum practitioners rejecting any work longer than a sprint. You have system administrators grumbling at accusations of a failed sprint because they had to stop everything to fix a critical security hole (hence, Scrumban and friends). You have product owners who have never met their customers but are serving as a proxy for them.

And then I see small teams, like that on my last contract -- I'm still looking for a new contract, by the way -- that manage to Get Stuff Done in an agile manner despite not following a specific methodology. I see this constantly. It's such a natural fit for the way we develop software that I think it's time to formalize this.

I can't say that I have this perfected, but I think the following is more or less accurate.

The SOC Team

• SOC is appropriate for small teams where you can understand the entire code base
• SOC teams write a lot of tests, but don't demand a particular methodology
• SOC doesn't have "sprints" or "iterations". You just have tasks

A SOC team has a Team Lead, Developers, and a Product Owner.

The developers are, well, the developers.

The Team Lead is the expert who knows the entire system and can be relied upon to answer questions and provide excellent feedback. Developers decide how they're going to implement something, but if there is a problem, the Team Lead has final say. The Lead should defer to the Developer whenever possible and offer constructive advice when appropriate. Team Leads support, not direct.

The Product Owner (PO), similar to scrum, maintains the product backlog. However, there is no "sprint backlog" because there are no sprints. The PO is responsible for knowing the full backlog and being able to answer any business question related to them. It's good if the PO can also answer technical questions as well.

The SOC Process

At the end of every business day, a 15-minute time-boxed stand up is held. It's at the end of the day to ensure that what you did is fresh in your mind.

That standup begins with the Summary. Before the standup, the product owner should briefly discuss where you've been and where you are going. Any interesting future issues for the team should be mentioned at this time.

After the Summary, each team member should explain:

• What they did today
• What they'll do tomorrow
• Any blockers they have

On a daily basis, every team member is allowed, even encouraged, to improve the code base. Add a Makefile target to rebuild the project. Factor out common code. Move test data into fixtures. The member is expected to mention this in the standup and it is the responsibility of the Team Lead and the PO to rein in developers who spend too much time "improving" instead of "developing" (and vice versa!).

Every task is done in a separate branch and merged back into the "main", "trunk", or "integration" branch, or whatever you call it (details about how to manage source control are left up to the team). Tasks should be as short as possible. Any task expected to take over a certain amount of time (a week is a good limit) should, if possible, be broken down into smaller tasks, each of which can add value even if the overall task is cancelled.

When a task is finished, the member independently chooses their next task. They should prioritize tasks assigned to them, high value tasks, and quick tasks. It is the responsibility of the Team Lead and PO to guide developers to suitable tasks if the team member is regularly making poor choices on their next task.

If enough open tasks are found, it is the optional responsibility of the PO to designate Priority tasks. There should be a variety of them. If a new task is to be chosen, they should be chosen from Priority tasks. If a team member is unconvinced of their ability to accomplish any Priority tasks, they should speak to the Team Lead for guidance.

Obviously, if a critical issue arises, any task can be stopped and the Team Lead can assign someone to tackle the issue. There is no formal structure to this because SOC is designed to be as lightweight as possible.

New team members (Newbies) are initially encouraged to focus on a single area to become very comfortable with the business rules. After the Team Lead and PO agree that the developer has become comfortable in their area, they they become Generalists. Generalists are strongly encouraged to regularly choose tasks outside of their comfort zone. Failure to do so may allow them to become siloed in an area and also encourage other Generalists to not work in that area.

Team Leads and POs do not promote Newbies to Generalists until the Newbie:

• Appears to understand the business (not the code base!)
• Is writing solid code
• Is writing appropriate tests

Releases are not described in the SOC process, but it's suitable for both continuous deployment and regular releases (as one might expect from a sprint or iteration).

Benefits

The idea behind SOC is not to formalize a new methodology, but to put a name on a practice that is already moderately well-known but followed in an almost embarrassed manner. It's a way of following a set of reasonable development guidelines that can eventually move on to a more appropriate Agile development process. Think of it as "Agile light", if you will. By putting a name to it, you can say "we follow a SOC development process" instead of "eh, we just get things done."

In short, SOC eliminates the silo problem of cowboy coding, but allows the extremely rapid development of products. It encourages creativity while having Just Enough Process to keep development on target.

Again, it bears repeating that SOC is not recommended for very large-scale environments. This is not necessarily because it is not suitable for large-scale environments (I know of at least one large company whose successful development process is very similar to this), but given that most of my experience with SOC-like development models has been with smaller code bases, I am hesitant to suggest it for anything else.

By separating developers into Newbies and Generalists, we create the psychological incentive to explore more of the code base. Ambitious developers quickly want to shed the Newbie label and fully participate in the rest of the team's work. However, by starting out by becoming an expert in one part of the system, the Newbie can quickly gain confidence in their ability to participate and make a meaningful impact on the system.

Hiring for a SOC process is important. You want developers who are comfortable in a fluid environment, but can also appreciate business concerns. There is a tremendous amount of freedom in SOC and it's very easy for someone to get carried away and try to "perfect" (*cough*) everything at the expense of adding value to the company. Thus, both the Team Lead and the PO are required to keep things in check.

Also, SOC benefits from skilled, conscientious developers. It's very easy to spend too much time "perfecting" your code, but it's also easy to spend to much time pushing out new features and ignoring technical debt. This is a hard balance to maintain. SOC does not address this directly because every project is different and every company is different. However, as a guideline SOC suggests that the PO advocate for features and the Team Lead advocate for technical debt management, but each should be able to understand and even agree with the other's point of view. If you can't balance these two needs, you're likely to have long-term problems.

In practice, I find this development model to be very successful for small projects. The pace of development is very rapid and I don't find that code quality is significantly worse than for other methodologies. The most significant obstacle that I find is appropriately managing the backlog. Typically backlog items are merely added to a ticketing system, such as Jira, Redmine or Trac. This does not scale well unless the PO is very, very good at managing the tickets and creating appropriate Priority tasks.

Glossary

• Backlog -- tasks which have not yet been done
• Generalist -- a developer who is allowed to work on all parts of the system
• Newbie -- a new developer becoming an expert on part of the system
• Priority -- tasks which should be taken before other tasks
• Product Owner (PO) -- The proxy for the customer. Maintains backlog and assigs Priorities
• SOC -- Stream Of Consciousness coding
• Standup -- an end-of-day "what I did, will do, and blockers" explanation for every developer
• Summary -- the PO's business-focused summary of the project status
• Task -- Something a developer can do
• Team Lead -- The code base expert. Should also understand business concerns
• Team -- all developers, including the Team Lead

There is very little terminology and most of this fits what you already know.

Summary

Shut up and write some code.

Seriously, there is nothing radical about the above and it mirrors what people are actually doing rather than forcing them to adopt a new methodology all at once. You might view it as a gentle transition to more formal Agile methodologies. Or, if it's working fine for you, it might remain your Agile methodology. Its very loose structure presents some risks, but once you understand them, you can watch for them and decide the appropriate course of action.

As usual, comments on this are very welcome, particularly suggestions for improvement.