You are here: Home » Archives for Agile

Tag Archives: Agile

Poverty Over – A Case Study, Part 2 – Designing

Written by Andy Weir. Filed under Blog, production, project management, Review, work. Tagged , , , , , , , . 35 Comments.

Our Design stage for Poverty Over was a lot of fun. And fast!

We set out to explore the Look and feel of the infographic and how, in principle, it was going to work. However, it was not our intention to have all of the UI, buttons and micro detail of the infographic nailed down at the end of this stage. We intended to find a visual style, find the limits of the tech, marry the 2 together, and finish by writing a list of functionality that we could start building in the next phase.

Our Design stage was to be filled with rapid prototyping, with all members of the team around the same table. No distractions, focused on the questions we had posed from the ‘Think’ stage (How was it going to look? How would we represent the data? How far could we push the tech?).

We worked fast and without any design limitations. Corporate styleguides and other confining restrictions were ignored. Our designer, creative technologist and 3D animator worked closely together in these early stages and we experimented with colour palettes, finding the right sort of map and then the way we displayed the data.

We realised that the data worked best as a graphic device when it was displayed with differing heights of the country land levels. Poor nations were below sea level, developing countries above sea level. It felt like a nice metaphor for comparing growth and decline. We also realised that in order to show comparative data levels for all countries then all countries needed to be on display all of the time. Unfortunately this meant that an interactive spherical globe was not as effective as the flat map. We subsequently decided to use the globe concept in the intro sequence, which sets up the communcation and introduces the themes of poverty and change.

Here are some screen grabs of our various prototypes:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

We spent 6 days prototyping and at the end we had come to the conclusion that technically we couldn’t use 3d models that were output from a 3d programme. In the end we decided to use the flash 3d API and some custom code to extrude the world map and draw it in 3d.

We had also been trying to add a light source, shadows and textures to the map surface. However this was causing the infographic to seriously slow down in how it rendered and moved on screen. We weighed this up and decided that the user’s ability to interact with the data was more important than adding texture effects. We knew we could make the map look great with flat colour as well. We’d just have to work within these boundaries!

So after a prototyping stage of around 7 working days we knew the method of displaying the data, the view of the map we wanted, how we were going to do it and how far we could push the tech. We also had a completely off brand colour palette and were still unsure of what else we could do with the data! At the moment we had a very straight-forward play through of the history of the world. The next challenge was to contextualise it. Why did Australia jump into huge wealth in the 1850s, what was causing Venezuela to buck the Great Depression and leap forward in the 1930s? For the data to start telling a story, we had more work to do.

We knew we couldn’t actually plan all of this stuff up front – we just didn’t know how the data was going to look at that point. We also didn’t know how many filters we should have – how many could we add before it would start to be confusing and detract from the central message? And what was the point of them?

So, we launched into our build stage, with a plan… but only a plan for the most high value and high risk elements that we planned to tackle in the next week or so. Fortunately our way of working allowed us to do this and we knew that making too many guesses at this stage would be a waste of time.

Read more about how we faced these challenges in part 3 of this case study – coming soon!

 

Poverty Over – A Case Study, Part 1 – Thinking

Written by Andy Weir. Filed under Blog, production, project management, work. Tagged , , , , , , , , , , , . 200 Comments.

Yesterday we launched povertyover.christianaid.org.uk. It was a fantastic, yet challenging project to work on and over the next few days I’ll be describing the craft of producing this interactive infographic. I say craft because I truly believe that is what we do. We take an idea, whittle it, shape it and fashion it into something that makes sense in the digital arena. Something that the target audience will take meaning from and hopefully – share it with their friends – which was the goal of this website.

When BMB approached us with this brief we were extremely excited to be involved. Robin and I follow a lot of infographic blogs and from the outset we were enthusiastically researching these and looking for great examples of map based infographics. The thought of being paid to create infographics that moved and reacted to data, time and various other filters was very appetising.

From the outset, the data we were to display was clearly defined. For each of the existing 285 countries of the world, a statistician had put together a 500 year history (where possible) of their relative poverty or wealth. Read more here for how these figures were calculated. We were supplied a figure from between 0.1 and 1.0 for each country for every year. It was our job to make this look beautiful, allow people to explore the data in an interesting way and highlight the following key parts of the story:

1. The world has, on the most part, moved out of poverty especially over the last 60 years.
2. There are however vast parts of Africa and Asia that still have a a way to go.
3. Countries that have been extremely poor before they’ve come out of poverty.
4. With further investment, development and aid – it is possible to move the countries remaining in poverty into prosperity.

