Mateusz, what was the most interesting thing that happened during the change? What was the most surprising?
I was expecting we would have problems with completing less exciting tasks such as testing, but that didn’t happen. Shifting the responsibility from individuals to the group gave space for everyone to work efficiently.

Also, we needed some structure and after we started working as a team we began to collaborate and everything seemed to fall into place. I think the main reason for our success was that the team members regarded each other as peers.

What's different now?
The biggest change is that there is no penalty for helping each other out anymore. The budget is relevant on the team level, but not on individual level, which means we can share problems and solutions.

One can clearly see what to work on now, and what needs to be worked on next. Tasks and impediments are clearly visible and are not being swept under the carpet.

Reducing the size of the team from 40 (whole company interacting semi-randomly) to 7 (Scrum team) makes it easier to work together, mainly because we get the chance to learn about and respect each others’ strengths, weaknesses and habits.

What is your day like now versus before?
Less stressful. It's possible to get more work done because we can focus on tasks and clearly see at any moment where we are in the sprint and in the project.

Folk wisdom has it that when you force a person's brain to focus on many things in parallel, their IQ falls considerably, and that's how it feels now - less chaotic, more intelligent.

What are you more more confident about now?
It's easier now to apply creative solutions and "refactor fearlessly". We have shifted from delivering at all costs to delivering high quality products up to capacity. Peer reviews, test coverages and testing by many people all contribute here.

It is possible to enhance how the team works both technically and from a process perspective. We can now build on top of what we have achieved in previous iterations because there is a "we" - a stable team.

What did you have to learn? What was the hardest to learn?
Not to tell people what to do and how to do it. It never worked well anyway. The other important ability is to be able to discern when is the time to say "no" to factors that would break the Scrum process.

How do you think you benefitted from working with a coach?
I've seen many of these Agile elements previously in different combinations and contexts, but never all put together.

A good coach will give you the confidence to apply all these principles now, immediately, and to achieve good result. Otherwise we would probably be stuck in the step-by-step approach which would stop halfway through and ultimately fail.

Pointing out the future possibilities is also helpful, showing that it's not the end of the road.

What's been in it for you?
There is more room for error and to try things out, hence more is possible. Short feedback loops and peer reviews provide a platform for learning and a cushion for failure.

Would you recommend Scrum and Agile to others?
Yep, without hesitation.


Conversations like these remind me why I love being an Agile coach. Whether the context or flavour is Agile, Lean, Systems Thinking, Scrum or Kanban (all very good things) - what it really boils down to is to make people’s working lives more enjoyable and purposeful and to create an environment where people are trusted to make decisions and have the freedom to succeed.

Mental note to self: Re-read this interview when I get frustrated with process, command and control and factory thinking.

Alex, what was the most surprising thing that happened during the transition?

Some of the surprising (although maybe obvious) things were that (1) it's possible for more than one person to work on the same user story, (2) work goes faster when people collaborate, (3) sprint planning that results in greater understanding of stories and tasks necessary to complete them really speeds up the work during the sprint - everyone knows what needs to be done and can pick up a simple task and complete it.

What's different now?

I love being able to see the day to day progress of the team - it's so visible on the board, plus the work seems to be going faster, with several people going through small tasks all the time. With the acceptance criteria being defined and discussed before the start of a sprint, and with the Product Owner being available to answer any additional questions and provide feedback throughout the sprint, there is virtually no possibility for any team member to go off on a tangent.

What are you more confident about now?

Talking to clients is easier now, as they are much more involved and ultimately responsible for making decisions about priorities. We (the team) make recommendations, share our knowledge and inform the client about pros, cons and consequences of the different options, but in the end it's up to them to make a final decision.

All along the course of a project clients know exactly where we're at, what's being built, etc., which they love. The transparency of Scrum, although scary at the beginning, is really beneficial for both the team and clients.

What did you have to learn? What was the hardest to learn?

The hardest thing to learn was to give up the control over what the individual team members were doing from day to day.

How do you think you benefitted from working with a coach?

Working with you has been a bit like going to the dentist - painful at times, but all along I knew it was good for me, and I'm in better shape now than I was before. It's been good to have you keep us on track, and point out things that now seem obvious, and yet were not at first.

Would you recommend Scrum and Agile to others?

Definitely. I couldn't imagine going back to the old ways, negotiating "resourcing" among Project Managers, developers being on several different projects at the same time, and not knowing when a project would end because of the uncertainty of developer availability.





