Category: Agile design

YouAin’tGonnaNeedIt – YAGNI

YouAin’tGonnaNeedIt – YAGNI is an XP principle based on Hoares Law (or Knuth’s Law).

It broadly refers to gold-plating in code and premature optimisation, with regard to Capacity Testing.

The interesting fact I found out this morning was that Charles Hoare denied he ever said it. He did say:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

What Donald Knuth said was:

“Premature optimization is the root of all evil (or at least most of it) in programming.”

It’s always worth bearing YAGNI in mind, it sits quite nicely next to a KISS approach.

I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

Designers v Developers

The amusing Infographic created by Six Revisions:

Started me thinking about the role Scrum has in breaking down barriers between disciplines.

Scrum teams derive their strength and ability to deliver diverse projects by focusing different skill sets in to one team. The input of design or testing is similar to Pair Programming in that the developer works closely with a team member from another business discipline. Partners from testing, design or other areas are swapped in and out depending on the needs of the project.

Working as a designer in a Scrum team I work closely with the developers to achieve excellence in User Experience. The team has recently won an industry award for delivering outstanding functionality in a high-profile website. The award was achieved by the marriage of technical excellence and elegant User Experience.

The fusion of different disciplines in products such as Microsoft Blend, Adobe Flash and Xcode’s Interface Builder reflect the needs of an audience, which expects a good user experience in a product that ‘just works’. Agile software development breaks down barriers and encourages communication between team members, which helps us to produce great products.

The mythical ‘designer/developer’ or devigner that excels in both disciplines is just that, a myth. 
The strength of the Scrum approach is that it encourages developers to understand and get involved with the User Experience and designers to appreciate the technical excellence required to make a product fly.

It’s a party not a war – or do you disagree?

iPhone, therefore i am

The iPhone is rapidly becoming ubiquitous, (at least among the design community) as the only acceptable portable communication device. I’m currently experiencing my first adventure in interaction design for this fascinating gadget. My first step was to register as an iPhone developer and download the SDK on to my MBP (MacBookPro).The Software Development Kit consists of Xcode (like Visual Studio for MS development.) Interface Builder (sort of like Expression Blend for Silverlight development) and the iPhone emulator.

Just to dispel any myths – it is not possible to run the Apple dev environment on a Windows machine. I spent some time pursuing this idea and even if you get the Mac operating system Leopard running in a VM the Software Development Kit (SDK) will not work.I completed the Apple tutorial to create a screensaver style app, just to get a feel for Interface Designer and then delved deeper in to the Apple documentation.

The first thing to do once you’ve got all the software is read The Apple Human Interface Guidelines, more commonly known as The HIG.

There is also a summary available but you need to read The HIG first.

I’m looking forward to blogging about working with this platform and integrating it with our Scrum process. Do you have any advice for me?

I moved away some time ago from including design in the Sprint.

I’m glad to say that I was working with developers who understood the need for attractive useable sites and app’s. The form v function debate was often hotly disputed but with humour and in the knowledge that everybody was working towards providing the best possible experience for the user.


As the team matured I withdrew my design work from the Sprint to lighten the load on planning and focus the developers on pure development tasks. More recently I’ve looked in to adopting a css framework ( to streamline the design and UI process. As we move forward in to adopting the MS 2010 Scrum Templates I’ve decided to once more jump in to the Sprint and join the developers in estimating and recording time against my creative tasks.

I’ll let you know if it’s a liberating experience.

A round peg in a square hole

A round peg in a square hole

A designer’s role in the Agile development environment.

I have a unique viewpoint when it comes to Agile Design. I run a Scrum Team as a Scrum Leader and I also work with the team as a designer. With all implementations of Scrum there are inherent idiosyncrasies and on our team I’m it. I come from a design and marketing background and I’m sure there were some in the wider development team who did not see me as a good fit with the Scrum Leader role. The axiom that stood me in good stead during the development of my Scrum Leader role was that I knew from my creative work that:

“We are at our most free, when we are at our most organised”

Freedom comes from the ability to move forward without needing to worry about the intricacies of logistical process. Scrum is a past-master at oiling the wheels of the software development machine.

A List Apart – has a great introduction to implementing Agile for Design