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
- 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
- Use cross-functional teams – End-user involvement, co-location, and collaboration between analysts, PMs, Architecture Team
- Test early and often – Test and employ configuration management tools and processes