Agile Development Blog

Once upon a time, Frederick Winslow Taylor and W. Edwards Deming lined up across a ping-pong table and went at it.

“There is only one correct way to do any job!” said Taylor, smashing one of those real curvy, tricky serves at Deming.

“Let people contribute in the best way that they can envision,” retorted Deming as he calmly returned the serve from 8 feet behind the table.

“Employees are evil and lazy!” screamed Taylor as he sliced a murderous shot high into the air, the backspin causing a local singularity in the spacetime continuum.

“The success of the company is good for all, and people want to succeed,” offered Deming, backhanding a low shot with sideways spin just over the net.

“Managers are the ones that know the answers!” shouted Taylor, cutting his forehand all the way across the table.

“Hmmmmm,” said Deming, who could be a very thoughtful guy given the right circumstances, “the people closest to the problem are more likely to come up with a correct answer.”

“Supervision!”

“Empowerment.”

“Punishment!”

“Trust.”

And on and on. They never did finish the game.

Here’s the interesting thing: we’re still playing this ping-pong game.

Here’s another interesting thing: many people don’t seem to know it.

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.” “If I do BDUF and most of my projects are late, then I’m waterfall.” (Oops, well, the last one is actually true, but the first two aren’t.)

The thing is, you’re not Lean unless your company commits to the two pillars of Lean: continuous improvement and developing people. You’re not Agile unless you create and foster self-organizing teams. You might be doing a lot of Agile practices, and you might even get better results than you used to, but you won’t be Agile. If you accept this limitation and you are doing Scrum, then you will be doing ScrumBut.

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.

Really? Yes. Would those managers supervise and micromanage some employees while supporting and developing others? Would they dictate commitments and solutions to some while allowing others to determine their own fate? Would they trust the people on the Agile projects and punish the ones on the waterfall projects? Would they hold individuals accountable on waterfall projects while holding teams accountable on Agile projects?

Of course not.

What they will do is treat everybody the way they always have. They will beam with pride when teams gather in their little circles every day, and then they will dictate to them that the manager is actually still responsible for delivery and ask for lists of who will be assigned to which task in the next sprint. They will refuse to make priority decisions and instead direct people to work on multiple projects at a time, and they might even decide just how many design documents each team should have. They will do this because that’s how un-Agile projects do it and for some reason this makes management require it of all teams. (What has always seemed odd to me is that they won’t demand that waterfall teams release an increment of working software each month because the Agile teams do it. So I guess it only works one way.)

And they’ll wonder why this Agile thing gets so much hype, since it really doesn’t seem all that different from what they’ve always done. And really, the results aren’t that great.

You can’t be both Agile and not Agile. You can’t be both Lean and fat…er…not Lean. Not at the same time.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

I have been back in the Fifth Discipline Fieldbook this week thinking about strategies for creating a shared vision to 2020 at Rally.

With our newest round of funding, we will be growing rapidly in multiple locations and beyond the max tribe size of 150-170 people. (Dunbar’s Number)  Over that last year, we grew the business well but without advancing our total headcount numbers.  Now with headcount growth slated in the field and in two development centers, we need a stronger foundation to steer our growth.  Doing this work, hit me with a BFO (Brilliant Flash of the Obvious) that is impacting many of largest Agile adoptions that I am working with.

Many leaders are seeing the benefits of Agile and “Telling” or “Selling” their organizations to go there.  But, the “Telling” and “Selling” strategies run counter to many of the guiding ideas behind Agile itself.  I have seen this rub  limit or slow the positive impact of an Agile adoption.  This rub almost guarantees you will only get incremental benefits from Agile and will most likely fall back to your old ways.

As Bryan Smith and Peter Senge remind us “Telling” is just the first developmental step in creating a shared vision to adopt.   This strategy has many flaws including that fact that most people only remember 25% of what they are told.  However, it might be the right strategy given a dire current reality.

In extreme contrast to Telling, is the Co-Creating strategy that has the whole organization working together to create the vision and implement it.  This requires a leadership group that can truly let go and an employee base that has enough personal mastery to understand their own personal vision.   Those are big pre-requisites to this strategy, but it should be obvious that if you can run this strategy, the self-motivating benefits will be highly supportive to getting the most benefit out of Agile.

The complete model, from the Shared Vision section of the Fieldbook includes five strategies that can be grown into over time:

1. Telling
2. Selling
3. Testing
4. Consulting
5. Co-Creating

We have discussed our Flow-Pull-Innovate approach for adopting Agile in larger organizations, but I have talked very little about strategies for leading this adoption process.  I think it is because most Agile adoptions get started in a grassroots approach and are led by the teams that testing it out.  The success of these teams then caused people to take notice and start talking about how to replicate this success.  In essence, I have been assuming, and the market has been executing a Testing level strategy.

I believe to put an organization on the path to continuous improvement, you must at least be executing a Testing level strategy to scale your adoption.  Over time, I believe your ultimate ability to move to the Innovate level of Flow-Pull-Innovate will be tied to your ability to adopt a Consulting or Co-Creating strategies.  As Agile is a journey to greatness, this journey depends upon your organization maturing in all including strategy execution.

