Scrum

The Power of Checklists

The Power of ChecklistsSurgeons, astronauts, airline pilots and software professionals. What do all these people have in common? Well, for one, all of these professionals are very highly trained – in most cases in takes many years to reach a point where you can practice without supervision.

But even highly trained, experienced professionals can have a bad day, and make the occasional mistake. The problem is, if you’re an astronaut, airline pilot, or surgeon, and you make a mistake, lives can be lost. Software development, perhaps, is somewhat less life-critical, most of the time.

Simple checklists can help reduce human error dramatically. Some reports suggest that surgical checklists introduced by the World Health Organization have helped reduce mortality rates in major surgery by as much as 47%. Neil Armstrong had a checklist printed on the back of his glove (pictured), to ensure he remembered the important things as he made history as the first person to walk on the moon.

So if checklists can save lives, keep aircraft in the air, and help take people to the moon and back, why not utilize them to keep software projects on track, and help maximize the delivery of value, and minimize the risk of project failure?

Checklists help highly trained professionals focus on, and remember, the stuff that is important, and critical to the success of the endeavor they are working on. Unlike traditional process documentation, checklists are, by definition, lean, light and concise, so work well with agile development. The point is that they don’t burden a professional with lots of extra things to remember, or try to be prescriptive about how things are done – experienced professionals can generally be trusted to do the job properly, and make the right decisions when circumstances demand it – a checklist simply acts as an “aide-memoir” so nothing vital is forgotten.

So what does a software project checklist look like? Fortunately, some smart people have already done some work in this area, identifying a core set of checklists that can be applied to any software project, regardless of practices being applied, life-cycle being followed, or the technology or languages being used. They have been particularly effective when used in conjunction with agile approaches such as Scrum. These checklists are available in card form as Alpha State Cards, or as an iOS app.

You can learn more about the checklists by attending this free webinar.

Your feedback is welcomed!

Story Points, Lean Principles and Product Development Flow

A “story point” is a unit or measure which is commonly used to describe the relative “size” of a user story (an agile requirements artifact) when it is being estimated. In many cases, a fibonacci sequence of 0,1,2,3,5,8,13,21,... is used during the estimation process to indicate this relative size. One of the reasons for this is to increase the speed in which an estimation is derived. For example, it’s more difficult to agree on the differences between a 5 and a 6 than it is to agree between a 5 and an 8.

It is very common for agile teams to use story points to describe the “level of effort” to complete a user story. That is to say a user story estimated at 5 points should be expected take 5 times as long as a user story with a point of 1. On the other hand, it is also very common for people to include effort, risk and uncertainty (or complexity) in the definition of a story point. That is an 8 is also 4 times riskier than a 2, 4 times more uncertain.

Mike Cohn has stated that it is a mistake to do this:

“I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity points.” I guess that sounds better. More sophisticated, perhaps. But it's wrong. Story points are not about the complexity of developing a feature; they are about the effort required to develop a feature.”

So what do we do with this?

In Donald Reinertsen’s groundbreaking work “The Principles of Product Development Flow” we get a clear sense about how “batch sizes” affect our product development flow. Without going into much detail, it is fair to say that story points describe the “batch size” of a user story. Web definitions define batch size as: “quantity of product worked on in one process step”.

Reinertsen describes some of the principles of how batch sizes relate to our product development flow. For example: Principle B1 “The Batch Size Queueing Principle: Reducing batch size reduces cycle time”. The cycle time is how long it takes, or, the level of effort to complete the story. Smaller stories equal less effort than large ones. This principle would support the story point as a relative unit of effort as Cohn would suggest.

There are other principles that might not be so supportive of this perspective.

For example, looking forward to the second batch principle: Principle B2 “The Batch Size Variability Principle: Reducing batch size reduces variability in flow” we beging to see some of the challenges in this as a “relative level of effort comparison” only. If we have significantly increased variability in the size of the story, should we still “expect” a “5” to be the same as 5 “1’s”? All we can really expect” is more variability. Increased risk, schedule delays, unknowns are what we should “expect”.

Let’s look at a few more principles.

B3: The Batch Size Feedback Principle: Reducing batch size accelerates feedback.
In our scrum processes, for example, because of B1 (increased cycle time) would mean that the product owner doesn’t see the work product as quickly, and, in some cases, begins to lose faith or worries and increases pressure or interruptions of the team. Fast feedback is cornerstone to agile and product development flow.

Large batches lead to B7: The Psychology Principle of Batch Size: Large batches inherently lower motivation and urgency. We like to see things get done, it makes us happy. As humans it takes us more time to get on with a huge job, but a simple one we might just knock out and get on to the next one.

Very little good comes from large batch size as it relates to product development flow. There are 22 Batch Principles and they are all not too supportive of large batch size.

For example, some of them are:
B4: The Batch Size Risk Principle: Reducing batch size reduces risk.
B5: The Batch Size Overhead Principle: Reducing batch size reduces overhead.
B6: The Batch Size Efficiency Principle: Large batches reduce efficiency.
B8: The Batch Size Slippage Principle: Large batches cause exponential cost and schedule growth.

