Janet and Jane come from two different areas of business for the Mayo Clinic. It’s the business and IT joining forces!

“When the business and IT partner together value can be derived through collaboration.” – Jane Shellum

The Mayo clinic employs several Agile techniques on their projects. The example project they discussed was the MayoExpert Project. Physicians face information overload on a daily basis, they needed a web-based support system for learning. The challenge, though, was that they needed to convince others to try something different than the (glacier) waterfall methodology.

“The waterfall methodology defers risk to the later stages of the project.” – Jane Shellum

They started by focusing on what it took to deliver value, used some (not all) Agile concepts, and built a “dream team” that would fill the Agile roles needed to ensure the project would move smoothly.

The roles they created included:

Solution Architect – Information owner

Business Architect – Business owner

Application Architect – Design and documentation

Data Architect – Document data

“If what I have in the end is a shelf full of documents and no software – I have failed.” – Janet Bartz

What is interesting about their experience is that even though their project is Agile, there are still remnants of the old waterfall method that are still necessary. Going Agile doesn’t mean drop (all) the old ways of doing things! There may be some processes that still provide value to your organization. Such as formal updates and communication processes to the upper level business folk.

What was also nice was a section on things that they are aware of that need improvement:

Technical debt reduction

Keeping technical architecture in mind

Some Keepers and Kudos from Janet and Jane include:

Adherence to fixed iteration schedule

Poster-sized schedule of features and sequence

Co-location

Feedback Bubble Groups

Hand-picked Steering Group – motivated and engaged

Full-time project managers

Commitment to quality and testing early

Inclusion of senior software QA engineer from the beginning

In summary, the business and IT partnership is critical. Don’t forget the basics of open, honest and transparent communication with leaders and teams, embrace change but manage it, recognize accomplishment, and finally, be Agile, lean, and in-control.

What Agile Scout liked about Janet and Jane’s talk:

They established a “Disclaimer” to their Agile requirements document. Allowing business owners to change requirements on the fly. For them, this sealed the deal and buy-in came easily from the business owners. Interesting!

What made their project successful was that they:

Delivered value early and often – Measure value as perceived by the customer

Learn continuously – Negative feedback is helpful

Shared information early and often – Built confidence of their users

Re-visited scope and timeline with leadership often – Re-evaluate priorities and course correct but locked their iterations from change after iteration start.

Put Agile measurements into action – Working software was primary measure of success