Agile Web Design in an Agency: The PHX Renews Project – Sprint 1
We left off with an approved style tile, an idea of our content and our user stories created for this sprint. As we started (and all throughout) we reminded ourselves of the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
What we did
Again, the point of this series of blogs is not to show everyone how it should be done, but simply to show how we did it this time so that you might be able to find out what could work for you. That being said, here’s what we did inside of this sprint (of two weeks, made up of 3 days a week).
First thing on the first day of the sprint, we broke up each user story into different tasks we needed to complete. The sticky notes were color coded based on who needed to complete it (design, development or content).
User Story 1
With our tasks laid out, we got to work on user story 1, which was: “As a Phoenix resident, I want to view the history and vision to see what the project is about.”
I had written rough content in the planning stage and shared it with everyone via a Google Doc. So we all went into the meeting with text that looked something like this.
This gave us an idea of the “shape” of the content that would be included. Preston, our designer on the project, ran the wireframing meeting. We all sketched out our own ideas. Everyone was involved, not just the designer. The goal here was to discuss hierarchy and placement and how things change on different screen sizes.
Here’s a few of our wireframes.
After our five-minute sketches, each person taped their concept up and presented. We discussed, debated and then made decisions.
As we decided on the order and hierarchy of different content elements, Preston drew the pieces in more detail on the whiteboard.
Having everyone in the room was great because content could speak up if not enough space was being left for something. Likewise, development could speak to the difficulty and feasibility of some of the ideas.
In our old process, content worked in isolation creating content. Then design looked at the content to create wireframes and concepts before handing it off to development. This resulted in many questions and discussions at each step. We never felt like we were all thinking the same thing. After the group wireframing, there was a general consensus as to what we were building and why.
One of the biggest questions was how much design we needed to complete. The answer was “just enough”. We created Photoshop docs but not for the client to see. Just so we could make sure we were all on the same page before moving forward.
Here’s a little bit of the evolution of the design.
This was Preston’s first stab. This seems like a lot of design to just jump into. But really, this is just applying the style tile that had been approved (see this post) with the wireframes we had agreed on.
The photo of the Mayor looked a little like one that would be shown at a memorial service though. So we emailed his office and they sent us some better options. The background was also lightened so it matched the background of the logo and we flipped the image to the left side.
Rather than doing designs at every breakpoint, the design team and development team simply talked to each other about where it made sense to change something and how that should look, cutting down on the number of Photoshop docs needed.
There were a number of other small revisions before this was landed on, but many were made in the browser as it was coded with the designer right there to see how his decisions impacted the actual site.
Note also that we haven’t addressed navigation. At this point, there’s no reason to as we don’t have any other pages. As design is working on this, development is coding the main structure of the page and then different elements.
That’s more or less how user story 1 looked when complete. As development finished up that user story, we moved on to the next story.
It would be too much to show every user story and the steps we went through to get there. But here’s a quick runthrough of how the website progressed through the first sprint.
In the next step, we added a location module to the home page (still no main navigation).
Of course, this meant we needed location pages, which started out something like this:
And evolved into this:
Next up was the ability to contact someone at PHX Renews. So we created a page with contact info and a form to contact the right person.
And now we’ve introduced navigation, as it made sense for the contact page to be a main nav item. Notice that the location module is also on this page as it seemed to make sense here, too.
What we learned
As you’d expect doing something for the first time, we learned a lot. In fact, we could take up a couple of blogs with just that info. But here are some of the big things.
Collaboration is absolutely essential
You can read about collaboration all you want and it can sound awesome, but there’s no way you can be successful in an agile/scrum project with people who don’t work well together or respect each other. You need a lot of trust because…
It’s hard to show you’re unfinished work
For successful collaboration to happen, you have to get comfortable with others seeing your “unfinished” work. That’s something we all felt weird about at first but excited about at the end. I showed unfinished/rough content, the designer was always having to field feedback/questions on unfinished designs and then the developer was asking about how things worked as he was coding.
Some things aren’t included in story maps
As we proceeded, we realized there were things we hadn’t accounted for because they’re not really represented in the story map. Things like 404 pages, copyright notices, privacy policies and meta information weren’t really in the user stories we had created. Yet, it seemed irresponsible to not include them, even in a minimum product.
Our solution was to add many of them to our definition of done, but they could also be additional user stories that you add to your sprints. We’re still figuring this one out.
Not everyone will be on the project, all the time
It’s not really that surprising, but design, development and content aren’t all working for every hour of the sprint. In fact, development was really the only one working 100% of the time. Design and content finished up a bit early.
What we’re still working on
This is our first sprint, so we’ve got things far from figured out. Here are some of the most important things we’re still working on.
Scoping and estimation
We feel like we have a good handle on the story mapping exercise. However, as we mentioned there are some things that story maps don’t take into account. Also, as this was a small project where we knew what the client wanted pretty well, there might be more difficulty in future projects that are larger and not as well known.
Many of our clients are not in sunny Arizona with us. As much as we’d love to be able to fly out to them (or have them come to us), it’s just not usually feasible. One of our primary goals going forward is to figure out how this works with remote clients.
Also, one of our developers works remotely from Washington. Another goal is to figure out how we can make sure he’s included in our story mapping, daily standups and other exercises. Any tips anyone else has here are very welcome.
Scaling agile to other projects
We’ve already begun our second project that will be run through an agile process. A different team will be running it (with the help of the team that was on this project) and the project is much larger. Plus, this client already has a relatively large, functioning website. So it will be a good learning experience to see how this scales to our other projects.
This sprint is now live at phxrenews.org so check it out and let us know what you think.
We plan on continuing our documentation of this project as we move forward. We’ve got big plans!