Tags: sprint

9

sparkline

Wednesday, July 24th, 2019

Jon Aizlewood · Agile and design — How to avoid Frankensteining your product

Jon’s ranting about Agile here, but it could equally apply to design systems:

Agile and design is like looking at a picture through a keyhole. By slicing big things into smaller things, designers must work incrementally. Its this incrementalism that can lead to what I call the ‘Frankensteining’ of a digital product or service.

Thursday, February 21st, 2019

Design sprint?

Our hack week at CERN to reproduce the WorldWideWeb browser was five days long. That’s also the length of a design sprint. So …was what we did a design sprint?

I’m going to say no.

On the surface, our project has all the hallmarks of a design sprint. A group of people who don’t normally work together were thrown into an instense week of problem-solving and building, culminating in a tangible testable output. But when you look closer, the journey itself was quite different. A design sprint is typical broken into five phases, each one mapped on to a day of work:

  1. Understand and Map
  2. Demos and Sketch
  3. Decide and Storyboard
  4. Prototype
  5. Test

Gathered at CERN, hunched over laptops.

There was certainly plenty of understanding, sketching, and prototyping involved in our hack week at CERN, but we knew going in what the output would be at the end of the week. That’s not the case with most design sprints: figuring out what you’re going to make is half the work. In our case, we knew what needed to be produced; we just had to figure out how. Our process looked more like this:

  1. Understand and Map
  2. Research and Sketch
  3. Build
  4. Build
  5. Build

Now you could say that it’s a kind of design sprint, but I think there’s value in reserving the term “design sprint” for the specific five-day process. As it is, there’s enough confusion between the term “sprint” in its agile sense and “design sprint”.

Monday, May 21st, 2018

Architecting the uncertain - Getting started with Agile Software Architecture

Some ideas on the best of use of time in sprint zero of an agile project.

  • Understand your context
  • Identify risks
  • Understand the business process
  • Get testing infrastructure
  • Understand quality attributes
  • Get to know the people
  • Prepare an initial product backlog
  • Build a walking skeleton/spike
  • Build a learning backlog

Wednesday, December 7th, 2016

What design sprints are good for — Cennydd Bowles

Cennydd enumerates what design sprints are good for:

  • generating momentum,
  • highlighting the scope of the design process,
  • developing the team, or
  • provoking core product issues.

And also what they’re not so good for:

  • reliable product design,
  • proposing sophisticated user research,
  • answering deep product-market fit questions, or
  • getting the green light.

Sunday, March 6th, 2016

thoughtbot/design-sprint: Product Design Sprint Material

If you’re intrigued by the kind of design sprints I wrote about recently, here’s a handy collection of resources to get you going.

Wednesday, March 2nd, 2016

Design sprinting

James and I went to Ipswich last week for work. But this wasn’t part of an ongoing project—this was a short intense one-week feasibility study.

Leon from Suffolk Libraries got in touch with us about a project they’re planning to carry out soon: replacing their self-service machines with something more up-to-date. But rather than dive into commissioning the project straight away, he wisely decided to start with a one-week sprint to figure out exactly what the project would need to go ahead.

So that’s what James and I did. It was somewhat similar to the design sprint popularised by GV. We ensconced ourselves in the Ipswich library and packed a whole lot of work into five days. There was lots of collaboration, lots of sketching, lots of iterative design, and some rough’n’ready code. It was challenging, but a lot of fun. Also: we stayed in a pretty sweet AirBnB.

Our home for the week. This is a nice AirBnB.

You can read all about it in our case study. You can also read all about from Leon’s point of view on his blog:

I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project – all in the space of 5 days.

I think this approach makes a lot of sense. By the end of the week, James and I felt pretty confident about estimating times and costs for the full project. Normally trying to estimate that kind of thing can be a real guessing game. But with the small of investment of one week’s worth of effort, you get a whole lot more certainty and confidence.

Have a look for yourself.

Monday, February 29th, 2016

A 5 day sprint with Clear Left exploring library self-service machine software – Leon Paternoster

Myself and Batesy spent last week in Ipswich doing an intense design sprint with Suffolk Libraries. Leon has written up process from his perspective as the client—I’ll try to get a case study up on the Clearleft website soon.

This is really great write-up; it captures the sense of organised chaos:

I can’t recommend this kind of research sprint enough. We got a report, detailed technical validation of an idea, mock ups and a plan for how to proceed, while getting staff and stakeholders involved in the project — all in the space of 5 days.

Monday, February 8th, 2016

» The Power of Responsive Design Sprints

Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.

There’s a really good point in here about starting with small-screen sketching:

For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.

If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.

If you nail the small screen design, the larger sizes will be easy by comparison.

Wednesday, December 16th, 2015

CarbonGraffiti | When agile’s not creative

Jon writes about the difficulty of maintaining an overall design vision when you’re working to an agile methodology, slicing up work into sprints.

This pairs nicely with Mark’s recent podcast episode: On Agile.