And so on. Large Stories are bad. Really bad. So, what can we do about this in our agile software development process? The most important thing is that we can not “expect” an “8” to take 4 times as long as a “2”. The “Principles of Product Development Flow” tell us that this is impossible.

We need to understand that, regardless of the size, they’re estimates, and not “exactimates” as The Agile Dad says. We need to accept that our estimate of a larger story is less accurate than our estimate of a smaller one.

We need to understand that, since we can not commit to an unknown, it is unrealistic and violates our lean principle of respect for people to ask them to commit to large stories.

We need to understand how batches affect our queues, our productivity, predictability and flow. We should study and apply product development flow.

We need to understand that we’ll do better in our flow if we have smaller stories, so learning the skills and breaking down stories into smaller sizes will help. We may never allow anything larger than a “5” for example, into a sprint.

With that said, if we have “8”’s in our backlog that (for some reason can’t be broken down into smaller stories) we should compensate in our velocity load estimates for stories in a given sprint. For example: If we have an estimated velocity of 20 and all we have are stories that have been estimated as “8”, we might want to schedule only 2 of these stories in the sprint, leaving us some capacity margin for safety.

One thing to note, however, is that, smaller stories might not be the best solution for geographically disparate teams, according to B17: The Proximity Principle: Proximity enables small batch sizes. Where it might be more effective to have the remote team working on a larger story. They might break it into smaller stories for efficiency. We need to understand the economics of batch handoff sizes and balance our efforts accordingly through reflection and adaptation.

A Hammerhead Shark versus James Bond in Speedos

A  Hammerhead Shark versus James Bond in SpeedosI’ve often found that most of the questioning about the worth of agile tends to come from the Project Management community. That’s not a criticism on PM’s but an acknowledgement that for them it’s probably more difficult to see how this agile concept can work.

Traditionally PM’s have tended to need their eyes pointing in different directions – one on the day to day development activities of the team, the detailed planning and daily progress, and one on the bigger picture, the long term roadmap and strategic planning side of a project. And, unless you’re a Hammerhead Shark – this is always going to be a tricky feat.

The trouble with agile, or more accurately, the trouble with some people’s interpretation of agile, is that it can be seen as an excuse to just focus on the tactical side of planning which leaves PM’s wondering what happens to all the stuff their other eye is usually pointing at.

So does being agile really mean ignoring the high level strategic side of managing and planning a project? Will the scent of burning Prince2 manuals soon pervade?

Fortunately this is not what agile means at all – in fact Scrum, which we all know and love, is pretty keen to remind us that we should still do release planning, risk management, and all those important things, it just doesn’t presume to tell us how to do them (in much the same way as it doesn’t tell us how to breathe, eat, sleep or do any other number of bodily functions we should still be doing whilst we’re Scrumming). What we are left to figure out for ourselves, as fully capable agile dudes, is how to ensure that we can stay agile for the long haul, which means having a sustainable and scalable approach to agility.

So how does that work? Is it really possible to add the governance, compliance, risk management and high level planning elements of managing a project to an agile approach without losing the agility? (Let’s hope so, for agile’s sake, because it is clearly and undeniably necessary).

Well, yes, of course, it is possible – otherwise agile just wouldn’t work. But it has to be done in a certain way. Let’s face it – you wouldn’t send James Bond out in full suit of armour, a wetsuit, padded ski suit and a parachute every time he went on a mission. Not only would it be a tad cumbersome, it would also be unnecessary (given that sometimes he gets away with just a small pair of Speedos). What you would do is give him exactly the right amount of kit required for a given situation. The same applies to agile. What’s needed is exactly the right amount of governance, planning and compliance for a given project – no more, no less.

So hang on – what have we got so far? James Bond in Speedos and a hammerhead shark. Which one is the PM? Well in a way it’s both, and neither. Confused? Good. Me too.

And I guess that is the point. A PM’s job is not easy and while they would love to be 007 in speedos (figuratively) – agile, unencumbered, able to work quickly and focus on getting the job done, they still need that hammerhead with one eye on all the ‘other stuff’.

I don’t think we can ever get rid of all that ‘other stuff’. It’s necessary and important. But we can minimise it so that only the right amount of ‘other stuff’ is put in place and we do what NEEDS TO BE DONE, building up from a minimal set (should I mention speedos again?) rather than starting out with everything, including the wetsuit and the parachute. This then, in essence, is the key to disciplined agile.

The PM still needs and will always need to be able to look at both the strategic and tactical side of a project, but with this approach maybe they need be less of a hammerhead. With agile self-organising teams the tactical planning side of a project is very much a team effort and, along with release and sprint burn-downs, daily stand-ups and sprint retrospectives, the tactical management is much less of an overhead.

So maybe, now, a normal shaped head will do, with just two eyes and some kind of innovative mechanism that will turn that head, allowing the PM to focus on the strategic but throw a glance towards the tactical when necessary.

Or maybe I’m just sticking my neck out.

Learn more about lightweight essential governance for agile projects.

Read the article: Agile and SEMAT - Perfect Partners.

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.

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…

Scaling Scrum? by Ivar Jacobson

Scaling Scrum?

