Benefits of a Work Items Sprint with IPA

While working on my latest process with Interaction Process Automation, I had a bit of an ah-ha moment I'd like to share: A Work Items Sprint. It worked out great the the first try this past week. We recently finished the front end consulting with sign-off for As-Is, To-Be and the Work Item mock ups. Keep in mind I didn't mention Detailed Requirements doc.

In early discussions with the customer, I had suggested the idea of trying to get something in front of them "sooner than later," but I hadn't gotten any further than the idea stage. Once we got sign off I had briefly started digging into the Detailed Requirements document, filling in the State names and some other obvious details from the flows.

Then last week I had an eureka! moment - why not do a Work Items Sprint? I'm no Agile expert but I am familiar with the basic concepts. I have been trying to consider how this can be accomplished with IPA since John Heiberger (www.lucilium.com) suggested the idea at Interactions2012 back in June during an IPA session. He might not have been the first to suggest it but it's the first I'd heard of it, so great idea, John!

My customer liked the idea of getting to see the screens (which are called Work Items in IPA) and I mentioned it would help drive the Detailed Requirements as well. I also talked it over with the PM, who also has IPA development experience and we were all in agreement that there were no obvious drawbacks and it was \worth a try...

So Monday I dove into IPA and started created a new Process. Keep in mind you can't jump straight into the Work Items, unless of course you don't want to actually be able to Test or Publish the process, but what fun is that? The greatest benefit is seeing the Work Items rendered on the screen because they look slightly different in the Process Automation Designer (PAD).

Turns out you have to build just enough of a shell of your process that it really helps lay the groundwork. Since we'll also be using the Database Driven Design with this process, the Work Items Sprint also required a bunch of variable definitions, which in turn will become columns in the database.

Turns out I didn't need quite the entire week and was able to get the Work Items implemented and a process published in production, which I used to demo for the customer on Friday. They liked it and I learned a bunch as well. Here's the highlights:

1. Customer gets to see something live almost immediately after sign-off, as opposed to having to wait weeks or months.
2. The inevitable tweaks are made early in implementation. I noticed a few oversights where I needed to add a simple text label and read-only edit box or a Text Label bound to a variable for display purposes, and adding those drove a few format changes, all of which made for cleaner looking and more intuitive Work Items.
3. Rapid Implementation - there's no getting bogged down in details with the logic. Just build enough to route the Work Items.

The feedback was very positive from the customer, plus it's always gratifying to see something running in production!

So consider doing a Work Items Sprint on your next IPA implementation. In another post I'll go into technical detail to break down the anatomy of a Work Items Sprint.

If you have other Agile-esque suggestions for Interaction Process Automation, feel free to contact me or drop them in the comments and I'll consider taking them for a spin too!

Happy Processing!