Many people are afraid of “going Agile” because of things they’ve heard about it. Some of these are either outdated or just misunderstood.  For example, while many have heard that you shouldn’t document and there is no need to do design, I would not say those are Agile beliefs. However, there is quite a diversity of mindsets in the Agile space, some of which to our minds, isn't effective.  Since Scrum is still the most popular Agile method present, the mindset of its thought-leaders is still what many folks hear represents Agile. We present another mindset here that we think helps achieve agility at scale.  It is based on Lean-thinking.  Oddly enough (and fortunately), this mindset is fairly consistent with most folks who are considering undertaking an Agile transition.

Here are the main aspects of the mindset we feel be conducive to achieve agility at scale:

Culture and how to start. You must attend to your present culture.  Requiring new roles, new methods, new team structures may work in some organizations but if it doesn’t work in yours you may want to control the rate of change so that people don’t resist the transition.  This means you may require a start that is gradual and attends to the rate of change your organization can adopt. Otherwise, you run the risk of the developers just outlasting management as far as the transition is concerned.  Even if they embrace the change, if it doesn't work and they felt it was forced on them, future initiatives will be more difficult.

A holistic view is needed. Although teams do need to be given the ability to self-organize, it needs to be done in the context of how the teams will work together.  This must be set by product management looking across the product lines.  A bottom-up, team driven approach is insufficient to achieve cohesive teams.

Respecting people. All Agile methods respect people.  However, this must mean more than respecting their value.  It must also include respecting how they work with each other.  People are tribal in nature and teams must be organized in a way that recognizes this so that they can better work together.

Systems thinking is a cornerstone of Lean-Agile.   Most failures are due as much, or more, to the systems within people work as it is to the people themselves. We must set up good systems for people to work within.  We must have both good systems and good people. 

Workflow should be explicit and easily changed. Explicit workflow helps people understand what they are doing and makes improvement much easier.  This is not the heavyweight process of old, however. Rather, making workflow explicit means the teams discuss it with each other to make it clear what everyone is doing.  This explicit workflow is the team’s understanding of the best way to do their work and becomes the basis for change. The purpose of discussing your workflow is not so you follow it rigorously as much as it is so people understand what each other is doing.

It is important to look at the entire value stream.  Merely looking at the team is not sufficient.  Agile must include the beginning of the value stream – where ideas are considered.  Many challenges at the team level are the result of decisions well upstream of the development/IT groups.

Cross-functional teams are useful but not essential. The methods available to begin an Agile endeavor must include methods, such as Kanban, that can work effectively without cross-functional teams being present.  While you should definitely transition towards cross-functional teams if you don't already have them, having to start with them (as Scrum requires) is often risky and disruptive to the organization.

If you want more information on mindsets, take a look at Mindsets: Waterfall, 1^st & 2^nd Generation Agile.

For a complete roadmap to Enterprise Agility see our Lean-Agile Roadmap.

Alan Shalloway
CEO, Net Objectives