Initially we looked at many influences and considered lots of different directions for how we were going to start representing the data. We loved Aaron Koblin’s work (Robin blogged about his show at the V&A last year here) and whilst we respect what he does, we quickly realised that we needed to be extremely graphic in our communication style – which was probably quite far removed from Koblin’s work . There were quite a few variables in our brief; wealth, poverty, maps and time. We needed to be single minded in our approach to how this was represented. Here are some of the approaches and influences we looked at:

 

 

 

 

 

 

 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Carl and Simon – the most excellent creative team at BMB had also researched many different types of maps (this is a whole cartographic language on it’s own). They provided us with some great books like this one.  We were able to find inspiration from many examples here – but also it started reinforcing lots of map do’s and don’ts!

Initially Carl and Simon were extremely keen to represent the data as a globe that the user could spin around themselves. We knew that until we actually started experimenting with the data and the visuals that we just couldn’t be so conceptually ‘nailed down’ just yet. To their (and the BMB producer Tyrone’s) credit they allowed us to be pretty non-specific with how we were going to display the map at this stage. We entered our prototyping phase with gusto, knowing that the team were in for some serious experimentation!

Any period of prototyping needs to have some clear questions to answer. We had three:

a) What was the infographic world going to look like? Was it to be a globe, a flat map, a 3/4 view?
b) How would we represent the changing HDI value? By colour? By the size of countries? By height or behaviour?
c) How far could we push the tech spec? A world map, with all of the country borders etc has hundreds of edges. If we are doing something in 3D how was Flash going to handle all of the interpretation of the data on the fly and then rendering it as 3d values. Should we use Papervision? Away 3D? Should we use 3D models from 3DStudio Max? What could we get away with before it fell over?

We finished our ‘Think’ stage of the project knowing that we had only planned the project in terms of the objectives and the potential of the raw data. Now… looking at the project from outside eyes, this might sound a bit irresponsible and lacking in “traditional” planning techniques, after all it might appear that we had simply created a list of questions based around look and feel, style and technical possibilities. We felt though that we had now fleshed out exactly what the website needed to communicate and we were now in an extremely good place – our Design stage was ready to go.

In my next blog post I will describe how we prototyped and started working out a visual style for the infographic.

 

Poverty Over – An Interactive Infographic

Written by Andy Weir. Filed under Blog, production, work. Tagged , , , , , , , , , , , , . 39 Comments.

Poverty Over

I’m really pleased to announce our latest work, in collaboration with BMB in London and for Christian Aid – check out povertyover.christianaid.org.uk.

In the coming days we’ll be blogging more about how we took this idea from scamp stage – right through to the finished product, to give you more of an insight into how we work. But now… back to the work.

The aim of the website is to show a history of poverty, illustrating that over the last two hundred years many countries have come out of poverty and have entered prosperous periods of development. Hopefully by showing that many countries can leave poverty behind, it will inspire you to invest in and develop the world’s remaining poor countries.

For WEIR+WONG – the challenge has been to visually interpret what was in effect a spreadsheet with 500 years worth of data for 285 countries. Our team of designers, developers and animators have come up with something which is genuinely compelling to look at, showing us a history of the world’s poverty and allowing us to delve deeper into the information.

In recent years there has been an explosion of Infographics on the web. Some of it looks amazing and communicates its data really well. However, there is so much of  it that looks great but is difficult to understand. The message muddled by the medium perhaps. I guess the most striking fact is that most of it is just really static. There are so many Jpegs or PDFs that warrant a first look but nothing more. We were really keen to be involved in an Infographic that was pretty, easy to understand as well as interactive.

We really enjoyed working on this project and hope that you enjoy looking at it too! The development process was extremely challenging and involved lots of collaboration from technologists, animators and developers in order to achieve this result. If you’d like to find out more, we’ll be releasing a series of case studies looking at each part of the project over the coming days, we hope you enjoy this, and we hope it encourages you to get involved to help bring poverty to an end.

Dedication. The only way to work.

Written by Andy Weir. Filed under about us, Blog, Future gazing, production, project management, work. Tagged , , , , , , , , . 19 Comments.

We’ve got lots of pretty big projects on at the moment, all quite varied and all for very different types of clients. We’re hoping to be able to share some of the stuff we’re doing very soon on this website, so stay tuned kids. Exciting times for WEIR+WONG! In the meantime, I have a fantastic and revealing insight into the way we are are working. I guess that nobody has ever thought about this before, let alone implemented it, so please hold on to your hats. Ladies and Gentlemen I give you……… dedicated resource. Tada. Booooooooooooooooom. I thank you.

At WEIR+WONG we have been working with some fantastic designers and developers. These guys are simply the best in the business. They uber-rock. We have allowed them to rock harder by simply giving them one job to do on a day by day basis. No daily interruptions so they can just have a quick think about ‘this other project’ or upload some changes for something they didn’t do in the first place. Robin and I are producers that like to protect our team from interruption, and dis-information.