Conversations like these help me put my work into perspective: They show me where I can improve as a coach and help me be a bit less perfectionist and appreciate that, even though we are not perfect, we have come a long way and I have helped make some people's working days a bit more fun and satisfying.

Next week I will talk to Mateusz Udowski., a developer at Silverstripe.

• Acceptance Test Driven Development/Specification by Example
• Jez Humble’s Deployment Pipeline.

Why is this a problem?

• Take away the focus from the real end goal which is delighting our customers (people who either pay for, use or support our application).
• Inadvertedly sub-optimise individual parts of the system such as e.g. design, frontend development or database design by isolating them from the whole product.
• Miss out on optimising the development of the whole product or project.
• Ignore the fact that software is developed as one-of-a-kind, which causes variety and makes predictive planning impossible. Honestly, stuff often gets finished either earlier or later than initially planned and there’s nothing we can do about it.
• Have difficulty absorbing this inevitable variety if resource utilisation is too high as people will either be idle or unavailable as a consequence of variety and lack of slack (This is bad for utilisation and people will either be stressed out and over-worked or bored. Also, no slack makes it difficult to deal with emergencies and opportunities).
• Run the risk of cascading delays within projects: If one part of the project is delayed dependent parts will be delayed as well, leading to a cascading effect.
• Run the risk of cascading delays between projects: Projects waiting for a particular person to come free will be delayed, again potentially causing a cascading effect on other projects’ schedules.
• Create an increased need for handovers between individuals. Handovers are regarded as one of the biggest causes of waste in software development and come with the added danger of losing valuable tacit knowledge. Handovers also often cause misunderstandings through ambiguity and are plain evil.
• Miss out on the advantages of working in teams. A well-functioning team collaborates to a level where the sum is way bigger than its parts. Well functioning teams create magic - much like the All Blacks on a good day.
• Make bad decisions: Without teams each individual on a project will only have part of the picture and it is almost impossible to make good decisions without knowing the history, background and reasoning behind all the other little decisions that have been made on the project so far. Also, diverse groups of people are usually superior in decision making ability to individual experts.
• Incentivise people to care about their particular part only, which leads to behaviours that are detrimental to the success of the overall system. For example, if I reward a football player for the number of goals he scores he will most likely engage in egoistic behaviour that damages team performance. The same is true for software development teams - especially if people’s utilisation is linked to their salaries.
• Waste time allocating and re-allocating people to projects and trying to get the impossibly complex and variable puzzle to work out.

What to do?

• Organise people into feature teams and give them the freedom to succeed
• Focus on improving the boundary-spanning handovers within the organisation (just as Mary Poppendieck says!)

Tags: agile , team, organisations, lean

We usually keep our checklists visible until the new workflow has become second nature and we don’t need reminders or memory aids anymore. Although, in saying that I realize that we created this particular checklist 6 months ago and we still like to have it around :-)

For us checklists are a very useful learning aid and workflow visualization tool, and as long as we decide on the processes ourselves we don’t feel they interfere with our self-organisaton.

Tags: checklists, agile, lean

Our cheat sheet

General guidelines

• The point is not to show that your software works but that it is useful and valuable
• Provide context and scenarios so that people can relate to features (role plays work great!)
• Don’t forget there is an element of show and entertainment. If people give up time every 2 weeks to come to your demo make it a good experience for them.
• No smoke and mirrors and never ever show anything that is not 100% done (see definition of done)

Our sprint review agenda

• Show what the team has built during the last sprint
• Engage with the audience
• Collect feedback

• Describe the sprint goal and why you chose it
• Explain why it is important for the project and for the company as a whole
• Give people context about where we’re at in the greater scale of things

• Tell the story of the sprint: How did it go? Did you have level 3 support incidents? (We handle those in a support work time box) Was anyone sick? New team members? Anything else important?
• Give a status of the sprint and an overview of which stories were finished and which ones weren't

Green check means “done”, red cross means not 100% done and therefore won’t be demoed.

4. For each story:

• The demoing team member shows the story description and describes the boundaries (explain the acceptance criteria without reading them out)

The story we are about to demonstrate

• Demonstrate the feature on a real system, in this case generate the report and show the result.
• Take questions and listen to feedback while you demonstrate. Remember to collect ideas for new features and user stories to include on the product backlog.

