, , ,

Should discovery teams be following Scrum methodology?



A few days ago, I attended a user researcher meet up session organised by the Register of Scotland. It was interesting to hear panel member’s experiences including dos & don’ts, insights, empathy, stories and of course free Jaffa cakes. This was an after-work meetup event and their interesting stories made me forget about my rumbling stomach.

During the question and answer session, it became very obvious that almost everyone in the room was involved in some kind of discovery phase. For readers who are new to the term “Discovery” – it is the time before you start building a service when you find out whether users need it and whether other services exist. This part of your project is called the discovery phase. (Read more about Discovery phase).

They were all facing a similar kind of challenge, convincing people that user research is a very important aspect of service design. And it needs to happen before you design any service or build any system or product. Then I heard someone mentioned that they are trying to fit the activities in a 2 weeks sprint cycle and are always under pressure to feed user stories or customer insight to the product owner to keep the story-hungry scrum team going.

Our experience:

We had a similar situation in a current project where the discovery phase was completed elsewhere, and our organisation was partnered to deliver an ecosystem which other similar government organisations can use. This was the alpha phase to build a prototype and prove technology selection. The partner organisation was kind enough to lend us an experienced user researcher and service designer who started working in tandem with the build team. They were involved in familiarisation, user recruitment and research, sense-making, journey creation, prototyping and conducting the usability tests. Soon it became apparent that these activities were dependent on the availability of external users to participate in the user research. Which meant sprint planning became unpredictable and meaningless and our daily stand-up meeting became chaotic.

I could totally relate to their challenge of not being able to feed the scrum consistently.  This caused loads of pressure for the discovery/user research team and a frustration, ‘feast or famine‘ situation for the build team.

So here is a question…. should discovery teams be following Scrum methodology?

What did we do?

We split the team into ‘User Need’ and ‘Build’ teams. The ‘Build’ team continued following the Scrum methodology but the ‘User Need’ team started experimenting with Kanban. This approach definitely helped the ‘User Need’ team to list their activities and prioritise them. We could see loads of post-its on the wall and hear telephone interviews but to date, there were no shippable outputs/outcomes. The User Need team still needed to review the information that had been gathered before the user stories could be written.

We decided to introduce monthly planning, retrospective session and show-n-tell ceremonies and run the discovery team a few sprints ahead of the build team. This allowed them to complete user research, make sense of their finding, design user journey and come up with wireframes. Enough time for the Product owner to define-prioritise-refine user stories and feed them to our code monsters!

I would like to hear from User Researchers, Service Designers, Product Owners and Agile Coaches about their approach in government or private organisations.

, , ,

Building A Walking Skeleton

This article talks about building a walking skeleton which is widely adopted by the Agile software development community.

Capri recently got involved with a greenhouse project to deliver a digital licensing system for Scottish Environment Protection Agency. There were few challenges such as team members were new to the agile way of working, new technology, new to cloud computing and tight timeline. Habitually team started analysing data model of CRM and building custom entity for storing data etc…….

The problem we have with traditional software development

  • Interfaces with various other systems (including legacy).
  • Teams not delivering working software
  • High risk due to dependencies
  • No early visibility of working software
  • Too many technical stories
  • No business value delivery in early sprints

These results in sprint failure and 

  • Frustration builds up
  • Velocity goes down
  • Project gets delayed
  • Project cost goes up

The simple solution to these problems is to start with building a walking skeleton

As per Alistair Cockburn a “Walking Skeleton” is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

walking skeleton


  • Mini implementation of the system that performs a small end-to-end function.
  • The walking skeleton is missing the flesh of the application functionality, incrementally, over time the full functionality will be added.
  • Its like building chassis with wheels and a motor which moves and adding body later on.

Not to be confused with Spike or prototype which gets thrown away

There are many advantages of building a walking skeleton first

  • —Upfront design/framework
  • —Quicker feedback
  • —Validate assumptions
  • —Proves architecture
  • —Quicker delivery
  • —Reality check
  • Reduces risk
  • —Manages dependencies

