Nick Clare avatar

What does it mean for the enterprise to be agile?

What does it mean for the enterprise to be agile?Closely allied to establishing the business objectives in adopting agile practices, an understanding of what it means for an enterprise to be agile should be clear to everyone in the enterprise. This post summarizes what it means for an enterprise to be agile from the perspective of the senior executives and stakeholders.

“Agile” is a set of behaviors that help a business achieve its objectives. The most prevalent agile practice, Scrum, defines a set of project management-based behaviors that help practitioners (especially software practitioners) achieve those objectives. However, little is said in Scrum about how to be agile outside of the immediate environment of the Scrum teams. Team agility does not automatically engender enterprise agility.

Deciding where a so-called value chain starts and ends is going to vary according to the individual enterprise considerably, according to factors such as size, business area, degree of specialization, vendors and suppliers as part of the larger value chain (or even ‘ecosystem’). However, this is a bit like a “5 WHYS” analysis, you have to recognize where it makes sense to stop the analysis at. Mostly, a company’s corporate boundary makes a natural place to stop (though ideally the whole external supply chain would be synchronized and agile). However, this may be too great a challenge for many organisations to begin with, so smaller organizational units and business units within the enterprise may have to suffice for the initial vision and implementation.

As a reference point, for a hardware-based product company, the groups that might be considered for inclusion in the scope for enterprise agility could look like: Sales, Marketing, HR, Executive Management, Software Engineering, Hardware Engineering, Product Definition, Product Releasing, Product Testing, Technical Documentation, Project Management, Programme Management, Quality Assurance. Where any of these groups are excluded, there will probably be a detrimental reduction in overall agility.

Here are some of the major characteristics that an agile enterprise will typically exhibit, at the ‘manager’ and ‘senior executive’ levels (some apply more to some groups than others):

  • Commitment through close involvement and engagement with agile teams
  • Removal of organisational impediments and issues
  • Flexibly determining release content and being responsive to change: based on sustainable organisational capacity and economic value (including cost of delay); taking into account (test) results and feedback
  • Be Servant Leaders: inspire, motivate, lead by example: including: allowing teams to self-organise - “Self-organisation does not mean that workers instead of managers engineer an organisation design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviours that emerge from the interaction of independent agents instead of specifying in advance what effective behaviour is.” – Philip Anderson, The Biology of Business
  • Demonstrating trust, especially in avoiding delving into (and controlling) the detail: but note also that trust is engendered by successful delivery
  • Focusing on throughput of (valuable) work rather than on 100% Resource Utilization
  • Recognizing the differences between repeatable and highly variable knowledge work (avoid purely “widget engineering”)
  • Evolving legacy practices into new (e.g. by evaluating and challenging old Ways of Working): powerful corporate forces can be afoot, so this is not easy.

Leffingwell’s Scaled Agile Framework provides a suitable structure for scaling Scrum to enterprise levels and fills in on many of the executive roles and functions required for success in agile at the enterprise level.

Some useful links:

The Rudiments of Scalability

The Rudiments of ScalabilityWhat does scalability mean and when do you have to consider that?

The scaling of software and systems agility is still very much in the early stages of evolution, such that there doesn’t seem to be any clear consensus on exactly what is meant by scaling, or rather, where that starts and ends.

In this post, I’ll use Scrum as my “baseline” and reference agile way of working since that is by far my biggest experience, but you can substitute other agile paradigms.

Scalability in this context refers to the innate ability to apply single team-based agile techniques in successively larger and interdependent organisational units. I often think of this as having two dimensions:

  • Teams working on the same product, project or programme. Typically, one or two teams (and at maximum three) will work on a product owned by a single Product Owner, and Scrum works entirely native in that situation. But where several products within a project or programme have dependencies between each other, a degree of coordination is required between them to ensure overall project/programme/system integrity. This can be to minimise waste, for example in ensuring that dependent components are developed just-in-time for when they are needed (no sooner, and obviously no later). It can also be to satisfy technical dependencies (especially in component-based development teams), part of the very essence of project, product and programme development.
  • Teams working on disparate products but within the same organisation.It may also be highly desirable to be able to use broadly similar agile practices across many (or all) parts of the development organisation. For example, this reduces ‘learning curve’ overheads when teams are formed or rearranged. It also helps contain and manage the cost of operational and tool support in large organisations, an important consideration for any business, even though we should beware of the tail wagging the dog.

