Arlen Bankston: 5Q's on Agile

Some time ago, I participated in the PM Boulevard's 5Q's on Agile series. Now, it's my colleague Arlen Bankston's turn. Do enjoy his interview below.

Arlen Bankston’s recent work has focused on combining Lean Six Sigma process improvement methods with Agile execution to dramatically improve both the speed and quality of business results. Read why he thinks Agile processes are about personal accountability and empowerment.

Q1: Why use Agile methods?

At an organizational level, the key drivers tend to be speed, flexibility, and quality—in order of demand. Much has been written about the general benefits of iterative and incremental development, so I’ll focus on what I consider to be a critical effect of the processes in the long term: Personal accountability and empowerment.
A favorite quote of mine from Dee Hock, creator of the Visa network: “Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior.” Many currently entrenched processes, with their focus on mechanics over value and creativity, are detrimental to a feeling of personal ownership and control. This void initially blunts individual drive and innovation, and subsequently poisons team dynamics and effective project delivery.

Q2: Biggest challenge of implementing Agile methods?

When you give power to one, you take it from another. The division of roles and responsibilities in Agile is significant and new, which fuels resistance. You have self-directed Teams, which are scary to many managers, and often to the team members themselves. You have “servant leaders” in the form of ScrumMasters and Agile PMs, a strange and frightening concept to some control-oriented PMs. You have customers that now need to prioritize their requests and stay engaged throughout the life of a project. All of this change is not easy to manage.
Transparency is another key factor. In addition to the new responsibilities granted above, folks also have to learn to live without excuses and admit to mistakes without shame. Burning security blankets isn’t an easy sell.

Q3: In what environment will Agile be most successful?

Organizations that focus on generating real value, and foment partnerships between those with problems (e.g. business) and those with solutions (e.g. IT) are most likely to succeed. Extensive hierarchies and compartmentalized roles tend to play against this goal. Startup companies often provide a good model for what an Agile organization should be. They usually don’t have time or money to waste, so a focus on value is a matter of survival.

Q4: What is the future of Agile?

Agile is still maturing, and many recent advances are due to two factors: Blending of complementary methodologies, and a deeper appreciation and understanding of process methodologies such as Lean and Six Sigma. Case in point: Scrum is the leading Agile methodology now, but it generally incorporates XP principles, and leverages Lean approaches to reducing waste in repeatable activities. I have seen great tools drawn from Evo, the Dynamic Systems Development Method, Feature Driven Development and Crystal, and used within Scrum. The introduction of pure pull-based flow (a Lean principle) in place of iterations, championed by David Anderson and Corey Ladas while at Corbis, is very interesting as well.

Q5: Can you recommend a book, blog, podcast, Web site, or other information source to our readers that you find interesting or intriguing right now?

Aside from our own blog , I currently like Corey Ladas’ Lean-fueled musings , Jeff Patton’s design-centered Agile Product Design Web site , and Confused of Calcutta , JP Rangaswami’s blog.

About the Author

Arlen Bankston is an established leader in the application and evolution of process management methodologies such as Lean, Six Sigma and BPM, as well as Agile software development processes such as Extreme Programming (XP) and Scrum. He is the Vice President of LitheSpeed, and a Lean Six Sigma Master Black Belt and Certified ScrumMaster Trainer.

Time for XP version 2.0?

When I first encountered with Agile methods several years ago, the fuss was all about eXtreme Programming. The XP community in those days was pretty stringent about doing all 12 practices or nothing, and there was a lot of talk about working software, coding discipline, etc. I had the good fortune of working on a team that implemented XP pretty throughly on several projects with pretty amazing results.

Now, it seems like Scrum is the "new black", and Certified ScrumMaster training is all the rage. Yet, having worked with many teams implementing Scrum, I do find that after some time, they run up against an improvement plateau. In these circumstances, when the team is developing software, we almost always recommend getting disciplined with XP.

On major difference from the proponents in the early days, is that we always recommend a context sensitive approach. Every project, every organization and every team is different. So, to accomodate these difference, we like to see team adopt XP in a context sensitive way. This might mean doing continuous integration first, before attempting TDD. Or it might mean doing simple design and refactoring, but not pair programming. Always making these adjustments within the context of the project's environment, but also always making sure we're pushing the envelope and continuously improving.

All is all, it's turning out, that in the midst of all the Scrum success, XP can provide that next level of "lift" in terms of improving time to market and software quality.

Old Wine in New Skin?

With all the brouhaha about Agile methods in the last year or two, it's hard not to get carried away in all the excitement. But, sometimes when balance sets in, it's hard for me not to wonder -- what's really new about Agile that's creating such an enthusiastic response? Now, I understand and appreciate that Agile has its critics, sceptics and nay sayers, and that's probably a good thing as we head into an Agile bubble. But, even among its supporters and advocates, some introspection is probably a desirable thing, isn't it?

Musing on this topic, I think back to some of my very first projects in the early 1990s back when I was a software developer. They were in the defense industry, and in those exciting days, we had:

1. Small, collocated teams. Usually, we operated in small teams of about 3-4 developers, a tester and a clear customer. We were collocated in a shared bullpen, even we did not pair program.

