Iterative

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.

The Achilles Heel of Agile

The Achilles Heel of AgileAccording to at least one source, Achilles, the hero of the Greeks in the Trojan War, was said to have been made invulnerable when his mother, Thetis, dipped him in the Styx, the great river of the Underworld, immersing all but the heel by which she held him.  From this we are given the expression the "Achilles Heel", which implies that something is not only a source of weakness, but that the cause of the weakness is also the source of great strength.

Agile has an Achilles Heel: the Product Owner.  The involvement of an empowered, knowledgeable, committed and engaged Product Owner is a source of tremendous strength and benefit of the agile approach; in fact, the Product Owner is the single indispensable person on the project, without whom nothing can be done. Like Achilles, the Product Owner seems to need to have powers beyond that of mortals: they must negotiate consensus with all the stakeholders in the business, they need to be almost omniscient in their knowledge of the business domain and the goals of the project, and they must be unfailing in their vision of the solution to be developed.  Oh yes, they also need to be available any time the development team needs them for feedback.  When presented in these terms, the Product Owner seems just as mythical a being as Achilles himself.

The reality, on real projects, is that it is almost impossible for one person to do all these things well.  If the Product Owner is a skilled negotiator of consensus among stakeholders they are not going to be in the team room all the time.  If they have a strong vision for the solution that vision is likely needed elsewhere as well. Visionaries also sometimes have a great "global view" but are sketchy on important details.  If they don't have a compelling vision for the solution they may vacillate or even flip-flop on important decisions.  If they lack important negotiating skills they may tell the team one thing only to have their decisions overruled later by stakeholders who were not involved.

The reality is that there is often no one person who can fill all the roles the Product Owner must fill. In these cases you will have to find different people to play different aspects of the Product Owner role.  The best Product Owner is probably one who can negotiate consensus, make effective and timely decisions based on that consensus, and be available on a predictable basis to work with the team (though not all the time). When she lacks understanding of the details of how something should work, she will enlist the support of the right people and get them engaged as needed. The grand vision is important but as long as it is provided by one of the stakeholders the Product Owner need not be the "big picture visionary".

The most important thing the Product Owner can provide the team is consistency, in participation, and in direction. If she can do that, she need not be some mythical hero. As long as the right people can be engaged at the right time, and as long as the guidance provided by the Product Owner accurately reflects the desires of the stakeholders and does not fluctuate over time, the agile team can make great progress toward delivering a solution that meets the needs of the business.

Warming Up to Agile

Warming Up to AgileSuccessful agile development introduces a lot of new things, or at least things that are often new to the people starting to adopt an agile approach.  Working with a backlog, engaging a product owner, and utilizing new techniques for planning and estimation often obscure the fact that in order to work in an agile way you have to be highly proficient at what we might call foundational software engineering. Some agile approaches talk about "sprinting", and perhaps this is a good metaphor.  Before you can sprint, you need to be in reasonable shape and you need to warm up a bit in order to avoid injury. Agile software development, delivering working, tested code in short time increments, requires some pretty solid skills in some specific areas. For the moment I'll focus on a couple of key areas we often find wanting when working with teams just starting their agile journey.

In order to develop in short cycles, let's say 2 weeks, you are going to need to build software quickly - certainly daily, and ideally continuously.  Concretely this means that builds need to be automated and executable anytime someone needs to do a build.  If you have to ask someone to do the build, and if it requires manual effort, you simply won't be able to build effortlessly. You need to be able to run a build without thinking about it, because you will have a lot of other more important things to think about.  If you're thinking about "going agile" and don't yet have an automated build capability, focus on that first.

Once you've got the build automated, you'll need to automate tests as well.  When we say that an agile approach focuses on producing working software, the evidence that it works is provided by tests. If you can't run at least unit tests every time the software is built you will never keep up with the demands on testing.  Realistically speaking, just automating unit tests is not enough; you need to be able to do integration, system and regression testing for every build, at least in theory, but unit testing is a good place to start.  In addition, all tests other than User Acceptance and Usability tests should be automated.  Building up from automated unit tests, you should be able to test everything in the system except the User Interface through programmatically-invoked tests.  If you don't do this, you will never keep ahead of the testing workload and your test coverage will remain weak.  If you don't have automated testing, runnable after every build, you will be able to "play" at being agile but you will never really achieve the kind of quality that you will need. At some point you will suffer from lack of testing and something important will blow up in production and that will be the end of your agile experiment.  As with builds, if you are not automating testing now you really need to get your testing act together before you get very far down the agile path.

While you're working on automating your builds, there is another skill in which you'll want to be proficient: refactoring.  There are a number of good books and web resources about this topic, but knowing is different than doing.  In short, you'll want to be comfortable with making significant changes in the structure of the code from one build to the next, done in concert with changes to the unit tests, so that the build and automated tests don't break from one build to the next.  You won't have the time to step back and do "big design" efforts, so you're going to have to get comfortable with making small changes that, over time, add up to big changes, all while continuing to do other development. This takes time and practice, and once you start sprinting you will either have to have it mastered or get good at it very quickly.

This leads to another foundational skill: source code management (SCM).  First, you need to use a source code control system to keep track of changes so that you can roll back to prior versions in the event you change your mind about an approach.  You need to be able to keep work that you are doing out of the build until everyone is ready for it.  You need to version everything, including unit tests.  Sometimes, when undertaking major refactoring, you may need to branch the code, and then merge it later once the changes have been proven. This is all really basic SCM, but it is essential to being able to achieve reasonable velocity and throughput for the team.  In fact, I've put things a bit out of order, because it's really virtually impossible to automate the build or refactor without solid mastery of SCM.

