I continue to see Agile adoptions that focus on the R&D or Engineering team. There seems to be this acceptance that the core of Agile rests there. I'm absolutely not convinced. I think that if the business doesn't fully embrace the Agile transformation, it is doomed for failure. How can I effectively engage the business in our agile transformation?

  • I think it would help to understand why you think Agile will fail in Engineering because the entire enterprise doesn't undergo an Agile transformation. Do departments like Legal, Compliance, HR or Investor Relations, for example, need to become Agile for Agile to work well in Engineering? Commented Jun 1, 2011 at 3:07
  • 2
    I've seen passionate engineering groups embrace Agile and then ultimately watch the Agile initiative fail. I've seen HR practices discourage empowered, collaborative work versus heroics. I've seen compliance auditors refuse to accept that Agile can be a disciplined and compliant approach. And I've seen Executives not support a rank-ordered work or limited work approach; that is, they continue to push "fire driven development" and hence chaos, pure quality & delivery. That leads to a view that Agile is flawed. This lack of buy-in outside Engineering results in Agile abandonment. Commented Jun 6, 2011 at 17:27
  • 1
    What have you already tried? Why didn't that work for you within your organization?
    – Todd A. Jacobs
    Commented Jul 16, 2020 at 13:07
  • I think the default state of any proposed transformation (agile or any other) is failure, unless it is supported by effective sponsors. Inertia & tradition are very effective at killing novelty and change. That said, I think that ToddA.Jacobs is right - we can't understand the question or offer useful answers unless we know what you've tried and why it has failed. I also think the information that @jeantabaka provided in comments needs to be in the question.
    – MCW
    Commented Jul 16, 2020 at 14:05

7 Answers 7


I appreciate that your question is about creating engagement with the Agile team, not getting the business to be Agile. I recommend that you start from a mindset of there not being any difference between the business and the teams. Choose to believe that both groups are fully aligned against a single vision... then address the bits that don't match your internal reality.

Adopting this mindset that there is no border helps me to avoid mistakes I've committed too many times in the past:

  • Selling Agile: It's not about "Agile", it's about better business results through the consistent delivery of high quality software, assuming software solves the problem. Using outcome-based language rather than our agile lingo helps the business to easily see how much I care about the organization's success, and becomes much less threatening as a result
  • Silo-based thinking: I can't solve a problem from inside the box. When I'm focused on a border between groups from a mindset of being inside one of the groups, I'm always going to use "Us" vs. "Them" language. Instead, I'm going to see a single group that is doing a few things that don't make sense.
  • Opaque Goals: A full transparency about your objectives goes a long way towards building trust. This requires having moved beyond the silo-based thinking, though, because that bias will come through in your language as you are transparent, and listeners will easily detect the misalignment between your words and your beliefs.

In a lot of ways it just comes back to the core Scrum values: Commitment, Focus, Openness, Respect, and Courage. Demonstrate these in the course of purposeful engagement, and people will come to share those values and return the engagement and attention you offer.


I am puzzled by the responses by Trevor and Mark and would be interested in what “Agile” means to them.

To me Agile (the philosophy) and its various incarnations XP, Scrum etc. are only a way to address the issue of what should I be working on and when. They are a framework to focus your team (and I don’t care if you are a developer, accountant, or lawyer) on what is the most important work and communicate your progress or lack thereof.

I don’t think anyone could argue that communication is a good thing and that is what is the bedrock of Agile processes.

The value of a backlog of work items that the whole company can see can’t be overstated, it allows

  • An understanding of what is important to the company and in what order
  • What part each division of the company has in making that goal a reality
  • Visibility into the cross functional dependencies
  • And perhaps the most important, the ability of the individual to see how they are contributing to the company which has the effect of increasing both the quality and quantity of work produced.

Agile has been recently adopted by my organization (moving on from a part waterfall and part continuous integration dev model)

And the way the consultant (who were selling Agile) approached it was:

  1. Learn "why" do you want to adopt Agile and what currently ails the organization which you are trying to solve through Agile. In our case it was little predictability in delivery, continuous integration detrimental to sustained quality levels, people being pulled in different directions, hardly any knowledge transfer and lack of deliverable vision.

  2. Explain and prove "how" Agile is going to solve the above problems and meet the business needs. Again in our case, it was through case histories, training, sample SPRINTs with the actual team and most importantly bringing the conflicts out in the open and relating the conflicts with the problems mentioned in the point above.

  3. Empower the team and implement the changes required. It was partially done through a pilot couple of sprints.