Why is this a revelation? Because we know that from speaking to and working with other agencies resourcing is a nightmare usually based around booking up 1 hour slots. An unmanageable task for the poor resource manager and a false economy anyway. The way forward is one job, one day per any one person.

How do we do it? It’s quite simple really:

  1. We book resource per job and not based on a bunch of time that can be used up on a multitude of different projects.
  2. A morning scrum. What did we do yesterday, What are we doing today, What’s stopping me do it?
  3. An open channel of communication throughout the day with the rest of the team. Don’t go to the producer if you need a design asset. Speak to the designer. Remember that building complex stuff should always be a conversation between creatives and techies. If it isn’t then something is wrong.
  4. Limited interruptions from producers. Save them up for the next Scrum.
  5. A prioritised list of functionality and features. If you finish something early, get working on the next bit and don’t ask anyone for permission.

So what benefits have we seen. Lots. We can’t think of any negatives either.

  1. Creative people have the head space to think laterally and focus on the proposition and user experience. We don’t really care when, where or how they arrive at the solution. In fact we trust them to arrive at the solution, and we seem to be finding better solutions faster these days.
  2. Technicians and developers can get themselves in the ‘coding zone’ without interruption. We’re being delivered better, more robust code that is tested and clearly has had more love given to it.
  3. Client and agency feedback is turned around much quicker. We can react quicker to change and produce more robust and thought out solutions.
  4. People like working with us. Their day is less stressful.
  5. We like working like this. Our day is less stressful.

But I guess that everyone knows this already. It’s pretty obvious that dedicated workers can only be a positive thing. So what gives with my sarcastic take that this is a new insight. Well, if you aren’t doing it yet it is a new insight. And most agencies and production companies aren’t.

This can change. Believe.

How do you learn how to do stuff? Fail!

Written by Robin Wong. Filed under production. Tagged , , . 13 Comments.

fail keyboard

I was talking to someone new in the industry this week when they said that they were looking for ways to understand the ins and outs of digital projects and the many technologies that one could use.

Ideally they wanted a quick way to understand technologies like AJAX and Flash. Unfortunately I had to disappoint them.

Maybe there is a quick way, but I don’t know it. I’ve spent years prototyping, testing, reading, trawling through coding forums, reading and refining my bloglists on google reader, listening to selected tweets, attending countless meetups and forums and expanding my horizon in terms of new technologies. This has literally taken years.

What I can tell you, is that most people in this industry who have progressed in their careers have tried (and probably failed at) a lot of things, and probably from the point of view of a creative, a designer, a developer, a producer, an information architect, a tester and maybe even a client.

What’s key is that people take time to try things, review what they’ve done, looked at it from different perspectives and then try to understand why things have gone wrong if it hasn’t gone to plan. This approach allows you change your methods in the future and to be more mature in your planning (allowing for risk and contingency) and responsible in your change management (doing what’s best for the project and the end user).

Try it, Fail, review, learn to do it better! Then rinse and repeat.

When can change happen?

Written by Robin Wong. Filed under production, project management. Tagged , , , , . 24 Comments.

left a bit, right a bit
I just read an interesting article over on lifehacker about putting the brakes on ideas at certain times during the production process. You start a project, come up with some great ideas, focus on the best, start work on bringing those ideas to life, and then along comes an idea that you wish you’d have thought of in the first place. What do you do? Drop tools and replan? Ignore this distraction for now and address it at a later phase?

Well there’s obviously several schools of thought, but 2 things are clear. First, great ideas should never be dismissed, especially if they add more value to the end user. Second – and this is the counterbalance to the first idea – change is only worthwhile if it doesn’t reduce the overall value of what you’re trying to achieve. If changing course and incorporating a new idea means you can’t realise all the other great ideas you had because of all the extra planning and changes you’ll have to make, then clearly park it for later.

The next conundrum revolves around the question “when is it a good time to change”. For an agile project, I would argue that embracing change is a central part of how one approaches a project, but this does not equate to having carte blanche at any time to throw new ideas into the ring. For me, if you’re using a sprint model, then at the start (or possibly end) of each sprint, the team should evaluate their priorities and decide what is going to add the most overall value. Until the next sprint, the team should stay focused on achieving these priorities. Any ideas that pop up, can be parked until the end of the sprint, when they can be considered by the team again.

There will always be exceptional circumstances when this isn’t the case, and you may need to down tools to investigate if you should change course, but I believe those situations should be kept to a minimum. I’ve seen teams change course all too quickly mid-sprint, to the detriment of the project and the morale of the team. Waiting until the end of a sprint is often a short period of time, and if it doesn’t come soon enough for the impatient, try a shorter sprint on the next project.

