, , ,

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.

, , , ,

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…

, , , , ,

Agile – How to abuse it?

Many people have abused the term “Agility” by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:

Don’t document anything!

– The documentation that an Agile project produces is significantly different from what traditional projects produce. An Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.

Agile need to No planning!

– Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.

Just build something! (without capturing requirements)

– The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.

No control over budget or schedule

– Agile projects always operate within a “Time-Box.” That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, “We will deliver the greatest possible customer value within the project constraints!”

Developers come from wild west (doing whatever they want)

– The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.

If you see any of above signs in your team, it’s time to stop pretending and get real. Its time to seek help from an experienced agile coach. I would like to thank Alan Koch for sharing his thoughts.

, , ,


Capri shirtCycling from one of nature’s greatest feats, Niagara Falls, to one of mankind’s greatest feats, New York City, is no walk in the park. Capri Consulting is proud to support Small Steps on their 740.3 km voyage over 7 days through Canada and USA. The previous blog post describes only a few of the many great things the charity does for special needs children in Solihull. Here is a brief day-by-day account of the trip.

Day 1: After arriving at Niagara Falls on 2nd August, the group made final preparations on their bikes before they set off on their first day’s ride on 3rd August. They cycled from Niagara Falls to Buffalo, crossing the American border.

Day 2: The group cycled 112km from Buffalo to Olean. They started at 6am to avoid the midday heat. Day 2 saw some difficulties with many punctures due to gravelly roads.

Day 3: Day 3 was another early start as the group cycled 131km from Olean to Wellsboro. Spirits were still very high.

Day 4: The group cycled from Wellsboro to Towanda. With very hilly start the route was quite tough, but at the end of the day, 400 km had been completed and 340 km remained.victory pose

Day 5: The cyclists travelled 122km from Towanda to Wilkes-Barre with huge hill climbs and 5000 feet of elevation.

Day 6: The group embarked on their longest stretch of cycling of 138km from Wilkes-Barre to Stanhope.

The last leg of the trip was from Stanhope to Newark, just outside of New York. After such a long and strenuous trip, a sense of achievement was felt throughout the group as they went the extra mile in order to raise money for the Small Steps charity and bring a smile to the many children with special needs that the charity helps.

We at Capri Consulting believe that business and social enterprise should go hand in hand. We feel the responsibility to support charities that aid social welfare and we look forward to doing so in the future.

We would like to congratulate every team member and their families for their effort & dedication! Well done !!

twitter | facebook | linkedin | website