What are your experiences with these strategies in your Agile adoption?

At Rally in 2010, our planning team is running a two pronged approach using a Testing strategy with the organization in Q1 for our 2010 plans and a three quarter long co-creating strategy for our 2020 vision.

About the Author: Ryan Martens is a lego building father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Just published in Dr. Dobb’s is my article on Agile Social Contracts;  It covers the process of Agile rollout planning and the burning need for a clear commitment to your teams and organization.  What is not as well covered are the other four components.

I make the argument in the article that Agile enterprise adoption is easy, if you are prepared and crisp with the right structure and discipline.

Here are the five items you need to be successful at Agile release planning or Agile Enterprise Rollout planning:

Release Planning Structure		Agile Enterprise Rollout Structure
Team – Cross-Functional Development Team	1	Team – Cross-Function Transition/Steering Team
Commitment -  To the Definition of Done	2	Commitment – To changes in external metrics
Contract – Team Norms	3	Contract – Social Contract with the Organization
Roadmap – Product Increments	4	Roadmap – Flow-Pull-Innovate transition steps
Vision – Product/Service	5	Vision – Organization, Process & Technology

Agile Rollout planning is best done like sprint or release planning. This is what I and others mean when we say “using Agile to rollout Agile.“  We use the same methods, structures, and process to rollout Agile as we do to manage our development.  This gets senior managers and executives talking and experiencing Agile along with all the practicing teams.  It leads the transition team to the benefits of visibility, alignment and frequent feedback cycles.  When this is done, it makes Agile Enterprise rollouts as easy as Agile software development.

For more details on our approach to enterprise Agile rollouts, please see the post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate.   This approached is based on a concept of  Shu-Ha-Ri (See Alan Atlas’ post on DIY vs. Shu-Ha-Ri).

For a detailed example on a rollout plan that uses the Flow-Pull-Innovate approach – see the post Agile Transition Plans – an example.

About the Author: Ryan Martens is a backyard chicken farmer, founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I do not believe there is a recipe for Agile enterprise transition plans because good ones must take the context and setting of the organization into account.

I do believe that starting step-by-step is the only way to get the snow ball of incremental improvement rolling down hill.  Our model, Flow-Pull-Innovate, is based on a strategy of creating a self-funding sustainable approach to adopting Agile; where some of the savings/profits from each step are reinvested in the next improvement step. (See my post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate for details on this approach.)

In addition to a step-by-step transition plan, you need a vision, shared commitment and social contract to be successful. Although, The Flow-Pull-Innovate model does provide sign-posts for your roadmap, the actual stories necessary to transition vary.  When we work with groups or organizations to build a plan that will take them from one step to another, we use a transition planning model that I helped define in the mid-1990’s.  This planning model is based on organizational change work from Peter Senge’s Dance of Change and Michael Hammer’s Reengineering the Corporation.

In this step-by-step plan, we use these high-level variables for planning change; “Strategy, Process, Organization and Technology.” In these transition steps, a typical story starts with the implementation of new technical and organizational infrastructure to support new methods, tools and techniques that lead to new way of working.  Download An Example Transition Plan (PDF).

An Example Transition Plan based on the Flow-Pull-Innovate model for Enterprise Agile Adoption

Again, please note this plan is very high-level and a fairly generic application of the Flow-Pull-Innovate approach. (See Jean’s post on What’s So Great about Flow? for more details on the first step.)  I have seen many variations on these detailed plans over that last 6 years.  Use this as a simple starting point for you and your group to think about your own situation.  If you work with Rally coaches to help you plan your organization’s transition, you benefit from their years of experience and ability to start with a clean white version of this model.

Transitioning to Agile at the enterprise level can be a very simple step-by-step process as long as you and your group thinks about it in this way. If you do a good job of defining “Done” for your steps, you will then be able to inspect your progress and adjust your plans based on empirical feedback.  In this way your adoption approach is just like the Agile process your adopting for software development; an empirical process that you steer with regularly schedule inspection and adjustment.

If, on the other hand, you think about the adoption as a “Big-Bang” that will be done on a certain date, I believe your “plan-driven” thinking will cause you to miss the real opportunity.  You will typically end up with only incremental improvement and not have the momentum to enable your teams to keep up the good work.  And, you will fail to get on the continuous improvement curve that will lead towards Agile/Lean expertise.  Given that most organizations are operating in a “plan-driven” world, this is not a surprising reaction to Agile adoption.   Agile success comes as you gain success incrementally by taking one step after another, while keeping process, technology and organization change areas aligned.

In CMMI, Level 5 teams get to a place where they “become continuous improvement teams.“  In enterprise Agile adoptions, we start folks at continuous improvement and watch them benefit from creating employees and teams that both solve their own problems and continue to re-focus on value delivery through each step.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts.  That question is quickly followed by, “And I don’t want to hear that it works everywhere!”

Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”

Where To Start

Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.

Our rendition from "Stand Back and Deliver"

In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts.  They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed.  The variables used in the book include:

• Uncertainty Attributes: Market, technology, customer size, project duration, scope of change
• Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies

Three Perspectives