Agile reading list

Written by Robin Wong. Filed under Reading. Tagged , , , . 26 Comments.

Here’s a collection of some great agile books, in no particular order.

Getting Real, by the guys at 37signals. This book is good at helping you to focus on real value-adding activities. Stay nimble, stay lean, work in short sprints, react to change quickly, and celebrate your victories regularly. They have a nice way to think about prioritising high-value low-cost activities first in a project – start with the UI, it’s going to have the biggest impact on user experience, don’t spend too much time on the back-end to start with, it’s likely to change. lots more gems.

Slack, by Tom de Marco, who wrote a similar book back in the day called Peopleware. A great view on how to best manage your teams to avoid burning them out and increasing their efficiency, the answer? give them some space to do their job. 100% utilisation is madness, I’ve seen people trying to claim it’s possible to plan this and yet still be efficient. Motivated teams with space to do the best job possible will produce a better product that is far more likely to lead to further growth. The flipside is that if you stack people with too much, they end up feeling like a hamster on a wheel, with no sense of autonomy, and they leave.

Agile Project Management with Scrum, by Ken Schwaber. One of the original founding fathers of Scrum, along with Jeff Sutherland. Essential reading for anyone interested in the subject. He does spend a lot of book trying to help you understand why scrum doesn’t work, but this is vital. In the end, it’s helpful when trying to diagnose if things don’t go to plan during a retrospective.

Agile estimating and planning, by Mike Cohn. This book goes hand in hand with the previous one, and gets into more detail on how to set up backlogs, prioritise, monitor burn-down and estimate touchdown for your agile project.

RetroSpecial

Written by Andy Weir. Filed under Blog, project management. Tagged , , . 22 Comments.

Retro PatternIn keeping with the Agile manifesto we’ve successfully had our first retrospective. At the end of week one for WEIR+WONG we looked through everything we achieved in the short time we have been up and running. We looked at what we had set out to do at the start of the week and then looked at what we had actually done. Pleasantly it has turned out to be a great deal more than we originally estimated. We now have a good idea of our burn down rate and can re-adjust our timings and planning this week. Over the weekend I was a little worried that the warm cosy environment of our local tavern and the drinks we were consuming to celebrate week one had had a rose tinted effect on my outlook. Happily however, its now Monday and I can confirm that after looking back we are in a great place going forward.

Using Basecamp

Written by Robin Wong. Filed under Blog, production, project management. Tagged , , . 18 Comments.

basecamp

I’ve always been a fan of basecamp, and I’m pleased to say that we at WEIR+WONG are using it. It’s great for collaborative working, mainly because of it’s simplicity and the flexibility it offers. But you need to be disciplined, it’s easy to get mixed up with how to classify each type of target. What’s allowed for a milestone? what do you classify as a todo list? how complicated can a todo be? How can you use this in an agile way? So where does one start? Clearly, there’s a lot of ways to play this, so this is how I approach it.

Capture

what I find handy to start with is to just capture all your ideas on what objectives you’re trying to achieve, working as a team to create your initial list of todo items. Unordered. Unranked. This allows you to see the basic universe that your project exists in. This is akin to creating your product backlog, to borrow from Scrum a little. You’ll find that you get a whole bunch of what I term as tasks (single actions, such as “write strapline”) and projects (a set of related tasks, such as “create designs for pages”), at this stage, leave these as they are.

Prioritise

Before you try and set deadlines and milestones, you need to work out what’s really important for this project, you need to prioritise your list and for this, it’s vital that you have all project stakeholders present. I rank by business value and risk. High business value and high risk items should be tackled first, so an action, or rather mini-project like “prototype unused technology” would fit the bill here, whereas “Translate copy for phase 2″ would not. Next I would tackle the high value-low risk, then low value-low risk, and finally low value-high risk.

Projects vs. Actions

Using my 1 task = action and 2 tasks = project analogy, you can then start translating your prioritised list into todo lists (projects) and todos (actions).

Team estimates

As a team, you can then take your list and start working out key milestones by estimating how much work you can effectively achieve in each sprint, or, if you’re not using sprints, each set of deliverables. I’ve found that this can be one of the trickiest stages for those new to the idea of team estimates, so it’s often handy to time-box this kind of estimation activity to limit the amount of detail you go into. You can always come back and readjust your estimates once you’ve found your teams project velocity. It’s also a doddle to move any todo item around the page in basecamp, so it’s not like you’re over-investing your time in changing plans. Don’t forget, don’t get hung up in the detail here, your time is better spent doing work that’s of actual value, re-planning needs to happen later as more facts come to light, so no need to sweat that your estimates may be a little off.