3 Industry Trends for 2014

December 26, 2013 — Posted by Al Shalloway

I have long described myself as "pre-cognitive impaired." But sometimes we can make predictions based on patterns that are right in front of us. I believe there are three shifts in thinking in the industry taking place that will manifest themselves this year. They are an understanding that:

  • Scrum will be recognized as a great team framework and not thought of as an approach to scaling Agile
  • Kanban exists both as a general approach to software development management and as a transition method
  • that starting with ATDD is often easier and more productive than starting with TDD

Scrum Will Be Recognized as a Great Team Framework & Not Thought of as an Approach to Scaling Agile

Scrum is a great team framework, but not a very good framework for scaling Agile. The success of Scrum at the team level, while being challenged at the program level, is ubiquitous. It has often been argued by Scrum proponents that this is somewhat by design.  That Scrum is a framework and intentionally doesn’t cover everything. However, it is one thing to say you need to put things into Scrum and another to recognize that a bigger picture than Scrum is required.  I believe the reasons people attempting to do Scrum beyond a few teams have difficulty include the following:

  • Scrum does not recognize that inter-team dynamics are different than intra-team dynamics.  In other words, the reasons which make it work so well at the team do not work at scale.
  • That one should not be “scaling” in the first place, but that one needs to create a context at scale within which teams can work.
  • That Scrum thought leaders have not emphasized (and in many cases even reject) the importance of Lean, with its systems thinking, leadership/management model, understanding of flow and learning models.

Many in the Scrum community have tended to resist systems thinking and have held Lean to be something that may or may not apply.  I am of the opinion that Lean’s systems thinking approach, explicit policies, attention to flow, and mid-management’s role are essential for Agile at scale. Ignoring them dooms most initiatives from the start. Ironically, some of Scrum’s practices (e.g., cross-functional teams, iterations, product owner) are not.

Why It Will Become a Trend This Year:  Given I’ve been saying the above for almost a decade, why do I think it will be this year that this trend happens?  The reasons are twofold.  First, very few have figured out how to use Scrum to drive Agile at Scale and the few that have, use methods based on systems or Lean-Thinking.  Another reason is that the Scaled Agile Framework presents the ideas I consider essential in a cogent manner.  Those who have been trying to scale Scrum immediately recognize how some of the SAFeTM concepts are necessary .  While none of these are new, seeing them together resonates with people struggling to get Scrum to scale.  These include:

  • One must take a portfolio, program, team view
  • One must attend to flow throughout the value stream
  • Creating a high level context to enable distributed decision making is essential to avoid both command and control management and local optimizations that hurt the true delivery of value
  • A real emphasis on how to achieve high code quality via test-first and continuous integration
  • A viable method of managing and implementing agile Architecture

Even if one does not intend to implement SAFe, these concepts are readily clear and therefore expose the shortcoming of attempting to drive scaling Agile with the Scrum mindset.  BTW: Please don’t interpret any of this as a lack of endorsement of Scrum (extended by Lean-thinking, of course).  I believe Scrum is a great team framework when it applies.

Kanban exists both as a general approach to software development management and as a transition method

There are two flavors of Kanban - one based on the original notion of using Kanban as an approach to manage software development, the other is a transition method based on evolutionary change.  The first is called Kanban while the second is called the Kanban Method (hence the confusion).  In my opinion, the Kanban Method is very powerful but somewhat limited.  It should be used only when nothing else will work.  In Extending the Kanban Method - Updated, I talk about how many of us outside of LKU use Kanban - as part of a systemic approach to improving an organization.

When Considering Test-First, Consider Starting With ATDD Instead of TDD

I am very encouraged by the spread of test-first methods.  However, many organizations believe test-first means TDD at the unit-test level.  Very often Acceptance Test Driven Development (ATDD) is often a better place to start.(btw: I mean to include Behavioral Driven Development, BDD, in this as well).  First, let me say that I love that TDD at the unit level is becoming more and more practiced.  Unit-level TDD is an implicit method of following many of the mandates of design patterns.  The challenge with starting with unit level TDD is that it is often difficult to do in existing applications that are being modified.  Furthermore, doing ATDD:

  • Improves the communication between product owners/business analysts, developers and testers
  • coordinates the work of developers and testers
  • assists developers in understanding what needs to be built
  • minimizes misunderstandings that result in the creation of unneeded features
  • improves quality both by lowering technical debt and lowering the number of bugs written
  • paves the ground for automated regression testing
  • provides insights into application architecture

