Developing Church Software

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:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan


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.

17 comments:

  1. It's much harder to use an agile approach when prototyping legacy systems. I suppose you could use use tools to mock up what the screens would look like in the legacy system. You then need to re-do all of your html (or css & xhtml or whatever) so you lose some of that benefit.

    Has anyone else seen success using an agile approach with legacy systems?

    ReplyDelete
  2. I'm curious if the Church will ever allow for paying tithes and offerings electronically. Has this been discussed?

    ReplyDelete
  3. Has the church considered launching some APIs so that members who enjoy programming can create custom apps, perhaps even submit them for your approval?

    I once wrote an app to help the missionaries in my ward that took a data feed I created from the old version of MIS and printed the ward list on 3x5 cards.

    ReplyDelete
  4. Brother Dehlin, this brings up an interesting subject: I’ve been using PAF since 1993 or 1994, when the only versions out there were for the classic Mac OS and MS-DOS. The Mac OS version’s GUI was (obviously) vastly superior to the MS-DOS version, but then, save a minor upgrade in 1997, it stagnated. (I’m told this is because a third party was in charge of development.)

    Over the years, the DOS version has given way to an Ms Windows version, which has been updated many times. At this point, the Windows version duplicates most of the features available to Mac users in the early ’90s, plus many more that weren’t. Unfortunately, the Mac OS version—while *still* superior to the Windows version, in a few minor areas—remains untouched, and seems to have recently been pulled from Church Distribution completely. (And no wonder. It’s so old, it won’t even run on any current Macs, and requires emulation to run on any Mac OS shipped in the last five years.)

    The bottom line is that I’ve contacted the Church many, many times about the availability of PAF for Mac OS X. There’s still many, many Mac users out there—probably somewhere in the range of 20-25 million active users—and with the recent upsurge in the platform’s popularity, the user base is only growing. Granted, the new Macs can run Ms Windows applications, using third-party add-ons (including Ms Windows itself), but that generally requires a pretty hefty investment where really, none should be needed.

    So bottom line…. When are we *finally* going to see a version for Mac OS X?

    Thanks so much!

    ReplyDelete
  5. .Joel,
    I am wondering if the church as looked into an automatic withdrawal from a checking account to pay our tithes and offerings. I have read several articles where other churches are doing this and it has been a great benefit to the church members, and the church has seen an increase in offerings.
    It seams like there are many times where there is a stake or general conference when you would like to pay your tithing, but there is no one to take the donation. Having the ability to pay online, either automatic withdrawal or pay as you want option would be of great benefit to the church members. Paying online solves any timing issues and is much more secure. There will be some costs involved, but I think the benefits will out weigh the costs

    ReplyDelete
  6. Has there been any thought toward tying member addresses to GIS, the way boundaries are now? This is something I'm doing for my stake, but then I have ArcGIS at home and at work. It might be just as easy to generate XY coordinates when the address on the record is updated, and then it could be flagged for insufficient address, outside boundaries, etc., as well as help map things statistically for local units.

    ReplyDelete
  7. I was an assistant Ward Clerk in charge of finances for over 7 years and have been the Ward Clerk for over a year. Switching over to MLS was a big step forward for us in 2004. When will we take the next step? We still transmit membership and financial information to SLC each week on a modem and a baud rate most people would not recognize. Our Stake Center already has wireless DSL for the Family History Center. When is the Church going to have it's units communicate with headquarters via the internet or a church-only intranet?

    ReplyDelete
  8. Joel:
    I want to let you know that finding your blog has killed my productivity today. Lots of interesting information.

    It's great to see the transparency your adding to the Church's bureaucracy and process. I'm sure you'll be rewarded with valuable comments and insights.

    Try to keep the really interesting stuff to a minimum. I’ve got work that needs get done!

    Best of luck in your efforts and initiatives.

    ReplyDelete
  9. I have questions about your implementation of Agile methodologies.

    I have been many years in IT both in project management and actual development. I have been involved in both traditional and alterative project management but have trouble convincing executive management of the benefits of Agile methodologies. I agree with you that there is not any methodology that is a one size fits all and often mix traditional and Agile components depending on the project. I am convinced that many people who like Agile do not fully understand it and improperly implement and explain it. As a result, my executive management has been soured on anything Agile which has become increasingly difficult to implement. My first question is, how do you present Agile to executive management when they are convinced it is a mistake? You mentioned you had difficultly at Microsoft implenting Agile. What were your road blocks there?

    My last questions have to do with your Interaction Designers. This is an interesting concept to me. How detailed do they go? Do they mock up every page and report that will be developed? How do you capture and document business rules and background processes if you eliminate traditional requirements?

    Thanks,
    Ben

    ReplyDelete
  10. I am interested in the Stake/Ward websites. I am in the Bishopric of my ward and my Bishop has asked me to setup or Ward website since I am in the IT field so that we can generate some training materials for a ward webmaster in the future.

    My questions are:

    1. Will there be some training developed and available online as is being done in other areas, for the website management.

    2. The site is very basic and it seems like there are opportunities to expand the capabilities (ie. add tabs on the Lesson Schedules page to allow schedules for other classes). Are there plans to allow administrators more/better functionality?

    ReplyDelete
  11. [...] 3) We’re designing iteratively, relying on prototypes. This allows us to have a great idea of what the customer is looking for before we ever start coding heavily. [...]

    ReplyDelete
  12. Joel,

    All I can say is THANK YOU!!! :-D

    ReplyDelete
  13. Rich,

    I agree. As a counselor in our ward's bishopric, I have yearned for some increased features in the Calendar, private calendar items for the Bishop, Bishopric, Leaders, etc. so that all of us can use the same church calendar. I wonder if somehow this could be integrated with an APP like google calendar where collaboration is possible (after log-in), but personal calendars can be used for each person (i.e. remote calendar links).

    Joel,

    I think that the advances that have come in church technology over the last few years have been very exciting. You and your group(s) and whoever else is responsible have done a wonderful job.

    ReplyDelete
  14. Notably absent from your list of supported items is the Ancestrial File. It was moth balled many moons ago. I can't believe that after so much time that there is still nothing released.

    I've enjoyed reading your blog, and I hope you can continue to turn things around for the church's technology. It was nice to see your focus on inspiration and revelation, as that is the complete solution and driver of what we do in solving business problems through code.

    I was first introduced to computers on a Saturday when my father needed to go into work at the church office building. He brought me and my brother with him. That was a couple of decades ago. I've since gone on to get a BS in CS from BYU in two years and have run multiple IT teams and departments.

    I know the church has had some truly inspired developers, and others that have been overly arrogant. My father has been grateful for those developers who care to truly understand the needs of his team and department, and then make a difference.

    I am a bit disappointed that the tech talk you are hosting is on a Thursday at 6:30 as that conflicts with bishopric meeting. I truly hope the discussion goes well. Maybe some of the discussion's highlights can be blogged for those of us unable to attend.

    I imagine you already know this, but the interface, usability and stability for MLS needs a lot of work.

    Best wishes and prayers

    By the way there are many of us software developers how would love to give back and help out the church. I don't know if the church has ever considered calling developers as church service missionaries, but I'd imagine you would get some interest and great talent.

    Also on the open source topic some of the little utilities that we write to make our callings easier, could benefit others if there was a repository that was easy to find for the source code and/or executables.

    ReplyDelete
  15. I am amazed. I would have never guessed that the CIO of the LDS Church would have a blog talking about Agile development. I have 18 years experience in the IT industry. I have worked for a software development company that professed to be using Agile methodologies. I also worked for the IT department of a manufacturing company who professed to be using Lean Manufacturing principles. I can honestly say I applied more of the Lean Manufacturing principles from the manufacturing company than I did of the Agile methodologies at the software development company. I hope I am not misunderstood here but I think sometimes "simple discipline" does all the work and "showy technology" takes all the credit. Some of these lean manufacturing principles are as old as the model T ford. I am always impressed by the advances being made by the LDS Church in many areas. I have no doubt that the it will go forward with or without "showy technology".

    ReplyDelete
  16. I view IT as just a part of the larger enterprise. I cannot see IT having its own purpose. Which is why I when I think of a manufacturing process and IT I can relate them together. It would be absurd to think of developing a manufacturing process to serve itself. But IT people seems to develop technologies for thier own enjoyment all the time. Since manufacturing processes improvement has been around longer they have progressed to a greater degree than software/IT development has. I really think the IT people should take a closer look at what they can learn from them. I wonder if their are others who have given this any thought. Keep up the work.

    ReplyDelete
  17. Thank you so much for sharing this one great tips here, well very helpful and informative sharing,cool Love it. - Mobile Application for Church

    ReplyDelete