1. We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
2. If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project.  The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
3. Projects of Low Uncertainty and Low Complexity rank third.  They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.

Environmental Factors

Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success.  Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments.  Here is a snippet of that kind of team assessment:

Does the Product Owner have the right level of authority and influence? Are they…

• Embedded with team?
• Dedicated to the project?
• Able to gain consensus from stakeholders on goals and features?
• Able to evolve the product backlog (with training)?
• Able to support the team through constant feedback and decision-making?
• Able to plan at multiple levels (with training)?

Is there a dedicated, persistent, cross-functional team?

• The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
• ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
• Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
• Architects might be contributing members, or might be advisory.

Is the team co-located?

• It’s not required, but can be a risk factor.
• For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.

Do you have an Uber Product Owner and Uber ScrumMaster?

• For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.

Is there a controlled build environment?

• To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
• As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).

You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach.  To me, Agile works everywhere,  it is just a question of how good do you want to be and by when.

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what  succeeds versus falls back, I do not believe their is a “cookbook” for Agile adoption. Of course, the question then becomes:

If there is no cookbook, then what is the best approach to succeed with my Agile adoption?

Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.

The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking.  However,  Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations.  In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.

Getting Over the Hump - Critical Step #3

Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)

We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.

What do think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?

About the Author: Ryan Martens is a trail runner,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Making New Agile Teams Successful breakout with Erika Peace of ICS and Chris Browne of Rally

Having now returned to Boulder and unpacked my bags, I wanted to reflect on the great experience I had moderating our most recent Agile Success Tour event in DC.

Our 5 executive panelists provided such great insight into their Agile adoptions, each with a different perspective.

The Q&A session that followed brought out puzzles and challenges from the participants, and it was great to feel their energy and passion to learn more. This flowed so wonderfully into the 5 breakout sessions that no one even wanted to take a break afterward!

In fact, the energy stayed so high through our final remarks and lunch that it fed even more insights from our panel. And, the audience was so highly engaged that many chose to stick around after the event to continue one-on-one as well as group discussions.

It was a pleasure and an honor to once again be a part of an Agile event that provided such genuine value to its participants.

One other note from DC: as usual, Israel Gat did a great job with his pre-event engagement work with the panelists. And, he has continued his tradition of capturing pivotal moments and pithy insights in his post-event blog entries. I encourage you to read his Threads from Washington, DC post for a breakdown of some of his favorite discussions from the event.

Stay tuned to the Agile Blog for videos from the DC event as well as details about our next round of FREE Agile Success Tours!

Last week, I ran our quarterly planning session and was very positively surprised with the results of testing Toyota’s A3 method in the meeting. Before the meeting, I was convinced that I was trying to “push” too much, but instead the team sucked them up.

Breakout groups at Rally quarterly planning

If you don’t know what an A3 or problem sheet is, I recommend starting with John Shook’s article in the MIT Sloan Management Review.

What is an A3?

John says in his article, “At Toyota, there exists a way to solve problems that generates knowledge and helps people doing the work learn how to learn. Company managers use a tool called the A3 (named after the international paper size on which it fits) as a key tactic in sharing a deeper method of thinking that lies at the heart of Toyota’s sustained success.”

An A3 is a problem sheet in which the owner attempts to:

1. “Establish the business context and importance of a specific problem or issue

2. Describe the current conditions of the problem

3. Identify the desired outcome

4. Analyze the situation to establish causality

5. Propose countermeasures

6. Prescribe an action plan for getting it done

7. Map out the follow-up process”

There is much more information on this topic on the Lean.org blog.

Introducing A3’s to the Rally team

At Rally, we started using A3’s to diagnose issues due to growth and market maturity last summer.  I hired a trainer and friend from my US WEST days Jay Arthur and focused our first effort on product marketing and product management.  In that three-month effort, we had very positive results from working 4 simultaneous A3’s and built a well prioritized backlog of countermeasures.  We knocked off the highly feasible and highly effective ones that next quarter, but we continue to work off that list today.  After product marketing and product management, we brought the technique to operations team, too.

Given this foundation and 25% of our team trained on A3’s, we brought them into quarterly planning as part of our rock prioritization process. Jean and others warned me that it was a ton to grasp in fully packed day of checking the last quarters results and adapting for the next quarter. For that reason, I was prepared to fall back to our old way of working and prioritizing.

Homework is good?

What happened was even more than I could expect. Instead of throwing out this process, the team embraced it and even worked through breaks. Using A3’s to structure your thinking requires discipline and critical thinking.  I guess there was more pull waiting in the room than I expected; maybe it was the required reading of John’s article that helped?  My conclusion – homework is good?

As Jean and I continue to explore what makes an Agile organization, I am curious as to what others are using in their business planning processes to prioritize their quarterly or annual efforts.

About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

“You learn more quickly under the guidance of experienced teachers. You waste a lot of time going down blind alleys if you have no one to lead you.” -W. Somerset Maugham (1874 – 1965)

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

click here if video player is not loading in your RSS reader

Catch the next Success Tour events in Boston, Seattle, Chicago and London this Fall
These events are free, but registration is required.

I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?