12 Key Agile Assumptions

This content is syndicated from LeadingAgile by Mike Cottmeyer. To view the original post in full, click here.

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.

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.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

ten + 12 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”



To explore how we can help you, please get in touch