« Technical Conveyor of Tacit Knowledge | Main | Why Social Media? »
Saturday
Jul032010

Agile Development – ECM Implementation Experience

Pilobolus Dance TheatreUsing Agile development techniques was a clear advantage to our project team.  We were able to accelerate ECM solution development and deliver an aggressive scope of work in a very short period of time.  But, this experience has taught me that the quality of user involvement is critical when following this approach.  For Agile techniques to work effectively in ECM deployment, users need to be given the opportunity to engage all of their senses and be not just intellectually engaged but experience how the system works.  In planning rapid, Agile methodology driven, ECM deployments this needs to happen as early in the schedule as possible.  Here’s what happened on my most recent project.

The project involved the automation of 10 distinct processes using Livelink Workflow and HTML forms.  An Agile approach was used to accelerate the development effort.  Though our scope of work was more than I would normally sign up for in the time allotted, the team pushed ahead, and was successful in completing the work within the project’s timeline.

Overall, the Agile approach helped us to accelerate our activities and seemed especially appropriate for the technology being used, Livelink.  But, we did run into issues during review and testing. Workflows that had gone through rigorous review sessions where issues and gaps were clearly documented and closed still were found to be discrepant when hands on testing by users began.  It seemed clear that our work was perceived quite differently when it was shown versus when it was used.  Through their hands-on experience with the system doing unstructured testing the test group seemed to learn much more about solution fit.

I observed that using an unstructured testing approach, the users began to feel what it was like to use the software.  The feedback I began to receive was much more imaginative.  Suddenly, they began to come up with many more usage scenarios for the solution and were evaluating how well the workflows met their requirements within each of these scenarios.  Their feedback became richer resulting in change requests that significantly improved the solution.

The users involved had many opportunities to provide feedback.  They had attended training on the system and had seen improvements made to the automated processes based on the feedback they provided in structured review sessions.  Irrespective, when they engaged in unstructured testing of the same workflows, they began to think of new usages, and came up with new requirements which had to be met.

In attempting to use the processes outside of a training venue or structured session, they began to engage their creative minds.  As they processed through the steps of each workflow, they began to imagine themselves using the system.  They could reflect on how they do the same transaction today and compare it to how the new system worked.  They began to “feel” what it was like to use the system.  They were experiencing the system.  They began to embody it.

As this happened, they began to feel what worked and what didn’t work.  Often, this would come out in emotional utterances.  They would struggle to explain the problem they saw and we would have to stop, talk about it, and take time to understand why they felt it wasn’t working the way it should.  As they experienced the system, they began to see the need for variations in our design.  Suddenly, they could think of scenarios where the current design might not work, and they began to refine the solution design with their change requests.

My take away from this experience is that as a part of the Agile development process, user engagement must be done earlier, more frequently, and on a less structured basis.  Structured sessions, whether they are for review or for training, yield less information.  My take away hypothesis is that engaging users in free form testing of the ECM solutions being developed as early in the implementation timeline as possible will result in an even more condensed development cycle.  Further, the less we control how they are doing this the better will be our result.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>