December 7, 2006 | By Joel Dehlin | 41 Comments
We’re planning to do tech talks in SLC, Provo and in Seattle where we’ll talk about some of the technologies the Church uses.
The audience is intended to be software and system engineers who have an interest in what we’re doing at the Church.
What topics would you be interested in?
Comments are ON.
December 5, 2006 | By Joel Dehlin | 19 Comments
As I mentioned in my first post, the Church is a diverse operation and therefore has a diverse toolbox of software required to operate:
* The MLS software used by ward clerks
* ERP (we currently use Peoplesoft)
* Other financial (tax, GL, payments, investments, etc.)
* Supply Chain (manufacturing, inventory, retail)
* Public-facing web sites (lds.org, mormon.org, missionary application, etc.)
* Facilities management software
* Etc.
Given the diverse nature of our work, we don’t take a “one size fits all” approach to our software methodology. However, for the most part we subscribe to some of the principles of Agile Software Development.
The misconception about Agile is that it is itself a software methodology. It is not. Agile is a set of principles–or preferences. The basic principles are these:
Many sling about the term “Agile” as an excuse to be reckless, ill-prepared, or undisciplined in their development.
“We don’t talk about dates… we’re agile.”
“The customer is right! If they want to grow scope they can do it… we’re agile!”
These are of course missing the point. “Agile” isn’t a methodology. It isn’t a panacea. It isn’t a cure for disease. And it’s not an excuse. A software methodology which is “Agile” will allow the developers to uncover and solve problems in real time and will allow the flexibility to swap scope as necessary. Delivery dates however can still be immutable, or at least inflexible, in an Agile software methodology. Scope can still be explored and agreed upon up front in an Agile software methodology.
I’ll give you an example. We just started working on a major revision of one of the Church web sites. We plan to go live in Q1 of next year. We could have spent days or weeks or even months writing detailed specifications, getting contracts in place, negotiating, etc. But instead we worked with the Church department to create a prototype of what they wanted.
We employ a team of Interaction Designers who are just phenomenal. They can sling xhtml and css with the best of them, but they are also terrific with Photoshop. They will meet with a customer and talk through the workflow. They’ll come back a few days later with a working prototype which allows the customer to give feedback based on what they see and play with, not what they read about in a 400 page document. Our interaction designers will even dummy up data for reports giving the customer a feeling for what the real deal will look like. When the prototype is all done, the customer can see precisely what we will deliver to them.
The proto for this web site is now done. We’re currently working on a schedule, and we will accurately be able to predict when we’ll be finished and how much it will cost.
Granted, things change once users start using the system. But that kind of change we can deal with. The changes that have been painful for us in the past are when we get nearly done with a project only to find out we didn’t actually understand the customer requiements in the first place. Using protoypes as specs helps solve that problem.
I read about this approach in a book called The Inmates are Running the Asylum a number of years ago, but wasn’t able to successfully implement the ideas when I managed teams at Microsoft. We never seemed to have enough Interaction Designers, or we were always in a hurry to keep developers busy so we’d skimp on up-front Interaction Design, relegating our designers to Photoshop technicians.
But we’re making it work at the Church and the approach is reaping dividends for our customers.
Joel Dehlin is the father of seven delightful children and the husband of one patient, wonderful woman. His primary love is being with his kids, but he doubles as the Chief Information Officer for the Church of Jesus Christ of Latter-day Saints. More about Joel...
Subscribe to Joel's RSS Feed
Follow Joel on Twitter