Get in touch with us if you need any help or download our slides by clicking the following link.

building walking skeleton

Happy Coding!

, , , ,

Why use Agile?

So Why Use Agile?

Just read an interesting article “Biggest UK Government Project Failures” by Matthew Hayhow. Today, the mainstream software industry has a poor track record; when it comes to delivering working software on time and within budget. It is widely reported that 80% of all software projects fail. What a disaster!

Source: http://www.softwareadvisoryservice.com/blog/biggest-uk-government-project-failures/

The Top 5 Reasons Projects Fail

When asked why their projects failed, managers and employees cited a wide range of issues. But these 5 reasons surfaced over and over again, as the main reasons why their projects failed:

  • Lack of end-user (customer) involvement
  • Poor requirements
  • Unrealistic schedules
  • Lack of change management
  • Lack of testing
  • Inflexible and bloated processes

Here’s how Agile addresses these problems head on…So clearly, with so many project failing, there’s Ota be a better way. And while Agile may not have all the answers for all the problems, here’s how Agile directly addresses these key issues:

The Customer Is King…

To address the lack of end-user or customer involvement, Agile made the customer a member of the Agile Product Team. As a member of the team, the customer works with the development team to ensure that their needs are met. The customer contributes to the requirements, approves the final result, and, is has the last word when making tradeoffs between which features are added, changed or removed from a release.

Requirements Are Written As Acceptance Tests Before Any Code Is Written...

To address the issue of poor requirements, Agile insists that you write acceptance tests before you write code. As requirements are gathered, they are defined as features containing one or more use cases with concrete acceptance criteria. The acceptance criteria is used to write an acceptance test before any code is written. That means that someone actually has to think about what they want before they ask someone to deliver it! This approach radically changes the requirements gathering process and dramatically improves the quality of estimating and scheduling.

Schedules Aren’t Assigned, They’re Negotiated…

To address the issue of unrealistic schedules, Agile makes estimating and scheduling a collaborative process between the Product Team and the Development Team. At the start of a release, the Product Team estimates the level of effort for a set of features. Then they ask the Development Team to review, revise and provide feedback on the estimates. The two teams work the estimates collaboratively until a reasonable schedule is achieved. Then everyone commits to the schedule and the work begins.

Nothing Is Carved In Stone, Except For The Delivery Date…

To address the issue of lack of change management, Agile insists that everyone embrace change, that everyone be realistic about change, and that anything can change except for the delivery date! In other words, as the product moves toward release, the customer (sitting on the Product Team) can add, change or remove a feature based on its priority and value. However, they have to be realistic. If they add a feature, they’ll likely have to take another one out, in order to meet the delivery date. And, the delivery date is always met.

Tests Are Written Before Code Is Written And Testing Is Automated…

To address the issue of lack of testing, Agile demands that tests be written first and that tests be run continuously throughout the build process rather than waiting until the 11th hour to punt some bad code over the wall; to a helpless test team. Each developer has to write their test first, then write the code to make it pass the test. The test is automatically run any time the code is changed. This approach makes testing the responsibility of everyone on the development and ensures the integrity of the build from the start of the project.

Project management is not a separate activity…

To address the issue of inflexible and bloated processes, Agile integrates project management into the process. The project management function is shared across the development team. For example, each 7 person development team (scrum) commits to a release schedule that they personally negotiate. In addition, the code base automatically generates project tracking information. For example, burndown, velocity and test pass-fail charts are all automatically generated by comparing outstanding tests with test passed and tests failed.

Agile is a profound step in the right direction…

As we said earlier, Agile may not address every software development problem, but it is a very profound step in the right direction. Based on the Agile Manifesto, it makes a serious attempt at addressing many of the key problems with current software development processes by empowering and respecting the people who are part of the process and by taking a pragmatic and realistic approach to the software development business.

To find out how you can become Agile, take a look at our Agile services…