These are by no means the only things that you'll need to master in order to work in an agile way, but they are the foundations on which the rest of agile development is built. Teams that have not gained proficiency in these foundational skills need to focus on doing so before embarking further down the agile path.  There will be plenty of other new things to learn along the way.

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…

Potential Barriers to the Adoption of Iterative Practices

Understanding the potential barriers to change will help you make the right choices of timing, project, and approach. Some of the more important questions to ask include in the following:

  • How supportive is senior management of the change? The measurements and milestones
    they establish can easily derail an iterative approach, as is the case when they ask even seemingly
    innocent questions such as “When will the design be completed?” or “When will requirements be
    signed-off?”
  • What is the scope of your authority to make changes? How much of the development lifecycle
    are you responsible for? For example, the requirements might have already been specified in a
    format and to a level of detail that would make it more difficult to adopt an iterative approach.
  • What are the team’s feelings about the changes? How enthusiastic is the team about iterating?
    To achieve the transition to iterative development, you will need the support of the team,
    especially the other members of the leadership team.
  • What else does the team have to do? How many other projects and initiatives is the team involved
    in? If the team is not focused on and dedicated to the project, the transition to iterative
    practices will probably be slower and take more time and energy to complete.
  • What capability do you need to improve? It is important to understand the capability of the
    team and how well the current capability supports the proposed iterative approach. For example,
    is there any testing capability in the team? Testing will be needed from the first iteration, which is
    often a problem in companies organized around the phases of a waterfall approach. Read More

Progressive Thinking About Planning

The progressive, adaptive, iterative approach is founded on the following principles:

  • Proceed in small steps, continuing steadily by increments.
  • The plans must adapt to the project’s changing circumstances.
  • The characteristics that distinguish the product or service must be progressively elaborated.
  • They should be broadly defined early in the project and made more explicit and detailed as a better understanding of the project emerges.
  • Large projects must be broken up into smaller projects.
  • Requirements errors can be 100 times more costly to fix after deployment than at requirements time.
  • Initial estimates have a large margin of error—most waterfall projects cost two to three times what was initially predicted.
  • The first one never works; always develop things at least twice.
  • Initial designs will be flawed.
  • Requirements must evolve alongside demonstrable versions of the product.
  • Teams need to own and be accountable for their achievements and plans.
  • You should believe the project results, not the project plan.
  • Detailed planning should be limited to the next milestone.
  • Projects should adopt an active and aggressive approach to addressing project risk.

Progressive, iterative processes were developed in response to the problems inherent in the waterfall approach. Instead of developing the whole system in one go, an increment is selected and developed, then another increment, and so on. The selection of the contents of the first increment is based on risk, addressing the highest-priority risks first. To address the selected risk(s), select a subset of the requirements to be implemented and tested. Develop the minimal set of functionality that enables objective verification (through a set of executable tests) that the risks have been successfully addressed. Then select the next highest risks to be addressed in the next iteration, and so on.
One of the great ironies of modern software development is that in the paper that led to the popularity of the waterfall approach to software development, Winston Royce argued that projects should always go through at least two development cycles because the first version never works. He was actually arguing that projects should take a more incremental approach, not that they should adopt a prescriptive waterfall development approach. Progressive, iterative approaches take this principle one step further by splitting the lifecycle up into many smaller increments, each explicitly addressing the project’s major risks.

Attitudes Regarding Iterative Software Development Planning and Measuring

Attitudes Regarding Iterative Software Development Planning and MeasuringNowhere is the change in values of iterative development planning and measuring more important than in the management team. If the project is to iterate successfully, it must be managed iteratively.

The project manager must believe that an iterative approach is the best way to manage the project and must be prepared to set aside any inflexible, predictive, waterfall management practices that have been used before. This doesn’t mean that you should throw away all the good management practices and experiences you have built up over the years; good, disciplined project management is essential to the effective application of iterative development techniques. It is just that you must put aside some of the conventional wisdom about planning to give yourself the freedom to fully exploit the flexibility and power of the iterative approach.

The conventional approach to planning is prescriptive, based on the assumptions that the work which needs to be done can be predicted with great precision and that the unusual rarely occurs. This is true for many things—building a bridge over a highway or a standard family dwelling or a prefabricated commercial building, for example. These engineering efforts are technically predictable, and planning this kind of work is based on hundreds of years of experience. This experience has given rise to the generic project lifecycle in which the different types of project activities are aligned to the single phase that bears their name (i.e. Requirements, Analysis, Design, Code, Test and Deploy). Read More

Attitude Regarding Teamwork and Collaboration

Iterative projects often require fundamental changes to the way team members work on a project. On a traditional project, it is easy to avoid really working together as a team. Everyone tends to have their own specialty and deliverables, and it is easy for a person to work in isolation and only interact with other people by passing documents around.

Successful iteration is very different, and requires a very interactive, collaborative way of working, involving:

  • Commitment - The whole team (including business representative participants) needs to be committed to making the project a success. This doesn’t have to mean working long hours or promising more than can be delivered; it means just doing whatever it takes to work as a team and meet the iteration’s objectives.
  • Focus - The team needs to keep focused on the iteration’s short-term objectives and not get sidetracked by other issues or activities. This is particularly true of the management team members, who need to stick to the iteration’s set of objectives after they have been set and agreed to with the team. The time to change the project’s direction is between the iterations, not during them. Read More

Stimulating a discussion: Getting to needs

Stimulating a discussion: Getting to needsOne of the frequent questions we are asked is "how can I get the time to explore needs when the business says that it is already done - "it's in the business case", even when it is obviously not complete?  This is actually a pretty common occurrence - nobody wants to take time to understand needs because they think it has already been done. Read More

Attitudes regarding risk and change

Attitudes regarding risk and changeMost project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read More

Page 1 of 212