I personally have seen both business not doing agile and business doing agile(the teams doing agile) and they both work. Most of the time, the team doing agile can be a precursor and can seep into the business starting to do agile but sometimes this does not happen. Agile derives from two main principles buried in Agile, inspect and adapt and let the team decide

I see many concepts that are like this software you are using....you like this stackexchange interface....well, they can swap the whole implementation and keep the interface the same. Same with teams and the business...the interface to the business does not have to change(though I prefer to change it as it is a competitive advantage to be more flexible and agile helps with this). So I would say yes, Agile can still work without the business doing Agile, but it would be better for the business to embrace agile as well in my opinion.


Getting your business to adopt or accept Agile is the same as any other change initiative. You have to demonstrate the value of doing it.

Two points with that -

First, you have to show concrete advantages that Agile provides (and can't be achieved otherwise). "Everyone's doing it" isn't good enough. It has to be right for the organization.

Second - you have to remember that Agile is not a silver bullet. Agile isn't applicable in all situations, and even where it is it may not be the best solution. So as Mark said, in some departments it just doesn't make sense.

  • Can you tell me more based on my remarks to Mark? Commented Jun 6, 2011 at 17:28
  • Sure - Agile itself is primarily an Eng process, so it's application in other areas will be limited. But High Performing Teams can be implemented elsewhere; just not wholesale. If you want Mgmt to 'buy-in' you have to give them a reason, which comes from proof, not assertion. Get them to agree to try it in a limited, even stand-alone application to see the results. Prove to them that it can work in other areas. But any change will be incremental, and limited. If you're expecting Mgmt to just change to Agile, then you're done before you start. It simply won't happen. And honestly, it shouldn't. Commented Jun 6, 2011 at 17:47

In the end, I think the agile transition comes down to adoption benefits vs agile phobias.

  • adoption benefits are mostly relevant to the team (improved quality, communication, etc...) and I think somewhat also easy to get for the business (time to market, improved ROI, customers satisfaction, etc...).
  • agile phobias are strong in the management departments (unable to make commitments, incompatible with distributed team, don't scale, I will have nothing left to do as a manager, etc..)

But from my experience business executives are often really tied to management executives. So it's a 2 versus 1 situation where Scrum teams often stay undercover as you described. You might want to look closely at your situation if you're not mistaking the business resistance with what's really behind: management resistance.

So yes, if you don't address those mistaken belief about agile or Scrum from the management, than eventually the adoption will fail.

Possibles suggestions includes: provide training, promotion, create dissatisfaction with the status quo, creating the sense of urgency, addressing individual fears, let time run its course, fire the saboteurs, praise the right behaviour, involve people, etc, etc...


A great way to introduce agile & xp methodologies to the "business people" in your organization is to have a workshop and play the xp game.

Note, that each team should have a coach who also doubles as the teams customer. Break out groups of "business / sales / developers" into a common area where several teams can be created. Have fun with it but make sure you are touching on key principles of your agile adoption.

Some examples:

  • Business Value
  • Velocity
  • Estimation
  • Priority
  • Acceptance Criteria / Assumptions

This is an example of the last game I played with a group of such people. Iteration 1 was folding paper to look like a hat, Iteration 2 was building a plane, Iteration 3 was blowing up balloons:

Iteration 1

  • Anything goes
  • Be easy on them

Iteration 2

  • Make it harder or easier given the blank stares you get from iteration 1
  • Requirements / acceptance criteria

Iteration 3

  • Inject stories
  • High value stories


  • Must sit on head
  • 3 folds

  • Needs company logo
  • Must look like a hat


  • Must look like a plane
  • Distance
  • Non - parabolic trajectory
  • Stunt plane
  • Company logo


  • Logo / Size
  • Color(s)
  • Size
  • Rubber ring
  • Something in it

Some other great ideas can be found here: http://tastycupcakes.org/

The whole goal of this exercise to help people outside of your agile teams see the benefits of agile methodologies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.