Scrum is excellent for lightweight management of small projects developed by co-located teams. However, it is not designed for large complex systems, or systems that build a SOA (banks, car companies) or PLA (product line architecture for instance Ericsson) or for large organizations with or without outsourcing. Moreover, Scrum is just one practice. You need many more to develop software.

But can’t we just scale Scrum? Scaling is challenging. In the 1970’s people tried to scale to ‘programming in the large’. Later people tried to scale objects to ‘objects in the large’ (mega-programming). Both never made it. Hundreds of books and even more papers were written on the subjects, but it didn’t help. Instead ideas that were scalable at their roots became successful such as components and objects. At Ericsson we never had to struggle with ‘programming in the large’ since we went straight to components and later to objects.

Why is it so difficult to scale? Explaining this is not difficult but takes a lot of space. Instead let me make an analogy. Suppose you have been able to produce a new chemical substance by using a test tube and a Bunsen burner and the new substance helps with an important problem. Now you want to produce tons of the new substance. Nobody would dream of industrializing the laboratory method by simply building a larger laboratory with hundred meter long test tubes and fifty meter high Bunsen burners. Instead a chemical process would be built in which you would not recognize the original method.

Now, why do we need to scale Scrum itself? Why not let Scrum stay the pearl it is. Treat it as one of your practices in your portfolio of practices also including for example practices for requirements to test, architecture, components. Scale by composing Scrum with other practices.

To the fathers of Scrum I would say: Please, don’t extend Scrum with all kinds of other practices such as use cases, user stories test-driven design, etc. and brand the whole soup as Scrum. Doing so will make Scrum heavier and it will threaten the survival of Scrum because of deficiencies in these other practices.

We help companies around the world to adopt Scrum. However, we don’t see Scrum as the center of all you need. Instead, the center is the practices you already have in your organization, the ones your people already have adopted. Replace them carefully with better practices – one by one. Scrum could be one of these better practices but not the only one.

Do you agree with this approach? Now, it doesn’t happen by itself. It is clear that a practice-based approach is what is needed.  We have been promoting and working with practices since 2003.  Now, even IBM and Microsoft have started to join this movement. And this is really good for the industry. It is very smart!

Yes, RUP is my baby by Ivar Jacobson

 I often get the question:  “RUP was your baby, but how do you look upon RUP today?”  In an interview a couple of years ago I responded jokingly: “Yes, RUP is my baby, but you know babies grow up and some of them need correction.”  RUP was created in Sweden under the name Objectory.  This was in 1987. 

 

Objectory was really new since its base could be used to describe all aspects of software development.  Our focus was to identify all of the rules that we use when we develop good software: what are good use cases, good components, good test cases, etc.  The literature in software engineering was totally empty in this space at the time. In order to do this we used object modeling to describe Objectory.  Now we could let the base grow forever – technically speaking.    Any company could make their own new process using Objectory.

 

Objectory became very successful.  It survived the merge with Rational in 1995.  The next version was named Rational Objectory Process, but after the success of UML, the name was changed to the Rational Unified Process or RUP as we all know it.  In the work of merging the two companies, the process content grew significantly.  However, hidden behind the size, our innovation of how to create a process base and the rules for goodness survived.  The crown jewels of Objectory had survived!

 

Thus, RUP is one of my babies.  The challenges with Objectory and consequently with RUP were serious. 

 

  1. Adoption
    Although our way of working in creating a process base was new and great, adoption became quite expensive.  To truly be successful with the adoption and consistent usage was to involve customization, mentoring and consulting which most customers couldn’t afford.  Thus the success rate was too low.
  2. Growth
    RUP was developed inside one company and all new ideas from the outside world had to be filtered by our own people and added to RUP.  It goes without saying that ideas come from anywhere in the world and by having a process be company owned makes it difficult to assimilate these great ideas.  The use of community much like what has been done with open source models would allow for continuous input and improvement.  This also allows for scrutiny. 
  3. Execution 
    All processes are paper-ware and often managed by people who don’t use the process.  This quickly becomes a problem in most organizations because the process becomes a religious document and not a realistic one.  This then has the effect that what teams do and what the process tells them to do is often not in synch.  And since the team is in charge (doing the work) the value of process becomes small.

 

These challenges paved the way for the agile movement.  The different agile methodologists have one thing in common: they hate RUP.  But that is NOT very smart. There are lots of good ideas in RUP.  Many companies have made the effort in adopting RUP and done so quite successfully.  This has provided them with a very competent staff and something to build on for the future.

 

However, “the baby needs correction”, and I and my company have done so.  The adoption problem is attacked by focus on the essentials and being light instead of trying to be complete.  We use cards and game boards to describe the process.  Moreover, you don’t need to adopt a complete process all at once, just adopt a practice at the time.  The growth problem is not a problem anymore, since we downplay big process and we make instead practices first class citizens.  Practices can come from any source including the RUP and much of the practice work we have done is in support of RUP adoption. Practices can be composed to create your own way of working.  Finally, the execution problem which is the hardest to achieve, is for the time being our little secret, but you are welcome to learn more about it by studying EssWork and EssUP. 

 

Trust me, this is very smart.

Page 1 of 212