12 Assumptions Agile is Making About Your Company

Last time we talked about the attributes of successful Agile teams. I did that post because sometimes I think we get hung up on implementing some set specific practices, just because we think that’s what it means to be agile. My belief is that agile isn’t about adopting any one set of practices. Agile isn’t really about adopting practices at all.

Agile is about being able to get feedback and respond to change. It’s about building products our customers want and are willing to pay us for. Somehow, I believe that if we can shift our focus away from installing specific practices, and more toward making sure whatever practices we choose lead to the desired business outcomes, we will have a much better chance of being successful.

In short, the idea that installing some set of specific practices make us Agile is just wrong. Practices that support business Agility come in all shapes and sizes, and being able to systematically choose what works in our specific context is key to really making change happen. Our job is to figure out what practices are going to work for us, and then figure out how to implement them in our organization.

Agile Makes Some Assumptions About Your Company

Shifting focus to today’s topic, this post is about the 12 key assumptions team-based agile methods make about your organization. Most of the popular agile approaches do come with a set of prescribed roles, artifacts, and ceremonies that you are supposed to follow for guaranteed success. In many organizations, doing it by the book will work just fine. In some cases though it’s a recipe for disaster.

If you go the prepackaged route, you need to understand what assumptions are being made about your organization before you begin. By definition, an Agile Transformation means you’re Transforming your company to work in a way that allows the agile to practices to work. Sometime that’s the right thing to do… sometimes it’s not. Either way, you’ve got to understand what you are getting yourself, your company, and your career into.

Here is our list of 12 common assumptions Agile methodologies are making about your company:

1. Teams stay together over time

This is the big one. When agilists talk about planning meetings, daily stand-up, relative estimating, velocity, sprint commitments, and even some of the technical practices like shared code ownership and pair programming… there is an underlying assumption that the team is 100% dedicated to the effort they are working on. Many of the practices associated with the prepackaged agile approaches make this assumption. If you aren’t going to have teams that stay together over time, pretty much every thing else is going to be harder than it has to be.

2. People are specializing generalists

This is the assumption that makes the first assumption work. When people are over specialized, we need to find ways to keep them busy. Typically that means we matrix them across multiple projects. The underlying assumption is that people are resources that can be infinitely time sliced across as many projects as we’d like to have them work on. The idea of the specializing generalist is the antidote for this. When people can do more than one thing on a project, there is less of a need to assign them to multiple teams to keep the busy.

3. People are engaged and motivated

In general I think this is a valid assumption and many motivation issues are a result of folks working in organizations and systems that just don’t make sense. The idea here is that if we get people out of life-sucking environments and give them some control over their situation, they will be happy and engaged, and willing to bring their best selves to the workplace. Like I said, I think this is something that is generally true, but I don’t believe it is universally true. Some people have other things going on that make them unhappy. Some people really are incompetent. If that’s the case, agile’s approach to dealing with it might be incongruent with your current HR policies and organizational norms.  Not sure agile has the full answer here.

4. You’ve got the top 10%

Kind of related to the last point, but even once you put people into rational work environments, the lightweight guidance given to folks via agile methods, is not suitable to how many people are used to working. There are lots of decent developers that can code from a spec, but ask them do to things on the fly and they are lost. If you really want to make agile hum, you need the best of the best. You need developers that are problem solvers and passionate about doing what they do, and doing it well. You want folks on the team that are driven to learn new things and new ways of working. That might be more than just 10%, maybe 20% or 30% can work this way, but it’s clearly not everyone on your team today.

5. Teams deliver products

Agile is often accused of being a product delivery life-cycle rather than a project management or software development life-cycle. There are clearly things that happen before the team gets the requirements, and even after they have delivered, that aren’t really addressed by agile methods. At the end of the day, agile is optimized for teams that are focused on continuous ongoing investment in a persistent but ever changing code base. The idea of spinning teams up around temporary endeavors is not really part of the plan.

6. Projects come to teams

This is probably just a corollary to assumption 1 and assumption 5, but at the end of the day, the work needs to come to the team, rather than the team coming to the work. Our traditional models tend to lead us to form transient teams around the funding initiatives we approve to run our organization. We ask ourselves if we have the people available to do some project. The question we need to ask when we adopt agile is how we can approve projects that can be done by the teams we already have working together.

7. Team are loosely coupled

In order for the team to get predictable delivering value, in order to establish a stable velocity of product into market, the team has to be loosely coupled from the rest of the organization. That means that the value created by one team needs to be wholly independent from the value created by another team. If team one is hyper-productive and team two isn’t… that might not be a great overall outcome for the business… but team two’s performance doesn’t have any bearing on team one’s ability to create value for the enterprise.

8. Teams have minimal external dependencies

If a team is going to be held accountable for delivering value and getting predictable over time, they need to have everything they need to deliver that value. That was the first key to success in my last post. Dependencies represent areas where the team does not have everything they need to be successful. Sure, dependencies can be managed and tracked, and many can be mitigated or resolved. The challenge is that anything outside the team’s control is just one of many excuses that can be used when things don’t quite go as planned. Accountability breaks down when the team doesn’t own the deliverable, and this leads to activity based planning.

9. Fully engaged customers

This is a big one… probably should have been first. How do teams get away with lightweight documentation? How do they get away with minimal specification and constant change? How do they get away with constant inspection and adaptation? They have someone on-site, either a customer or a customer representative that is empowered to make decisions about what goes into the product… in real time. If you don’t have a fully engaged customer, many of the key principles and practices of agile break apart, and what we really have is just another way of tracking activity. There is no longer any guarantee we are delivering value.

10. Established architecture

I’m not saying that you have to have an established product to do agile, but agile methods don’t really address how to spin up a product from scratch. How do you do enterprise level architecture and design on agile projects? How do you mitigate risk and validate assumptions? In many organizations, specifying an ambiguous Iteration 0 is insufficient.  For complex products, refactoring is not the answer.  Because agile methods are largely silent on this, you either have to have it in place, or figure out how to do it yourself.

11. Minimal process governance

Agile doesn’t deal with phases, budget approvals, business cases, templates, change management, audit controls, charter documents, scope sign-off and the like… at least not explicitly. Much of this is left to the strength of relationship, and the degree of trust, between the customer and the team. In larger, more complex organizations, at least for now, governance is part of the equation.  We need to have a credible story in place to deal with it. There are tons of things we can do here, it’s just that agile doesn’t have the answer… and in all honesty, that’s kinda by design.

12. Team Members are co-located

You might argue with me on this one, there are a ton of us out there dealing with distributed and dispersed teams. Many of us are figuring out how to make it work, and making it work quite well. The point I want to make by including co-location here, is that many of the things agile teaches us about managing delivery, assume the folks are all in the same room. Team rooms, information radiators, daily stand-up meetings, pair programming, and lightweight documentation; all kind of assume that people are all in the same room at the same time. When we disperse people across multiple geographies and time zones, many of the constructs encouraged by agile break down and we need different ways to mitigate communication risk.

In Closing

Okay… so please keep in mind… I’m not suggesting that if you don’t have this stuff in place it’s impossible to do Agile. Many of the things I listed here are simple to put in place… some are not. We just have to be aware that Agile methods are making these assumptions about your organization… and if these assumptions aren’t true… we either have to make them true, via Transformation, or we have to come up with alternatives to standard Agile practices to mitigate the risk of them not being in place.

You’ve got to either change your company or change your practices, there isn’t really any place in between. You need to know this before you get started.  The worst thing you can do is adopt a practice intended for one context when that context does not exist in your organization.  As always… let me know your thoughts.  Did I leave anything out?  Anything on my list off base?  Let me know.