• Repeat step 4 for all user stories the team finished during the sprint.

5. Scrum Master closes the demo

• Wrap up and thank people for their attendance and participation
• Communicate the time and date for the next end-of-sprint review.

Some general Tips

• Audience participation and interaction works really well: If possible we ask audience members to play roles in our scenarios such as e.g. a customer who has lost his Snapper card.
• It is really important to prepare. We found out the hard way that it is a good idea to trial the demo before giving it to a larger audience to make sure it flows and that all the accounts, logins and data are set up.
• It is good practice to have the agenda visible on a wall or whiteboard at all times. This serves as a map of the territory we have covered last sprint. It is especially useful if some people come and go during the demonstration (our customer facing folks often do)

Where to from here?

Tags: scrum, scrum master, sprint review, show & tell

The “Kanban for One” board

The board, at Snapper known as “a Gina board” is used to organise personal tasks. The standard workflow is “Backlog” (stuff I want to/have to do), “Queue” (the subset of the Backlog that’s up to be worked on next), “In Progress” and “Done”.

The limited space for each of those workflow states imposes a natural limit on the number of items in each state, e.g. no more than 4 stickies fit into the “In Progress” area and getting more than 8 items into your “Queue” column is impossible. The lowest area on the board is either used as an expedite lane or for little inspirational messages and reminders.

The creator

Gina is the proud inventor of the Snapper Agile board. Unfortunately she has the least visually appealing board as she is stuck with an early version that had not received the benefit of several iterations of learning.

Spreading like a rash

Since people can place orders with Gina they’re spreading like a rash through our office.

Andrew with a board full of marketing tasks.



Sean, Head of Product, and obviously obsessed with the alignment of stickies.



The Product Owner’s wall


Reminders and ground rules on Gina’s board. I’m a bit confused about the haircuts though.


The Office

Conclusion

Tags: lean, kanban, workflow, agile

The Product Owner

In general the Product Owner ...

• is responsible for that the team builds the right product
• manages ROI and makes sure to deliver business benefits
• is responsible for that budget constraints are met
• is responsible for that what the team is asked to build is aligned with what the sponsor, stakeholders and users want
• provides boundaries to describe the realities within which the vision must be realised (e.g. time frames, external quality)
• makes sure management, stakeholders, sponsors are informed and the vision is aligned with their wishes

As a Product Owner you do ...

• Provide a vision for the product
• Communicate the project vision to the team
• Motivate the team to subscribe to the product vision
• Communicate the business benefits of the entire product and each individual feature
• Create and maintain the product backlog
• (the product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible that the work is being done and is being done properly)
• Continuously groom the product backlog
• Prioritise the product backlog
• Define releases
• Define release and sprint goals
• Continuously answer questions to add detail to requirements
• Accept/reject developed user stories at the end of the sprint (or during the sprint)
• Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting, sponsor liaison )

Here are some great resources I can highly recommend:

• Jeff Patton’s “The Product Owner and the Product Shaped Hole”
• Jeff Patton’s “How you Slice it - Agile Product Design”
• Bill Gaienne’s “3 Ingredients for a Great Product Owner” (10 min training video)

Tags: scrum, product owner, product manager, agile roles, agile

The Scrum Master role

 In general the Scrum Master ...

• makes sure the team is running (good) Agile development
• assists team members in adopting and improving Agile Development
• helps the team maximise throughput and to work in the best possible way
• protects the team from disturbance and external threats
• is a “servant leader” with no formal authority - all authority is granted by the team
• has no direct authority over Agile development team members but does have authority over the process

As a Scrum Master you do ...

• Remove impediments
• Facilitate meetings (sprint planning, retrospective, review, daily stand-up)
• Coach the team on the Agile development process and make sure the team improves over time (note the caveat “experienced”)
• Re-enforce good practises
• Challenge bad practises and habits and work towards their removal
• Make sure people do what they have agreed to do
• Make sure that the team follow the team ground rules they have defined
• Make sure that quality is a team effort and commitment to the “done” statement is taken seriously
• Provide transparency via the product and sprint backlogs, daily stand-ups, demos and a visible workspace
• Assist in reaching the sprint goal (help with story creation, testing, making coffee, etc if necessary - loads of ad-hoc stuff)
• Ensure that a collaborative culture exists within the team
• Support the Product Owner
• Improve the team’s engineering practices and tools
• Communicate, communicate, communicate
• Smile lots, make people laugh, and make the team feel that you are one of them not an outsider

