It looks like most of the IA work (structure, wireframes etc) were designed upfront and handed over to the next team. Was that part of the project done in a more waterfall like process or was it seen as preparation or ‘sprint 0′?

What happened to the IA during development and were the IA’s part of or interacting with the development team to further iterate the IA?

I also don’t agree that agile forces a project team to LAUNCH work incrementally. It simply means that a team can CONSTRUCT work incrementally. Thus, agile can still happen in a big bang project. You simply collect all your agile sprints into the test phase, test as a collective whole, then push the button.

@Marius

I was effectively a UX team of one here so I did the IA and interaction design, working very closely with the visual designer (for UI) and the development team for functionality of the elements. This would occur on a daily basis, very much in a loose, iterative way of designing and developing simultaneously. So although wireframes were handed to both parties, decisions were being made around these documents as they were being worked from and we moved quickly, sometimes without further wireframe revisions.

So yes it was a Sprint 0, for some elements and then I carried on through subsequent sprints to check the new functionalities with the website editor (product manager). It was not optimal as a way of working, one problem we had was that we were located on several floors which meant a lot of protracted meetings. But under the circumstances, it was the best we could do.

@Holger

I too hold a love/hate relationship with Agile. Mainly as I am a big supporter of iterative design, and a development process that seems to be based on the cyclical nature of design is very interesting. However it does have limitations, mainly on the type of culture that it operates in. Some companies or organisations will never be able to build in a truly Agile way as much as they are incapable of utilising social media technologies. Unfortunately it is the nature of the beast.

Agile, like so many new ways of working, seems to require a course in change management before people rush headlong into it. Your fears about Agile are mirrored time and again in the clients that I work with. They like the idea but they feel they are on a train unable to get off. If it is not managed by a very empathetic project manager the client feels lost and out of the loop with a budget being spent on intangible elements they can not see.

Fragile is such a great way to put it, and there is definitely room to improve this area of Agile. It seems to need the UCD thinking more at its core to help bridge that gap between the concept and the delivery of the product. Agile is development and delivery focussed but it needs great communication and collaboration between people to produce quality results.

@Eric

I totally agree about the difference between launching and construction. This being a relaunch I highlighted the project in this context but as you rightly say, construction is the focus of Agile. Launching in a phased way was the initial ambition of the development team but it proved too much of change in technical architecture.

Regardless of whether your working in an agile context, I think there’s great value in the Boundary Spanner concept. It seems to me to be an excellent way of communicating the strategic importance of UX, from the perspective of project team effectiveness.

I also found your description of the deliverables do a good job of showing their value for a development team. Churn at pre-release becomes especially expensive when we are talking about a relaunch.

Together these help broaden the business value of UX, and shift it away from being some sort of quality assurance method with purely marketing value.

To replace a whole website in a big-bang approach isn’t anti-agile. In fact, you could achieve the whole outcome by using the same team, working collaboratively in parallel, working on a ‘skinny solution’ to replace the whole website, within 8 weeks. The focus after that would be to identify what users value most (through application of UCD techniques) and then add to the site incrementally in 2 week iterations.

UCD can also lead the assessment of the priority of features to be designed+coded within an iteration through collaborative work and I often see great IAs doing this through what you term here the ‘boundary spanner’. In agile-speak this is the job of the Agile Master who’se been there and done that and knows enough to be able to be the gel that keeps the team together, helps to identify impediments to the project and keeps everyone working to the Agile Way.

This sounds really interesting and glad to hear it works for you. It is dependent where you operate, but it is a really important matter to find the solution that is right for the context you operate in.

@Justin

The boundary spanner is actually the core message of this article that I wanted to get across and I am really glad you picked up on it. UX people are the ones who have the ability to bridge those roles in organisations that may be more traditional and subject to organisational structures that confine efficiency. We should strive to go beyond boundaries, reach out and collaborate beyond our remit as a matter of course. If we do this effectively and avoid the jargon (especially amongst the stakeholders) then business value is derived from our behaviour. I firmly believe this is the
differentiator between the usability guy and a person who will transform the product to a desirable or delightful experience.

@Matthew

The case study really highlights what occured within the confines of what we were able to operate in. Agile was the method of the development department. You are right in saying that iterative design is not agile, I completely
agree. Agile is a way of getting work done with a series of steps and methods that are clearly defined, taught to
scrum masters and stuck to rigidly in my experience.

I would say that iterative design happens in a different arena in a different mode in the development of the site. Sorry if this was unclear – but it is an important distinction to make.

I agree with your point of how it could be done, but that was not the reality in this particular company and that moment in time. The organisational make up of the business proved to be an impediment to developing the site optimally. This meant that the ‘Agile Master’ was not actually the boss of the team but the client of internal departments. The scrum was managed by another person, who led the development team. In this situation, there was no way that they would do any IA at all.

I have written about this recently (http://userpathways.com/2010/04/agile-and-the-importance-of-cultural-understanding/) and it would be great to have some feedback.

What you raise here is really valid, but this situation, called for this solution. It couldn’t be done in any other way – at that moment. It was not optimal but it achieved the brief in a manner that satsified both the users and the business.

Here’s another document by Desirée Sy (2007, also Alias) that elaborates on the parallel approach: http://upassoc.org/upa_publications/jus/2007may/agile-ucd.pdf

This parallel way to design and develop works really well when communication lines are clear and used frequently, if not it can go badly wrong very quickly. Hence the need for boundary spanners, or product owners who collaborate in all stages of the product’s creation.