2. On site customer/product owner. Our customer was usually a colonel looking to make a mark by building a software system that delivered real value.

3. Daily meetings. We had daily meetings with our customer and entire team, including our managers. Okay, so we didn't standup, and we didn't have the nice 3 questions we do now, but these meetings were pretty productive, and gave the customer a real sense fo what they were getting, and us great interaction with them and each other.

4. Technical discipline. We had object libraries to package and streamline code development, code reviews and simple, clear design. We checked in often and integrated very often.

5. Software studio/craftsmanship. We had senior programmers who were pretty strict about shepherding the system, and apprentices like me had help and mentoring as we progressed to become journeymen and master crafsmen ourselves.

6. Heavier methods on large projects. On larger projects, the confirguration management and documentation was more rigorous, the code reviews more formal and the touch of the senior programmers a bit more onerous. The team dynamics were not as fun, but we still had sub-team focused on particular modules. Overall, it was amazing how much quality, valuable code we produced because of the additional structure.

As you can see, even though we didn't call it Agile, many of the accoutrements of Agile were very much present on our early projects. So, I have to wonder, what's really new about Agile?

Not sure I can answer that question authoritatively, but I understand that Test Driven Development is perhaps the only new practice in XP. I can't think of any other practices in XP, Scrum, DSDM, etc that can be claimed as radically new. Therefore, I think the thing(s) that it new about Agile is not so much this or that practice, but the presentation of a prescriptive set of simple, essential practices. By boiling things down to the minimum, and by perhaps pedantically insisting on these basics, Agile methods have tended to reliably deliver customer value.

Your thoughts?

Worldwide Agile Adoption?

Whew -- it's been quite a while since my last Blog post! Turns out that I've been quite busy conducting a number of Agile related engagements on at least three continents: North America, Europe and Asia. This work included workshops in Chennai, Bangalore and Mumbai; Manchester, UK and Italy; and the Middle East.

Some of my impressions:

1. Agile has spread quite widely in Europe and North America, and adoption is growing quickly elsewhere.

2. Many organizations are now evolving their Agile implementation to multiple projects and complex organizations. These organizations are now looking to evolve beyond basic XP and Scrum on lone projects.

3. Enthusiasm and interest for Agile was strong everywhere I went. For instance, I found quite a difference in the interest in Agile in India from my last trip there about 18 months ago.

4. Agile is creating a common vocabulary for the delivery of customer value all over. I was easily able to converse with people in many different engagements because of this shared vocabulary.

5. Companies large and small are adopting Agile, in pretty much every industry: high tech, financial services, healthcare, etc.

How are Lean and Agile Related?

In the past few years, we've seen the emergence of serious initiatives in understanding and exploiting the connection between Lean Thinking and Agile methods. Here are some of the interesting efforts (of which I'm aware):

1. Experts like Mary and Tom Poppendieck and Bob Charette have been preaching the value of Lean Software development for many years.

2. Leaders like Bud Phillips at Capital One have established a rigorous project delivery discipline using Lean Thinking to reduce process waste and Agile methods to accelerate project delivery.

3. Corey Ladas and David Anderson have developed a discipline they call Lean Software Engineering that they use to deliver production releases at Corbis every 12 days.

4. My own work in the area of the Lean-Agile PMO and the Agile PMO work of Ash Tengshe and Scott Noble at Capital One Auto Finance.

5. There's now even a Lean-Agile-Scrum user group, hosted by Alan Shalloway of NetObjectives.

So, what's all the (growing) excitement about? My experience has been that Agile methods can be scaled up to the enterprise with hundreds of projects using Lean techniques. Also, within projects and processes, Lean Thinking can help identify and reduce waste. Finally, Lean Thinking can serve as a management philosophy - one that perfectly aligns with the Agile ethos of customer value, self-disciplined teams, small batch delivery and continuous improvement.



Some time ago, Arlen Bankston and I created the adjacent chart for our training classes.


I'm happy to share it with you now to help illuminate what we see as the connections between Lean and Agile.

What is Lean Thinking?

Lean Thinking – the term popularized over a decade ago by Jim Womack and Dan Jones in their book with the same name, refers to the core principles behind the Toyota Production System (TPS):

• Specify value by product
• Identify the value stream for each product
• Remove waste from the value stream
• Make value flow without interruptions
• Let the customer pull value from the producer
• Pursue perfection through continuous improvement
  

The TPS system and its supporting “Lean” culture, first set in place at Toyota after World War II, continues to drive Toyota‘s incredible financial success even today. Over the years, Lean practices have spread from Toyota and manufacturing to thousands of companies in all industries including healthcare, financial services and retail.

According to Womack and Jones’ Lean Enterprise Institute, "Lean thinking changes the focus of management from optimizing separate technologies and assets to optimizing the flow of the product through the entire value stream."

The Lean-Agile Connection

Thus far, I've posted mostly on the subject of Agile methods and Agile Project Management. In the next several weeks, I will be turning my attention to Lean, and exploring how Lean and Agile fit together.

Next Post: What is Lean Thinking?