Why I Believe The Trend to Implement ATDD Will Increase in 2014. I see several forces coming together on this, including:

  • SAFe emphasizes ATDD considerably.  Doing SAFe means you must do ATDD.  Even those companies who aren’t planning on doing SAFe are at least hearing about it
  • ATDD has been on the rise each of the last several years.  I’m hoping it’ll reach critical mass this year
  • Scrum’s recent suggestion that one incorporate XP practices into the framework and the rise of the Scrum training with integrated XP style coding practices has been raising people’s awareness of ATDD.

To be clear, don't take this commentary as any suggestion you should not start TDD at the unit level.  If your folks want to, go for it.  But all too often  test-first is abandoned because unit-level TDD seems to difficult and people don't realize that the alternative of ATDD is available. ATDD is such an amazingly effective practice, taking little investment and providing great returns, that exposure to it may be all that is needed.  I hope so.

In Summary

Agile is moving into the enterprise.  This is exposing fundamental challenges that our current popular approaches have – over-focus on teams, lack of overall systems thinking, and insufficient attention to technical methods.  As organizations realize they must adopt Agile methods and find the current popular ones lacking, people will rethink approaches and look for what works.

I admit to being an idealist.  But I see little reason to accept tolerable pain when better solutions exist.  Wishing you all a great 2014.

Al Shalloway
CEO, Net Objectives

Resources for those interested:

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.


I'm not seeing the daylight between your and David Anderson's thinking.

You say the Kanban Method ignores the notions of small batches and of limiting work hitting teams. In my understanding these are elemental aspects of the Core Concept "Manage Flow", and this was only reinforced during my attendance of David's "Kanban Masterclass" in October where he spoke explicitly about the non-linear increase in problems and coordination costs as batch sizes grow and about the value of "demand-shaping" to balance input against the capacity of a system.

I'm left thinking this is more a difference in personalities than in ideas.

Thank you for the post.

I'll review the blog but it is not just personality. I'm not referring to just batch size within the system. I understand that's managing flow. See this blog of David's http://djaa.com/why-doing-things-right-should-lead-doing-right-thing

I'm a believer that using MBIs early to focus on the right work and the right size of the work is essential. That is often a place to start and something the Kanban method doesn't say to look at initially.  Also, LKU's Kanban Method approach says teams are orthogonal to Kanban Method. I am definitely not saying that.

Thanks for this comment, i'll make it clearer what I mean.

I was told by both David Anderson and David White (an LKU accredited Trainer) that teams are orthogonal to the Kanban Method.  This emphasizes that the Kanban Method is not saying to look for improvements in team structure.  The Kanban Method is a focus on Kaizen because trust does not exist.  But this ignores the other methods that can often be done at the start, after visualizing the workflow and seeing where you are.  Managing WIP in queues between the steps is not always the right place to start.

Erik:Here's my question - what are the methods the Kanban Method suggests to manage flow besides managing WIP in the queues and work steps?

Note: I speak only for myself as a student of these ideas and not as a representative of any other individuals or orthodoxy.

The Kanban Method doesn't discourage looking for improvements in team structure or using MBIs to effect things such as batch sizes or WIP in the greater system. What it _does_ discourage is the installation of a set of pre-determined changes (even if those changes are a set of great practices highly likely to lead to significant performance improvement). The practices themselves are really not at issue -- rather it is their manner of introduction and the resultant impact on evolutionary capability.

An organization might mandate MBIs, cross-functional teams, Flow, and ATDD (and enjoy great benefits) yet find themselves less able to adapt quickly to future environmental and technological disruptions than a competitor who arrived at the same practices through an empowering series of experiments and discoveries. The latter org is more likely to have cultivated the sort of Evolutionary Change capability David Anderson writes about here:

It's hard for me to imagine this is anything new to you, who introduced me to Kanban and the Lean underpinnings of Agile in the first place, so I don't know if I'm creating much value here.

Thanks again.

Erik:This is becoming a pretty good dialog.  Comments is not as good a place for this and I originally had a message (I see i removed it) saying I preferred to have this on the lean-agile group - so I've moved it there - http://groups.yahoo.com/neo/groups/leanagile/conversations/messages/7676

please keep up the dialog.


For the sake of clarity/completeness for readers, another concept very closely related to ATDD & BDD is Specification By Example (SBE). When research one, be sure to research them all.


I agree that intra team dynamics are different from inter team dynamics , I believe intra team dynamics are improved on 2 tangents - social and technical
On a social level ,all the teams should clearly understand the goal of the project and have a shared sense of purpose - The concept of belonging to a community working on a shared goal
From a technical perspective it helps that the teams have a shared understanding of the architectural design and understand which part of the puzzle they are solving and how it interacts with what other teams might be working.

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