UX and Agile: Co-Mingling

Hi Friends!  It’s good to have UXSuccess back up and running after a hiatus.
Since I last blogged, I’ve contracted to a company as one of two UX resources for all of IT — the department that is responsible for designing and building and maintaining and supporting all of the logistics applications that keep this freight company up and running.  I am privileged to work with this team!  It is a really fun change to be working for a company that is not “hi-tech” too.  Fortunately I joined the team last July just at the time all teams were switching to the Agile development process.  It was great to go through training with the developers and BAs and to have Agile coaches that work with us.
While there are many project teams in IT — because there are many applications,  I am going to focus on the team I am spending the most time with now.  We are tasked with reducing the amount of paper our Truck drivers and dock workers use to track the movement and delivery of freight.  (Think about the hand held device your UPS guy carries now to have you sign off on when he delivers your packages).

As part of this training, I was introduced to the Agile project management tool: Mingle.  http://studios.thoughtworks.com/mingle-agile-project-management.

I thought I’d post some information about how we are using this tool to fold UX into the software development process here.  Since we’ve been through 4 iterations now, we are starting to get the hang of how we all work together.

This chart shows the relationship of cards to a project in Mingle:

mingle1

How cards relate to a project in Mingle

This chart shows where UX fits into the Mingle Card Status:

This is the card flow we are using for our Agile development process. See where UX has sign-off on cards

This is the card flow we are using for our Agile development process. See where UX has sign-off on cards

The goal in working with our Agile coaches was to provide earlier visibility to stories that require UX involvement and would reinforce the idea that
UX should  work more closely with the BAs and DEVs:

How this Works:

  1. (Process—UX responsibility)  UX monitors the BA tab to maintain awareness of upcoming stories that may require user research and notifies the BA if there are stories of interest. NB: We’ve established here that anything that relates to “front-end” is automatically tagged for UX.
  2. (Mingle update: “Start Analysis”) BA are prompted to flag the story that requires UX involvement (with help/input from UX analyst).  The flagged story will immediately show up on the UX tab.
  3. (Mingle update: “UX Design Sign-off”) Story that is flagged with UX involvement required requires “UX Design Sign-off”. The flagged story must be signed-off by UX analyst prior to BA marking the story as analysis is complete and ready for development.
  4. (Mingle update: “UX Development Sign-off” – The UX flagged story must be signed-off by UX analyst prior to DEV marking the story as Ready for QA (which will give the BA a chance do a cursory check to ensure what was developed met the business requirements).
  5. (Mingle update: “UX Required” field is made editable). The field is made editable and allows Mingle users the ability to update/set the flag as needed

Here is how this plays out in real life so far:

  • During Story Analysis : UX participates with the BA in needs elicitation from the user’s perspective to help write the story.  UX meets with the BA and the Clients (who are not end-users per se — but that’s another story)
  • The BA works with the business owners to decide what stories go in this iteration.  He then draws mock-up screens that are added to the story.  We are using a Wiki to hold these story pages, and link them directly to the story in Mingle. (We also use Balsamiq to do the mock-ups — that will be another post)
  • UX reviews those mock-up screens for best-practice as the developers review for technical viability – this is done through a story review with the team (try to take the form of cognitive walk-throughs here to keep team members on task)
  • When enough stories are complete in mock-up, they are linked in clickable prototype format so that our End-Users who participate in weekly revolving door sessions can test.  UX does a weekly report-out that includes story sign-off and stories signed off with these exceptions.
  • UX also participates in client story reviews at this time to get client feedback on the prototype
NB:  We are always working 2 iterations ahead of the developers here.
  • During Development UX does desk-side reviews as the developers are programming the UI screens.  We are learning a lot here — since our developers are doing the screen design — we have no formal designer on the team.  As the UX person, I am trying to extract “standards”  from the 6 developers and post those on a Wiki to try to keep the design consistent, repeatable and predictable.  This is our greatest challenge right now.
  • As soon as we can, UX brings the “happy path” click through on a device that has been populated with mock-data to the revolving door session users. NB: About revolving door sessions:  Generally these sessions always happen once a week with 6 users who have committed to a 30 minute time slot.  They look at both prototype mock ups and test the click-through tasks on the device.  Often I am working in 2 iterations with these users — sometimes my head spins!  I will write about these sessions in yet another post-
  • When enough stuff has been developed so that we can get end users on a device to walk through a task in the context of how they would do it — not just following a “happy path” we do a more formal review with users out in the field — drivers and dock-workers. This gets us locked down, UX will sign off, and then we go to QA.
  • During QA UX review stories and defects and adds cards as appropriate.  We partner closely with QA to make sure that the integrity of the UX is maintained before we go to client sign-off.

We are making good progress.  We don’t claim perfection.  I would love to hear other stories and experiences to bring to our team.  What works for you?  What is not working?  What resources are available?

2 thoughts on “UX and Agile: Co-Mingling

  1. Great post, Julie. We’ve been using Mingle at my company for 4-5 months now, and we’ve finally gotten to a point where we have a pretty good shared understanding of how stories flow through the various states. I think we are doing roughly the same process you describe here with one major difference: we aren’t separating out UX from the BA role. The way we’ve been working is that the BA is the one responsible for user research/testing, functional specification, UI design, and scope definition (w/ the POs). That’s typically the role I’ve played at other companies, so it’s fairly comfortable for me to handle all those different aspects. However, what I’m struggling with in our process and been trying to figure out are the following:

    - How much lead time is appropriate for me to do my work? Am I undermining the “just in time” design approach if I’m too far ahead of the developers?

    - What is a reasonable-sized chunk of work for me to take on, so that I’m not required to design story by story (and lose the bigger picture of what I’m designing and spec’ing out)?

    I’d be curious to know, how are you approaching the design phase? Do you work story by story? My team tends to want the stories to be smaller bits of functionality than I can design in discrete units. Do you do some upfront planning for stories you would group as a whole feature?

    The other area I’ve found difficult is providing stories that the developers feel they can accurately estimate without spending much time doing analysis. My dev team wants small and detailed stories, which are tough to provide without more upfront work than I’m “supposed to” do (according to the Agile process). It’s a bit of a chicken and egg situation. Have you or your BA had any trouble in this area?

    Thanks for writing on this…it’s great to see what other people are doing and hear from other UX folks working in this manner!

  2. Olivia, Thank you so much for the comments and great questions. Let me see if I can take them one by one:

    1.UX/BA role. Yes! That is probably the single most frustrating thing for me, personally — as my experience and comfort generally would be in playing that role. At this time, the BA is from a developer background and is responsible for scope definition with the PO. Frankly, I have had to assert myself and join him at the hip to fill in the gaps from that standpoint.

    2. Lead time: I find that it is most successful to work about 2 iterations (or sprints) ahead of the developers. That seems to be the best way to be designing and validating altogether :)

    3. Reasonable sized chunk of work = design phase : Designing story by story equals a patchwork of craziness. Read today’s post for my notes on that. What I still do is to put together USER STORIES that generally hook together 3 or 4 agile stories and try to design that way. I attempt to have those thought out before our iteration planning meeting. An example user story would be: “IN THE BREAKROOM: Logged in driver checks his dispatched trip at the start of his shift. He views total pick-ups and equipments stops. He checks his first stop address.” That is probably 6 0r 7 stories right there. When I work with the BA, I define those stories and kinda force him to draw out the corresponding Agile stories (we use Balsamiq) that way, we can actually test the prototypes with our revolving door test participants.

    Stories: I have the same problems! Trial and error. I am actually thinking of picking up a book that someone recommended and when I remember what that was, I will post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s