Tags: scrum, scrum master, agile roles, agile

The idea

• Why? - The battery is dead.
• Why? - The alternator is not functioning.
• Why? - The alternator belt has broken.
• Why? - The alternator belt was well beyond its useful service life and has never been replaced.
• Why? - I have not been maintaining my car according to the recommended service schedule.

The plan

The execution

The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints.

It became obvious that, during the last 4 sprints, we had consistently bitten off way more than we could chew. While it is generally a good thing to strive for what is just out of reach and to improve though practice we thought the gap between attempted goal and real achievement was too big. We certainly didn’t want to lose management’s trust by over-promising and under delivering.

Therefore, we decided to focus on this problem for the remainder of the retrospective.

The problem

The first why: Too many stories are almost done

1. At the end of the sprint too many stories were “almost” but not entirely done (testing not finished, found a defect, etc)
2. Two of our team members had just gone from 50% to 100% and we overestimated the immediate benefit in terms of velocity

The second why: We are running mini-waterfall

The cumulative flow showed us that by day 4 most of our stories were in progress (yellow) but not many were actually completed (blue and green). Only 2 days before the end of the sprint the majority of stories were completed (blue) and then accepted by the product owner on the very last day (green).

This looked suspiciously like a mini-waterfall process where we first went though a development and then a testing phase.

The problem with any waterfall approach is that it forces feedback towards the end of the time box where it is hardest to react to. This is true for feedback on quality (through testing) and feedback on whether we have correctly understood the needs of our business and users.

The third why: We’re not doing tasks in parallel

The forth why: No TDD, test automation and stubbing

1. Lack of communication
2. Only partial TDD, test automation and stubbing
3. Lack of collective responsibility
4. Not cross-functional enough

The fifth why: We have an attitude problem

The solution

1. Ask for help when stuck
2. Accept help gracefully
3. Automate our regression testing (Flexmonkey/RiaTest), do TDD when possible
4. Make more use of stubbing and mocking to be able to develop the front and backend part of a story simultaneously
5. Hand over to the next person after finishing a task, i.e. don’t expect people to see progress from the task wall only; inform the rest of the team when e.g. the web service is finished or the story is ready for testing

My conclusion

• A 5-why root cause analysis can work amazingly well for a targeted retrospective.
• To avoid any danger of a 5-why retrospective turning into something like the Spanish inquisition it needs to be very well facilitated (Hallelujah for good Scrum Masters :-)
• A 5-why analysis with a group of people will produce a decision tree as there will be mostly more than one answer to each “Why?”.
• Voting to decide on which reason is the most relevant one and should be discussed works well and speeds things up.
• It made my day that I got the opportunity to try this ;-)

I wrote this to illustrate and examplify a retrospective technique that worked extremely well for our team. I think this was one of the best retrospectives I have ever participated in and I hope other people will give it a shot and share their experiences.

Tags: agile, retrospectives, mini-waterfall, root cause analysis, inspect & adapt, lean, kaizen

Tags: organisations, agile, failure, inspect & adapt, adoption, transition, scrum

Coping Mechanisms

Tags: agile, adoption, product owner, scrum

• For a user story or feature to be "potentially shippable" it needs to meet the expectations of the Product Owner and be of the agreed quality.
• The Product Owner’s expectations are phrased as acceptance test criteria. Acceptance test criteria are conditions of satisfaction specific for each individual user story. (For more on acceptance criteria read “On Acceptance Criteria”).
• The user story's (internal) quality is defined in the "Done" statement. The "Done" statement is applicable to all user stories in the project.

Here’s an example:

• I can purchase an album by VISA card
• I cannot pay with a VISA card that's expired
• I cannot pay with a VISA card with a wrong number

• 0 bugs
• Passed unit tests
• Passed automated Cucumber acceptance tests
• Passed cross browser testing
• Passed UAT
• Code peer reviewed (if not pair programmed)
• Relevant documentation updated

Tags: user stories, agile, acceptance criteria, requirements

What is in the release sprint?

• Work that couldn’t be performed every sprint because it was too time-consuming and/or expensive (e.g stress testing, full regression testing, getting copy text translated)
• Work that is only needed when releasing to production (e.g. bundle software, send out release notes to ops team, send comms package to change management, move code through various environments)

