Reflections on the SQE Better Software/Agile Development Practices Conferences

June 14, 2011 — Posted by Al Shalloway

I had a great time at the Better Software/Agile Development Practices West in Las Vegas last week.  I gave 7 of the 9 talks/courses/tutorials Net Objectives presented. I would say the most interesting thing about the conference was the large number of companies using Scrum who's progress had somewhat plateaued and the number of companies who wanted to go Agile that couldn't see how to use Scrum to do it. I call these patterns of failure. Not that they hadn't had success, but were failing to maintain it. My talks, of course, were about patterns of success – how to overcome these same patterns, interestingly enough.

Plateauing of an Agile Learning Process.

It's clear I'm going to have to write a more detailed blog here, but thought I'd put out some of the things I saw. First, plateauing of Scrum teams seem to fit into one of the three following patterns:

1. The first pilot goes well, but subsequent pilots have difficulties. Pilots are often successful, not so much because they've started an agile process, but because they start by creating cross-functional teams.  This is a well established phenomenon, that co-located, cross-functional teams will outperform non-co-located, non-cross-functional teams by 3 to 1 even when both teams follow a waterfall process.  See Challenging Why (not it) Scrum Succeeds where I first reported this phenomenon over 4 years ago.  In fact, successful pilots can actually hurt an organization (How Successful Pilots Often Actually Hurt an Organization).  Pilots, started in isolation, without attending to overall organization, are luck to start a sustainable pace of transition.

2. Isolated teams are successful, but there is no clear way to extend the success to the entire organization.  In this situation, pilot teams work better and many can be started.  Unfortunately, no one understands how to handle inter-team dependencies.  While Scrum-of-Scrum's is supposed to manage these dependencies, one of the elephants in the Scrum room is that Scrum-of-Scrum seems only to work for communicating results of work, not for creating the context of work.  Several of my talks at the conference was how Lean-Kanban provides many insights into handling these dependencies.

3. Learning is hard to maintain in Scrum teams.  It is almost axiomatic now that retrospections become stale after a few months.  There is a lot of effort being spent on imploring teams to be more disciplined in doing retrospections - not to mention all of the tutorials on how to do them well.  No one seems to explore the possibility that relying on learning mostly through retrospections is not a good idea. Developers are passionate, they want to get to the work at hand.  Most will do the first few retrospections with energy, but after that they just seem to be an impediment to getting the job.  We don't want to change developers - their passion is essential for sustainable effort. What we need to do is to create a better way for them to learn. We've seen that one way to do this is with explicit discussions about all workflow steps and a team-board (Scrum-board, Kanban-board) that reflects this.

Challenge in Seeing How to do Scrum Across the Enterprise

Most of you know I'm not going to tell you how to do this, but rather say a team centric approach is unlikely to succeed. To be clear, I don't mean enterprises need to do a command and control type of implementation. Rather, it is essential to have leadership create a context for the implementation and have teams manifest that vision. Lean flow provides a great way to create the needed context as well as where to start. We've seen successful transitions begin more often at the business side and product portfolio management, than at the team (although that is often the only place one can start). The bottom line is that a holistic approach must be considered before even starting.

When to Consider More than Scrum

If you are trying to just get a team or two to be agile, Scrum is not a bad way to start (although I still think the practices of Kanban will be very useful to integrate into your framework). However, if you are in a situation where you have people who are needed on more than one team because they have specialized knowledge of the domain or legacy code or have special skills, assuming Scrum will work may be a costly and painful assumption. Again, even if it works in the small, it may not scale.

If you can relate to any of these challenges, I suggest you check out our Scrum clinic . We've got lots of suggestions about how to improve your Scrum methods there.  I also invite you to contact Net Objectives (info@netobjectives.com) to see if we can assist you.

Alan Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban