Event notes from Agile War Stories held at ustwo

I went to the London office of ustwo to listen a panel talk about introducing agile to big business. I enjoyed the event, good drinks and food and friendly staff were around to chat. The panel was a good mix of people who worked with agile in startups, large organisations, government and traditional businesses that use waterfall.

Below are notes that I took during the panel discussions

  • Agile doesn’t have to be done strictly as one style, take the best
  • You are not agile or agile, you only become more agile
  • Adopting agile is not easy and it doesn’t guarantee anything
  • Changing how people think and work… Can be hard
  • Is agile for everyone? -> Yes but different personalities of people can require adjustment
  • Agile can be something that builds the wrong thing quickly
  • Q: What does agile means? Ability to change, communication
  • What is the least we can do to get most learnings.
  • The only certain thing is time
  • Agile requires building trust
  • Build it, show it. Then decide to either go forward or scrap
  • You are not locked to a bad idea/concept with agile
  • Workshops can help build trust at the beginning. Share your learnings by playing back to stakeholders

Pace vs quality

  • You can either be agile at the start or at the end.
  • Choose where quality matters
  • Do less better

How do you iterate existing vs delivering the roadmap

  • Deliver needs over features
  • What is the rationale for iterating? Value of it
  • Iterating has diminishing returns

Other notes

  • With agile your status my start in the red zone. This transparency helps reflect reality
  • How to start with agile: You don’t need to wait. Start small, ground up. Ground up hits a limit of adoption within organisation. To make agile stick, everyone needs to be involved

In the questioning period there was a discussion on how to manage senior stakeholders who have expertise and want to deliver their vision even if these features do not resonant well with users.

  • Take them along the journey
  • Use data and research to back up your decisions


Building things with user needs alone you can miss the big picture.  If you ask what people want then they want more efficient versions of reality. Instead of making a knee jerk reaction, we want to find out the why they want that – analyse their needs. Otherwise you could end up building the Homer car.



Multiple levels of done and design

The definition of done is core to agile but can you have multiple levels of done? I came across this blog article that expresses this idea.

Seems like if you don’t know exactly what you are building then this method works. With development you have clear criteria of what needs to be done but design can be more subjective. Not every task with the design process results in the same output. Sometimes it is exploration and it is the learnings that are results. Sometimes it is design assets and it is the actual assets that are the results.

How can you apply a single definition of done to such different outputs?

Most of the comments from the blog article didn’t agree with Mike Cohn (the author) but I agree with him.