What is a successful release sprint like?

• Independent of how much functionality we had developed and how "big" the release was the release sprint was always the same length (e.g. always 2 weeks).
• Everyone on the team had a 100% focus on getting the release out of the door. 
• We never developed any new functionality during the release sprint.
• Although sometimes unpredictable we made use of the task board and tracked our work with a burn-down.

• Sometimes, on larger teams (8-9 people), we were only a subset of the original development team but most of the team stayed on to help. (People who didn't work on the project did other work for the organisation such as e.g. R&D, "business planning", etc but that was not a project issue)

Tags: organisations, transition, agile

What’s the purpose of acceptance criteria?

• define the boundaries for a user story/feature
• help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements)
• help the team gain a shared understanding of the story/feature
• help developers and testers to derive tests
• help developers know when to stop adding more functionality to a story

What are good acceptance criteria?

• State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)
• Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
• Are relatively high level (not every detail needs to be in writing)

Can you give a good example?

• The rolling balance is displayed correctly 
• The rolling balance is calculated correctly for each transaction
• The balance is displayed for every transaction for the full period of time transactions are available
• The balance is not displayed if a filter has been applied

• I can see on MySnapper that there are pending credit(s) for my card
• I can choose which credit(s) to pick up
• I can see my new purse balance when I have chosen to pick up a credit
• I can’t top up my card or buy a pass when there are pending credits for my card

Where do the details go?

• The column heading is “Balance”
• The rolling balance format is 99,999,999,999.9 D/CR
• We should use a dropdown rather than checkboxes

Tags: acceptance criteria, agile, user stories, requirements

One of my clients is a small software development house that does custom development in the form of development projects for clients . I helped them to successfully introduce Agile (Scrum with XP) and both the team and business managers are really happy with it.

As they liked our methods of planning and estimating (story points and velocity) the account managers and sales team were discussing the options to relate story points to dollar values.

To explain why I think this is very risky and not advisable I wanted to give them some background.

“How big” vs. “How long”
Story points are units that are used to size a piece of functionality or work. Sizing in this case means that story points indicate "how big" a piece of work is. 
 
This is often confused with "how long" it takes to implement it but in fact "how big" and "how long" are very different things:  

• The "how long" is highly dependent on which developer is performing the work 
• The "how big" bears no relationship to who is performing the work

• We can plan ahead in terms of time: If a team normally achieves 10 story points pr iteration for a project with 100 story points we would need 10 sprints. 
• We can plan ahead in terms of budget: Given the number of resources on a project is constant we know the number of hours in an iteration and therefore the price of a sprint. If we know roughly how many sprints are needed in a project we have an indication of how much it will cost overall.
• We have managed to make estimates independent of who will be doing the work. Incorporating the "how long" into team capacity rather than the piece of work unit makes estimates independent of future work allocation. 

Tags: agile, estimates, story points, planning, requirements

Tags: agile, scrum

Tags: agile, user stories, requirements

There’s a saying in software development “If someone gets hit by the red bus ... “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project.

Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions.

But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money.

In this case one of two things normally happen:

1. The project goes on with fewer team members
2. The project gets canned or put on hold

Tags: organisations, agile, risk

Mingle has received a fair bit of attention lately and the latest version, 2.1, has just been released.

I’m quite happy with Rallydev but as Mingle is made by Thoughtworks themselves and the guys at Silverstripe keep raving about it I thought I’d better check it out. Also, as much as I like Rallydev and VersionOne - they’re both a bit weak on the usability side.

Below a list of what I like and dislike about Mingle:

Things I like:
1. Installation & Support

• Free web/phone conference with a Mingle representative to guide you through configuring the system after you have received a free hosted trial. Very helpful!
• A breeze to install the downloadable version
• Runs on all operating systems (incl. Max OSX, Linux and Open Solaris) and most database systems incl. Postgres

• It just looks nice and appealing
• Tasks can be completed with relatively few mouse clicks

• If you choose the scrum template the card hierarchy of sprints - stories - tasks is very intuitive and standard scrum
• You can create epics for your product backlog

• Given you’re willing to spend enough time playing with configuration settings and are inclined to learn Mingle’s proprietary SQL-like language you can configure the tool to fit exactly your needs. Hell, you could probably even extend their JRuby ;-)

• Mingle contains a fully fledged wiki - great for sharing project information!
• All reports are configurable on the wiki