There is no question that Scrum can be applied to a large number of teams. In small products, projects and programmes, there are typically a “handful” of teams that need to collaborate and the original concept of Scrum-of-Scrums works perfectly well. To some extent, this is also further scalable, in both dimensions described above. Things start to get a lot more tricky however as you start to get beyond 6-12 teams. This is partly because there has never really been much in terms of detail of how Scrum-of-Scrums should work that I have come across, and that isn’t also bespoke to a particular organisation or scenario. However, it’s an even bigger headache in terms of how to manage an ever-increasing number of teams that need to ‘cross-coordinate’. Examples of Scrum-of-Scrum-of-Scrums (and beyond) have been tried and made to work (or so I have been led to believe) so this might handle a limit of up to 50 teams, at its best, but this is introducing hierarchies of ‘reporting’ and function that generally have pretty severe disadvantages too.

This returns me to the original question of what we mean by scaling agility. To many organisations, scalability to 50 teams would indeed seem ambitious and round about the upper limit. My experience has been with organisations like Nokia and Symbian, where we were dealing with a phone product development of 200+ teams, at peak. This can truly be called Enterprise Agility. Scrum-of-Scrums begins to look a little lightweight in this context.

Without some method of scaling for the enterprise, it will be pretty well impossible to achieve a coordinated system (or enterprise or system-of-systems etc) that always runs, that delivers value to stakeholders in small increments, that is responsive to change, delivers just in time (only) and minimises the Cost of Delay.

Unsurprisingly, businesses that I have worked with over the years have all placed great importance to the predictability of schedule and predictability of quality (whether they are using agile methods or not). After all, these characteristics are the basis of survival in an ever-increasingly fierce and competitive marketplace.

In a highly complex product being built using changing/emergent technology and having frequently changing priorities for features, it is still reasonable to set business deadlines based on forecasts of market need , economic value, and quantified Cost of Delay. It isn’t realistic to expect dozens (or hundreds) of teams to self-organise; it’s a risky approach almost bound to fail. The need for a way to combine Scrum with higher-level release and portfolio planning becomes vital if we want to preserve the benefits that agile can bring (e.g. small increments of value at product quality, fast feedback, ability to react to change).

Shown here is a picture summarising the model for scaling agility defined by Dean Leffingwell; you can read about in many sources including his blog. This was the basis of the model in use at Nokia. In a later post, I intend to talk about the details of the model with some modifications and minor enhancements we adopted. For example, the model allows for just enough planning (and at the right level) to be able to define the next release, and beyond in an increasingly less detailed way.

It quickly becomes clear that any adoption of scaled agile practices requires commitment from more parts of the organisation than small-scale Scrum does. This raises a number of questions for the enterprise aspiring to reap agile benefits. Some of these arise for any ‘size’ of agile adoption but require even clearer answers in an enterprise agile transformation:

  • Will all affected parts of the product development chain adopt agile behaviour? It is so often the case that, at best, senior executives endorse the practice of agile techniques, but do not consider that it is something that will (or even should) affect their own behaviour. It can be regarded by leaders as something ‘they’ do but obviously we, as the decision-makers, need not be constrained by its patterns.A little knowledge is dangerous (in the wrong hands). Having learnt that agile practices embrace change (changing priorities and product scope), there can be a tendency to assert too many changes on the development organisation and assume there is no associated cost at all. Some change is of course healthy but too much change (let’s call it ‘churn’) has a high cost and also is indicative of a business in chaotic mode.
  • What are the business objectives in adopting agile practices?
  • What does it mean for the enterprise to be agile?
  • What is the initial willingness of the workforce to become agile?
  • Will it be acceptable for the product architecture to emerge or is there a light (but significant) steering design required?
  • How should large product teams be organised? In sufficiently large and complex products, is it feasible to have feature-based teams, or does component-based teams become a necessity in practice?
  • Does the enterprise have an organisational structure that will support scaled agility? For example, how collaborative are those parts of the organisation dealing with system/product testing, requirements definition, code-line integration (configuration management)?
  • How robust are the underlying Technical Practices (for designing, building and testing)? Scrum itself quickly reveals flaws in how teams actually develop software, but these become magnified exponentially when scaling agile practices.

    In subsequent posts, I hope to tackle a number of these issues in more detail.

