Month / August 2017

by Frederik

Done!

Note: this post is based on the 2017 version of the Scrum Guide and has not been updated since.

The most crucial sprint objective in Scrum is to deliver a DONE product increment – a piece of working software delivering value for the end user. That is the goal today and always has been the goal.

In a context in which multiple Scrum teams work on the same product, it’s the goal – and only goal –  to deliver each (and every) sprint an integrated product increment – so no UNDONE work is left at the end of the sprint.

How do you define DONE?

Scrum does not define what “done” means for a product – that’s to be determined by the development team.

Yet the goal is to improve and raise the bar to deliver valuable working software at the end of each sprint.

With the support of the Scrum Master, the development team improves their practices at a steady pace to reach that goal.

The Scrum Guide describes:

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”

Unfortunately, many Scrum teams (or teams saying to practice Scrum) cannot deliver a done product increment at the end of each sprint. Some teams do not care and finish the work at the next sprint. In software development, this means a piece of working software (end-to-end) ready to be used by a customer (end-user).

The output at the sprint has been called a potentially shippable product increment. Some teams interpreted this as “the product increment is ready to be shipped, but there’s still work to do to release it to the customer.” That’s not the point.

That’s why the Scrum Guide describes:

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”

A lesson from Scrum history

Jeff Sutherland and Ken Schwaber, – Scrum creators- have updated the Scrum guide over time. It’s interesting to read how there were more details about what done means and what to do with “undone” work in previous versions of the Scrum guide. In general, some artifacts and pieces have been left out to make the description of Scrum as a framework simpler, more straightforward to understand, and lighter.

From Scrum Guide, version 2009:

A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.

You get the picture that “done” includes all the work necessary for a piece of releasable, valuable software at the end of the sprint.

It continues:

“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”

Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.

Take care. The current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. The only goal is to create a done product increment at the end of each sprint. In Scrum, this is considered a bad practice. “Undone” work piles up and increases risks and delays.

The word “undone” is no longer mentioned in the Scrum Guide’s current version.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) explicitly mentions “undone” work – in larger organizations. There are often whole teams (e.g., an “operations” team, a “services” team) or whole departments (“operations” department) or people (“release manager”) existing, which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).

A definition of “done” implies that each product increment is

  • valuable
  • immediately releasable to the end-user

And that should be the goal of “done.”

To be able to achieve this as a team, the effort is necessary to invest in:

  • software craftsmanship
  • automated testing
  • continuous integration
  • deployment automation

without sound technical practices, it’s pretty impossible to accomplish this on any scale (small or large).

Do not make a mistake. This is quite a challenge for many teams who (try to) practice Scrum.

According to the rules stipulated in the Scrum guide, all variants on Scrum that do not achieve the actual state of “done” product increments are not considered Scrum teams.

What does “done” mean in software development?

I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)

The result should include software that has the following:

  • Presence of valuable functionality for customers to use;
  • Absence of low-value functionality that must be maintained and sustained regardless;
  • Quality code base to predictably maintain and sustain;
  • Quality code base to enhance without undue effort or risk;
  • Ability to catch defects early and no later than at release;
  • Predictability of schedules; and,
  • A Lack of surprises.

This raises the question, what is quality software?

It has these characteristics:

  • I can readily understand the software and where & how things happen;
  • When I change or add to part of the software, there are no unintended or poorly designed dependencies;
  • I can read the code without looking for tricks or ill-defined and labeled variables or data;
  • I don’t need the person(s) who wrote the code to explain it to me;
  • Therecompletea full set of (automated) tests to check that the function works as expected;
  • When I change something and add to the tests, I can check that the entire change and product continue to work;
  • How things work and hang together is transparent;
  • Standard, well-known design principles have been adhered to.

Source: Quality, Done Increment

Keep on improving!

by Frederik

Agile Transformation is a strategy, not a goal.

I came across an article, “Transforming from Projects to Products.”

Excerpts of the article:

The general understanding and perception of “Agile.”

” ‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you ar.e reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.”

Each company or organization should be concerned with becoming more agile (as defined in the dictionary). This is a matter of sound principles and ‘common sense’ (for example, eliminating waste and becoming more effective in what you do – indeed, in software development/product delivery, there are many ways to achieve this).

What is the goal if an agile transformation is not an end goal?

Organizations shouldn’t embark on a mission to become agile without understanding what it takes in terms of cultural and organizational changes – and, most importantly, figuring out what they want to achieve – why do you need a change?

Questions to be asked:

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you (or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams, are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process?

As you notice, these questions which concern the whole organization. Any initiative for improvement should be looked at globally – at an organizational (systems) level – to avoid local optimizations.

  • What are the significant areas of improvement?
  • Transform from projects to products, including:
    • Stop managing and start leading.
    • Shift from “output” (deliverables) to focus on “outcomes.”
  • Embrace the idea there is (and will be) uncertainty instead of fighting it.

“Agile Product Leadership is about accepting the plan is likely wrong or at the very least unclear and the scope is unknown, and so adapting to change and building the right things to fulfil our customers’ needs.”

  • Reward people based on contribution to a common goal instead of individual performance.

Changing from:
“What will I do today?” to “What can I do to help the team towards our goal today?”
It can make a huge difference in behavior.

A common understanding of why we want to change as an organization

“Your business should be saying:

  • Where do we need to improve?
  • And how will we measure success?

Agile transformation may be a means of reaching that goal.

“If you choose an Agile Transformation you will measure success by delivering what customers need, by creating happy and satisfied customers not adherence to a plan. You will measure teams success by those that are willing to learn and grow.  By empowering teams to make decisions for themselves you can create an environment of continuous improvement.”

Read the full article at InfoQ.

and recall:

Image source: https://quickscrum.com/Images/article_detail/Whyagiletransformationisdifficult-1.png