9h30 Ok, lets do the stand up!
Between five to 10 people promptly gather around the whiteboard every morning and give updates on their work, raise flags when they are blocked or when they need help who is to say that agile projects are chaotic?
For the past couple of months, I have been working on a long-term project that has been managed in an agile way, and have discovered many pros and some cons along the way. The biggest success, from my perspective at least, is to see how easily you can implement a user-centered design approach into an agile development environment if a few factors come together:
- There is a general understanding amongst the team members that producing a usable and pleasing product is a top priority.
- The analysis phase is not skipped in the process and time is allowed to really understand the business rules, users and their context of use.
- The user experience (UX) always works one or two sprints ahead while verifying work done in the previous one and discussing implementation questions for the current one.
Below is a diagram I created that illustrates the last point and explains how UX and development collaborate across the sprints:
Here is a summary of how the project has been going so far (from my perspective) and what tools we have used along the way:
At the very beginning, the UX, Functional and Technical track had to define what their approaches would be and how they would interact with each other. Since we came from different companies, we also had to get to know one another. What this meant for me was to explain what UX was all about e.g. not just delivering graphical templates, and, yes, I do need to be involved in Functional workshops as well! This set the framework for the blueprint phase of the project.
During this phase, I had the opportunity to spend time with users in different countries, interviewing and observing them in their working environment. Based on these visits, I created personas and scenarios in Visio, which I shared with the team and then hung up on the wall. They were quite lively because I had been allowed to take pictures and had created photo stories about their daily tasks. The goal was to promote a common understanding about the conditions and context of work, and for the development team to feel more connected to the actual end users.
I used Axure for the wireframes, a tool that allows you to create a clickable prototype and to simulate rich internet applications in a realistic way. This has been instrumental since our early discussions with the different stakeholders and has also allowed us to conduct usability tests early on. Sharing these wires online has also been a big plus, especially since they are quite alive and have evolved constantly over time.
Since this application was the first of several in the same family, it was important to clearly define user interface guidelines. Initially, I created these standards and rules in a wiki. However, I quickly realized that those pages were hardly ever consulted (except by myself). So I switched tactics and included specifications on navigation, buttons, tables, forms, error messages and alerts as an appendix to the wireframes. Having everything in one place is definitely easier for the team and gives more visibility to the UI standards.
As this is an Agile project, there are no functional specifications but only stories. The stories have been created and reviewed in JIRA (Greenhopper), as are the bugs and enhancements. I must say that this is the point I (and I think most of my colleagues) have had some issues with. The stories were often too short and out of context to see the bigger picture. There is still room for improvement in terms of refining the method and the tool used. It would be helpful to take greater care in describing the epics (above the stories), and structuring the information in a logical way which is not alphabetical or even by business value!
As to my daily update: Working on new functionality for next release, will give demo today at 14h00 - no major blocking points!