A seminar on Lean Manufacturing, and sessions on Agile Software Development have convinced me it would be beneficial to "Agilify" our team of Applications Integrators here at Thomson Reuters.
So I joined an internal Agile group, got in touch with Agile coach Paul Ellarby, and started to learn as much as I could.
One of the first events I attended was about gathering and writing user stories. I was inspired by the approach; keeping close to the customer's actual needs and wants was a strategy that resonated with me deeply. While Paul spoke about the techniques he prefers to utilize when ellicting and creating user stories, I began to think:
"Why couldn't user story gathering happen in the field, where the customer is actually located?"
As a large corporation we have many direct points of contact with our customers, none of which are gathering requirements continuously. I've come to believe this is an oversight that many companies are making who are adopting Agile and other "customer-centric" or "customer front-end" strategies, but failing to really meet with the customers on a continous, iterative, cyclical basis. These practices are paramount to Agile, yet few in large corporate environments seem to be taking them all the way to the customer.
Do we have any employees in the field that continuously meet with the customer, (ideally) understand their needs, and in general are challenged think from a customer's perspective? The sales professionals. That's their exact job. So, without further ado, here's the theory:
Steps for Extending Agile to the customer (Agile Product Development):
- Utilize Sales / Account Management teams to close the feedback loop, gathering stories directly from the end user.
- User stories are sent into an aggregation process. Filtered, interpreted, by Product Development teams.
- Product Development Teams organize stories in the normal way, communicating with the Software Developers in a traditional Agile method.
- End of release cycle, product is taken to the customer to check for satisfied needs. In this case the customer is the real customer, not necessarily a product development group.
This is a rough draft of the theory. Currently I'm endeavouring to organize a pilot group willing to test this out. I'll be documenting the results as we proceed.
How close is your development team to the customer? I'd be interested in hearing your perspective as a Software Engineer, Product Developer, or anyone involved in a software development process.
