Things We’ve Heard Leading Agilists Say That We Don’t Believe

September 18, 2015 — Posted by Al Shalloway

I’ve often seen what at first appears to be successful Agile pushed out of companies.  Some folks say that’s just because management doesn’t get it.  But I think that’s not always the case. Sometimes the Agile that gets pushed out of companies should be pushed out of companies. Not all Agile is equal and sometimes what works at the team level is doomed when it is used to guide Agile adoption across the organization.  After the initial success, this becomes clear and the organization abandons this misguided form of Agile with good reason.  

There are several beliefs by many in the Agile community that we feel are counter-productive yet are spoken by many leading Agilists.  My concern is that it confuses those new to Agile as to what Agile can and should be.  This blog states some common beliefs in parts of the Agile community that we don’t agree with.  

Common Belief

What We Believe

Agile as team focused

Agile is a team-based approach.

One must look at the entire value stream – from product management to the team.  Product management in many ways is more important than the teams themselves as you must be building the right things and have the right workload.

Agile is based on the Agile Manifesto The Agile Manifesto was a watershed event for the software development community.  Unfortunately, many people consider it the definition of Agile and keep referring to it for guidance.  In the Agile Manifesto: Incredible Success and Time to Move On we acknowledge the manifesto's incredible contribution to the software development community but suggest that Agile should not be based on a static document that presents a team-centric approach.  It is interesting to note that the manifesto mentions teams 17 times, the customer 3 times, the business twice and management not at all.

Scaling Agile

Scaling Agile should start at the team level.

You don’t want to scale agile, you want to look at the entire value stream. Smaller teams working together is better, but if you have to work at scale, start by looking at the entire value stream. Starting with effective product management is often much more important than getting teams to work well.

Agile works because teams get to self-organize.

While self-organization is important, it is more important to have an effective eco-system within which to self-organize.  This misbelief is why many things required at scale are ignored in the Agile community.

Scrum of Scrums works to scale Agile

There is little evidence this approach works well. It certainly is not the only way to coordinate multiple teams.  See Scaling Scrum – What Works

It’s all Scrum

Inter team dynamics are quite different from team dynamics.  Applying what works at the team level everywhere causes challenges.

Management and Agile

Management’s role should be supporting teams.

While management does need to support teams, management has responsibilities beyond removing impediments for the team.  They are responsible for setting up the system within which people work.

You should try to eliminate middle-management

Mid-management may be ineffective in many places but that doesn’t mean it’s not necessary.  There is a lot of tacit knowledge in mid-management.  We need to get them focused on creating proper eco-systems so people have a better place to work.

Starting Agile

A good way to start Agile is with a team pilot project.

 

Getting teams to do Agile by themselves is not that difficult. A focus on it may actually make expanding Agile more difficult later. For large organizations, starting an Agile pilot by starting Scrum at the team level is often counter-productive.  See How Successful Pilots Often Actually Hurt an Organization

You always start by forming cross-functional teams

Cross-functional teams are wonderful. However, they are not always possible or financially viable to have.  Few practices are an always.

You always start exactly where you are

Starting where you are may result in missing easy opportunities for improvement. 

Complexity & Non-Predictability

Workflow should not be specific

We believe a team’s workflow should be specific to improve collaboration and team learning as well as to allow management to understand what the team is doing

You can’t get predictability because software development is complex

There is a difference between micro-predictability (is the ball landing on the red, black or green number in roulette) and macro-predictability (more money is staying at the table).  There are patterns in software development that can have you achieve predictable results.  Just because many people haven’t figured out how to do this doesn’t mean it’s not possible.  Perhaps they are trying things that aren’t effective at scale (e.g., Scrum-of-Scrums).

You must keep everything as simple as possible

Focusing on simplicity typically results in missing things you should be looking at.  See Framework Tunnel Vision.

Miscellaneous

 

You should never tell people what to do when you start them off, just give them the rules and let them figure it out themselves

When people start out they need more support.  Telling them what to do at the beginning while providing options as they learn is often an effective way to teach people how to learn.  Having people struggle often is just frustrating for people.

Teams should not make commitments, just forecasts.  The best way to build trust is to make commitments and then inform who you've made the commitment to as soon as you believe you may not achieve it. See Let's stop doing the wrong thing because we can't get past an impediment

If you're having troubles with Agile, perhaps it's not what you're doing, but it's the belief system that you're coming from.

Please contact me if you think we can help.

Al Shalloway

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 over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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