I'm curious what others are doing with regard to getting teams up and running with Agile in a sustainable way. What do you emphasize first (practices, principle, process framework)? Or is there no one approach for kicking off teams?

EDIT: I guess I am still looking for something in between business and technology. Where does that guidance come from and what does it look like? I'd love to hear some ideas on this.

  • 1
    Hi Jean - welcome to the site! Could you please edit your question to be more of a question? It is coming-off like a blog post/soap-box, rather than a question. May 3, 2011 at 1:52
  • @Jean - As Mark said, welcome! We're happy to have you joining our community. My suggestion is to take a walk-through of some of our other questions from our high-rep users. Additionally, our Meta Site is where you can learn more about our community, as well as participate in driving it's direction and helping to solve some of its growing pains. We're looking forward to your contributions to our site. Welcome! :)
    – jmort253
    May 3, 2011 at 3:34
  • Looks like a blog post. But good advice is given in this post! +1 for blog-post-question. :) May 3, 2011 at 14:43
  • 1
    Hi Jean, welcome to pm.se! You can always answer your own question (perfectly permissible) so maybe cut some of this out and paste it in an answer. Then the rest of us can provide different perspectives.
    – Lunivore
    May 3, 2011 at 14:55
  • @Lunivore - Well said. I think that's a great suggestion. Jean, please feel free to reformat your question as a question and paste your answers in as an answer. Just pretend that you're on Jeopardy! ;)
    – jmort253
    May 8, 2011 at 23:55

4 Answers 4


Make sure business owners are on board and see a need for change – not just technology/delivery people. Change is hard and unless there is business value ($s) on the line any transition (Agile or otherwise) will stall and fail.

  • +1 great answer, Bob. Practical, to the point. Something that can be used right away. May 10, 2011 at 22:18

Let go of your focus on Agile for Agile's sake ... forget about trying to do Agile as Agile should be done or to earn stars on some sort of Agile report card. Agile methodology is only a tool ...

Focus on business results -- develop and communicate SMART goals in terms of business results -- use/re-shape/refine/re-engineer methodologies like Agile as your toolset to accelerate the delivery of business results.

Even if you could turn "successful adoption and transformation to Agile" into some kind of specific, measurable, aggressive, realistic, timebound objective, it will still be a really dumb strategic objective because business results pay the freight.

  • I agree. A successful "Agile adoption" should be about a successful articulation of business goals and why certain (Agile) practices might be a valuable approach to help teams contribute to the business success. What would compel people talking about "business results" to then move toward a discussion about "Agile" or "not Agile". Where does the methods and technologies and tools discussion about business success occur and with what guidance? May 22, 2011 at 22:46

We don't push Agile, we expect clients and Teams to pull it.

In our fairly sizable yet chunky enterprise, we have a community of Agile champions. Our role is to help kick-start teams and organizations on the path to using Agile methods well. That includes indoctrination in various thinking, organization and action tools, as well as ongoing coaching to ensure a continuous improvement atmostphere gets established and then sustained.

We start by forming communities of practice that include leaders at various levels, and involve the Agile coaches and mentors that will work with the Teams themselves. That works very well where leaders respect people and treat them accordingly. In situations where some managers view individuals as fungible resources, we politely say our goodbyes and if needed put in a word with some leaders further up the org tree - we're fortunate to have a sensible CEO now and some wise Vice Presidents (of various flavors), so that helps a lot.

One interesting aspect is that we can help any and all teams improve their thinking and habits, regardless of the flavor of work process they use. Using Agile thinking is not like flipping a switch - Friday you were in a Waterfall Team, Monday you're in an Agile Team. It takes time and a fair amount of study for folks to adjust their perspective. It takes practice for people to master new habits. It takes trust for them to volunteer their better thinking and take charge of their own work processes. Communities of practice make the journey of continuous improvement sustainable.

So, in some of our larger organizations, we start by gently and progressively improving all flavors of work processes. Once a culture of continuous improvement takes hold through its habits of inspection and adaptation, work processes can shift to their optimum spot in the spectrum as driven by client needs and investments.

We also always start by saying "Why do you want to use Agile? Using Agile for Agile's sake isn't a good enough reason". That leads to some very interesting conversations with various leaders and managers. In short, we either reach win-win and proceed, or no-deal and go for the next opportunity.


Best idea? Hire a coach (not necessarily me, but I am a professional coach).

The coach can work with business and with technologists and get them on the same page. It only takes a few months, and then you can usually take it from there.

As for a more direct answer: establish the engineering environment and engineering practices early, and simultaneously work with the product management side of things to understand how to deal with velocity, iterations, breaking down stories, and the shorter-term focus of continual integration and continual delivery.

There are a few rough iterations before you hit your stride, but with a good start, sustainable pace, and regular retrospectives you can push through it.

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.