Iterative Sprint Planning

I’m encountering a recurring theme in my agile coaching. Some organisations have a sharp divide between their business and IT functions. This always spins off a twin-track coaching path for me: on the one path let’s try and address the fundamental root cause of the dysfunction/divide and on the other path what can we do to ameliorate and get around the problem in the short term?

So far my experience is that most of the symptoms of this issue are revealed via the Product Owner role. Sometimes business folks just don’t understand the basics of either software engineering or software economics. It’s just a simple inevitability of the organisation and experiences/skills their career paths have taken them on. So they can be experts of the business domain, but appreciate none of the pain and realities of software development. That is not a trivial problem to solve and will likely take a lot of effort and time. So in the meantime, what should we do to minimise the impact? Well, for sure, this is going to depend on all sorts of factors surrounding what exactly the problems are being created by having Product Owners with no software experience.

I’ll describe what I have found works quite well at one particular client in regard of one slice of this overall challenge: Sprint Planning.

The difficulty faced by the agile teams was that the allotted time Sprint Planning was always reached before any kind of commitment to the content of the Sprint was close. On closer examination, there were (as so often is the case) a number of contributing causes for this and all need attention. As well as the common issue of developers being uncomfortable with the relative sizing of backlog items without knowing almost every line of code impacted (they may have got bitten in the past), the thing that seemed most acute was the compounding problem of unclear requirement. With the lack of an empowered and embedded full-time Product Owner, it was perhaps inevitable that even well-formed User Stories were insufficient in getting a shared understanding of the requirement to the agile team(s). In this circumstance, we have used a Business Analyst as a proxy Product Owner with regard to backlog generation.

Scrum and similar methods describe the Sprint Planning event in some detail. They suggest a planning meeting of around four hours per two-week Sprint. There is also a recommended ≤10% allowance in the Scrum Guide for backlog grooming and refactoring by the whole team. By converting that ≤10% grooming into more structured events, we are finding it much easier to contain the planning to the suggested time boxes. The structuring consists of three iterative parts to Sprint Planning:

  • GET-AHEAD sessions. The proxy Product Owner meets regularly with business (and other stakeholders) to discuss upcoming requirements a Sprint or two ahead of when the requirement needs to be delivered as a backlog item/ User Story. By starting these meetings ahead of the Sprint execution, it gives the diverse stakeholder community the opportunity to address issues and questions raised concerning the requirement. Typically, this was left until the Sprint Planning meeting previously, giving no time for issues to be analysed and answers to be gathered. This not only gummed up the Sprint Planning, it also blocked the subsequent Sprint execution. The agile team need not be involved in the GET-AHEAD sessions (it isn’t an effective use of their time) – this helps reduce the overall amount of time that the team spends in planning sessions.
  • CONFIRM sessions. Once the proxy Product Owner has established the requirement to a comfortable degree, the backlog refactoring would continue by discussing the requirements with the team. By this stage the requirement is largely understood by the proxy Product Owner so whilst business stakeholder attendance could be useful, it wouldn’t be mandatory. Discussions in the CONFIRM session are generally more technical and where the Product Owner is not of a software background, this is of limited interest to them and not a great use of their time. Whilst the proxy Product Owner would be able to answer most questions that the team would have, sometimes more questions may be raised and these are taken back to the next GET AHEAD session (hence the process is iterative). Typically relative sizing of the stories (through planning poker) starts in CONFIRM sessions but not task decomposition.
  • COMMIT sessions i.e. the Iteration Planning Meeting itself. Once the major issues have all been resolved in good time, the team can confirm the story content and sizes, do task decomposition and estimation, then commit to the delivering the work in the impending Sprint.

By following this process in an iterative way (just enough planning in just the right amount of detail), we have been able to get much more meaningful Sprint Plans produced just in time. There is still some way to go to get this working in an optimum way, but we have reduced one major impediment and can now move onto tackle others…