Definition of a Great Agile Company


Last night I attended the inaugural meetup of the Great Agile Companies of NYC group at AppNexus‘ beautiful headquarters in New York. The event was moderated by Josh Grob, a member of AppNexus’ Agile Strategy & Execution team, with the intent of open-sourcing the definition for what it means to be a great Agile company. AppNexus’s own Agile team is less than a year old and has quickly grown to 11 full-time scrum masters. With over 500 developers building the company’s flagship online ad auctioning platform, the need for a dynamic and scalable software development process has never been stronger.

The audience consisted of about 30 New-York area software project managers, business analysts, product owners, and scrummasters. Attendees were divided into 3 groups and asked to generate their own definitions of what it means to be a great Agile company. Each requirement had to be supported by an explanation of why it is important, and had to include at least 1 concrete metric to measure its implementation. Each team generated about 20 cards, which were then traded with the other teams in multiple rounds to “pass and perfect” down to a final set of 14 that passed unanimous approval. Together these formed a “constitution” that was signed by all participants. Here is the result, in no particular order:

  1. Executive support. Without this it is easy to temporarily “skip” out of Agile when time gets tough.
  2. Empowered team members. Development teams need to “own” the solution and implementation details.
  3. Transparent teams. Goals, user stories, and progress should all publicly visible in analog or digital form.
  4. Self-managed execution. Teams should be self-regulating and determine whatever communication and work structure works for them.
  5. Continuous learning and improvement. Teams should consistently conduct honest retrospectives after each sprint with concrete action items for improvement.
  6. Input from the customer. Working closely with the client to develop user stories, showcase progress, and receive feedback.
  7. Frequent product releases. Allows for constant feedback and minimizes the risk that the customer’s needs will not be met.
  8. Alignment on vision. Just a backlog of user stories is not enough. What is the overarching goal?
  9. A dedicated team. Team members should be dedicated to the agile team and not shared. A single product owner should serve as an empowered advocate for the user, preventing deadlocks and giving direction.
  10. Shared language. A principle of Domain Driven Design that improves communication and understanding between developers and the customer.
  11. The confidence to fail a sprint. Unless a sprint fails, there is little incentive to fix the underlying root cause.
  12. Trust. Team members need to work well with one another and trust each other to do the right thing.
  13. Fundamental buy-in from above. That means limiting last minute quick-fix or emergencies that are really a symptom of poor planning.
  14. A partner with stakeholders. True alignment and fellowship with clients, business users, managers.

One of the challenges that surfaced during this process was the intended scope of the definitions. Many of the contributions tended to re-iterate tenets that are already central to the Agile Manifesto. It wasn’t clear whether to include them in the final list (because they were obviously true) or not (because they were already implied). In our “retrospective,” it was suggested that rather than create a potentially competing Agile Manifesto, the meetup team should instead accept the Manifesto as the base “constitution” and the group’s contributions as “laws” that implement the constitution in a consistent and clear manner.

The Agile meetup group will meet once every month to continue the work that began last evening. True to the Agile methodology, the group will iterate to constantly refine the definition of what it means to be a great Agile company. The goal is that their work will serve to assist software companies with concrete recommendations and metrics to make the Agile process more successful and ultimately more profitable for them.

About Martin Rybak

I am a New York area software developer and MBA with 10+ years of server-side experience on the Microsoft stack. I've also been a native iOS developer since before the days of ARC. I architect and develop full-stack web applications, iOS apps, database systems, and backend services.

One response to “Definition of a Great Agile Company

  1. Just realized I wrote #1!

    I’m sad my idea about snacks didn’t make the cut. 😀

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s