How can I get our business leadership engaged with our Agile team?

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...

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.

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.

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

Hats

• Must sit on head

• 3 folds

• Needs company logo
• Must look like a hat

Planes

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

Balloons

• 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.

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.

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.