• As expected, very easily done from Excel (For switchers it’d be great to have an automated import/export to/from Rallydev and VersionOne)
• Great that it lets you preview your import before starting the actual import.

• Representing everything as cards is confusing: It does make sense for user stories, which in the physical world are written on story cards but using cards for releases, sprints and tasks seems forced and non-intuitive
• I don’t want to fit my mental models around a tool - it should be the other way around! Scrum concepts such as sprints and releases are a bad fit for Mingle’s generic object model of cards

• I miss the nice overview I have in Rallydev where I can see all my release and sprint dates
• Card trees fill quite a big part of the screen and it’s hard to get an overview at a glance (There’s another, smaller view but it doesn’t show the relations very well)
• Sprints and releases don’t have fields for start and end dates (I can add them myself by configuring cards but not adding them by default seems odd)

• There seems to be no standard way of getting started with a project quickly. There is no step by step process to quickly set up your releases, sprints, product backlog and user stories. Unlike Rallydev which guides you through with a pre-defined process and video documentation Mingle makes you figure it out for yourself.
• Mingle expects you to invest a considerable amount of time learning how to configure the system and how to make it work for you.

• There is no free SAAS version available (By comparison Rally Community edition is free for up to 10 users and Version One’s team edition provides similar functionality for free)
• Hosting Mingle on your own server is free for up to 5 users but I don’t want to wast my time installing tools and maintaining a server.
• The hosted trial for one project is great but only being allowed to keep the instance for 2-3 week is not enough for me to try Mingle on a real project and to make a decision to move all my projects from Rally or VersionOne

Tags: tools, mingle, rallydev, review, agile

• People on the team are not fully allocated and committed to the project
• You can’t stack a great team and only get the people that everybody else wants to get rid of (Give me some of the company “stars” even if it’s just to show commitment and get me agile personalities!)
• You don’t have the courage to let the team make decisions, to allow them to learn by making mistakes and to trust them to get the job done - you’re stuck in command control
• You don’t have a business person who has the time, courage and authority to work with the team and to make quick decisions
• You expect instant success and need a silver bullet (Sorry to be the one to bring it to you but if your project is impossible or if you don’t have good people no methodology or framework is going to help you ;-)

Tags: organisations, governance, obstacles , change, agile, scrum

1. Personality and work attitude - people who are solution oriented, like to deliver, like to succeed, are easy to work with, can communicate and just get the job done
2. People who like each other or have a chance of getting along, i.e. have respect for each other and can have fun together 
3. Absolutely no primadonnas: We can all be flexible and accommodate a lot but the lone genius who lives by his own rules just does not work (I usually remove them and I have never regretted it)
4. People who are confident enough to handle the visibility and transparency that come with Scrum

Tags: agile, team, personality, transparency, visibility

• UX people are driven by a holistic approach (big picture)
• Dev teams focus on iterative and incremental development

• Attempt 1: Concurrent IA, design and development
• Attempt 2: Upfront IA and graphic design
• Attempt 3: Post skinning

• We introduced an iteration (sprint) 0
• We de-coupled IA/user experience/graphic design from development

• done before development begins
• short (2-3 week) IA/user experience/graphic design only iteration to lay the groundwork
• defines “big picture” on which subsequent designs and not yet fully defined areas of the site will be based
• outcome 1: overall strategy for IA (site-wide elements such as page grid, navigation, rough placement of modules)
• outcome 2: overall design concept including site-wide design guidelines
• exact content balance between IA and design will be based on whether an IA or design led approach is used
• signed off by client (partial IA and design sign-off) and discussed with developer to assess technical complexity
• iteration 0 only covers fundamentals and potentially the details of the most important page. Details for other pages and areas of the site are still to be refined incrementally

• after iteration 0 decoupling IA/design and software development into two independent tracks
• tracks iterate separately but simultaneously and provide frequent feedback to each other
• the IA/design track feeds a refined design of the most important features/page(s) to the development track at the end of each design iteration
• the output from the IA/design track at the end of an iteration is used as input to the subsequent development iteration
• for the IA/design track to feed the development track the IA/design track needs to be ahead in time - ideally this would be one iteration ahead with minor refinements still possible during the development iteration (e.g. change an image)
• focus on potentially shippable increments of functionality to provide feedback opportunities for the client/users

Tags: user-experience, agile, scrum, web