Agile Development, A Practical Guide for Churches

You probably aren’t a software developer, currently organizing a new piece of software. More likely, your time is being invested in the discipling of others or managing the ministry of your organization in some other capacity. But, you probably also have ideas that need to be put in motion; the next big YouVersion, a tool to simplify paperwork, or a way to communicate with your groups. For that, you may need to have custom software created to further your cause.

The unfortunate reality, however, is custom software is expensive. We all want to be good stewards with the widow’s mite. Therefore, you'll either be already aware of, or investigate, an efficient process of development of that new software that honors and respects the resources needed to make it happen.

On that premise, comes the introduction of a software development methodology called 'Agile.'

Agile software development is an approach to software development that encompasses a unique set of frameworks and practices. If you are familiar with it, then you may have heard that it can help build better software or shorten development time. However, you may have also heard of things like stand up meetings or other 'rituals,' and felt it was a little 'cultish.' Either way, in the world of software development, the word “Agile” has generated plenty of conversation, and left many with questions on what it is, and what it isn't. This article intends to present a pragmatic overview to address the things that it isn't, in order to provide clarity on what it is.

What Agile Isn’t

Agile Isn't the Opposite Of Waterfall

Usually when people talk about Agile they bring up Waterfall software methodology. Waterfall is a tried and true way to develop software in a way that will frustrate clients and developers alike. In Waterfall you break your project into discrete stages (planning, coding, testing etc) each following the last one at a time. Often this results in projects that have a slow development cycle and painful deployments.

Waterfall, however, is still popular. It’s very easy to write a contract that prescribes the exact product that should be produced. Unfortunately, the process and result is often less straight forward.

Agile came about as a direct result of the pains of Waterfall. The grey beards who programmed before us were tired of the corporate behaviors that dictated software development and created the agile ideology and codified it in the Agile Manifesto. It’s an unfortunate unibombery name, but the concepts were designed to bring sanity to both developers and customers.

Sometimes people will say they are “Agile” because they don’t use a Waterfall methodology. But there are many development methodologies that aren’t Waterfall or Agile. You can Google “Fake Agile” and see the extensive list of articles warning about this.

Agile Isn’t Scrum

…or Kanban or XP or whatever. Often when people say they are “Agile”, they mean they use Agile Scrum. Scrum is a framework that attempts to organize agile ideologies in a repeatable not-scary for business way. There are many different frameworks that attempt to codify agile development. But Agile really is an ideology that tries to show how software that should be developed.

Often organization will try out different frameworks to be “Agile” as some sort of magic pills without embracing the core concepts. Frequently, leaders will have their development team follow a prescribed set of rituals (fancy word for regular meetings), but fail to realize that if Agile isn’t embraced at all levels of the organization there really isn’t any benefit.

The goals of Agile are to minimize the part of the software development process that hinder good product creation and maximize the parts that do. It focuses on collaboration and relationships over business deals and valuing adaptability over a perfect plan. There are Agile and non-Agile organizations that use Scrum.

Agile Doesn’t Mean Fast

It always seems like the more important the need, the shorter the notice will be. Promotion Sunday, groups launch, the new sermon series; there is always another event just around the corner. I remember vividly a software project that we were waiting on approval to start. We calculated it would take six weeks, but it was needed in three. They waited another half a week before telling they wanted it and to start work!

It’s easy to look to a software buzzword like Agile and think it will solve the issue of running against deadlines. Sprinters are fast but only in a straight line. Instead think of Agile like a boxer rolling with the punches, round after round. Personally, I’d rather race Mike Tyson than Usain Bolt, but the difference is more than speed. The runner executes the plan perfectly every time, but the boxer expects to get punched a few times. Rarely in software development do things go perfectly to plan.

The lesson for custom development is this: the best plans may not prove to be the best product. Sadly I can recall too many projects where a church spent over $100k on a project that would be underutilized, stuck in endless development, or never used. Some of these projects were completed in record time!

An agile development methodology could have solved many of the issues that caused these projects to fail. A bad idea, perfectly planned and brilliantly executed will still be a bad idea… and an expensive one at that.

Agile Isn't Only For Developers

There’s an episode of the Simpsons where the local car company picks Homer to design their new car. He has a long list of requirements to make it perfect and the engineers go right to fulfilling the request. The CEO only sees the car when it’s finally revealed to the public, but “The Car That Homer Built” is nothing short of an ugly expensive mess. It’s a funny gag, but it’s actually a parody of a real car: the Ford Edsel.

When the Edsel came out it was full of ideas Ford thought people wanted, but ultimately it was a flop. Critics called it “the wrong car at the wrong time”. Even though it had all the things people asked for and more, it was a terrible product in the end.

The reality is the car Homer built is a perfect car, but not to the person who ultimately has to use it. When commissioning a new project, most likely you won’t be the person who actually uses the product… or at least only one of the people. It’s up to you to find people who can help you determine if things are going the right direction early in the project.

This means giving your development team blueprints and expecting them to return in three months with a product that meets your needs is lunacy. Even if the finished work is identical to your mockups, this only means that the developers achieved your vision and not that your vision is any good. Ford learned their lesson; now potential customers drive prototypes of a new car years before it goes into production.

Practical Applications For Churches Looking to Develop Custom Software

My hope is that the above points shed some light on what Agile can be for your organization, by clarifying what it 'isn't.' With that, there are definitely cautionary tales, or rather, learned lessons from journeys already taken, to account for and consider if moving forward with Agile as your development process. Below are some words of advice that will help keep the process efficient, smooth and overall benefit the outcome of the goals you initially set:

Give Yourself More Time than You Think

The old joke is "however long you think a project is going to take, double it and go up a measure of time." So, if you think something will be two weeks, plan for four months. This is a bit of a nihilistic view of estimations, but there is some truth there. Unless it’s a trivial task, software development always takes more time than it should. On top of that, keep in mind, if you want to make changes– which you probably will– that will take additional time.

There is good news here though. You can deploy working, but not fully complete software to production. It’s a special feature of software that you can’t do with something like a building or manufactured good. Often the 80/20 rule will apply and you can get to an 80% solution early in the project.

Involve Your Developer In the Planning Phase

One of the worst projects I’ve ever been a part of was planned with the best of intentions. It was an integration so that Rock could talk to this external service. The client talked to the company’s marketing about how you can connect it to your CRM and how it had all the APIs and tools needed to make it work. The client signed up to the service, paid the fees, and started using it, waiting for the integration with Rock to be done before launching it for the whole church.

I was assigned the project, but it wasn’t very long before I realized that the service didn’t do what they wanted it to. I explained that I didn’t think the project had a chance to succeed, but the warning didn’t catch on. After all, the client had already signed a contract with the service! At that point I realized that if the project was going to fail, I wasn’t going to let it be my fault. I put in overtime to get far ahead on the project, finishing my work and more, weeks ahead of deadline.

In the end the project was canceled months after the deadline came and passed because the service didn’t do what they wanted it to. The time, money and lost opportunity could have been avoided with a thorough technical review. Even more important is the hit to reputations and damage to relationships.

Working Code Is the Only Measure of Progress

That’s it. The only measure of how things are going is working, testable code. By testable, I mean code in an environment that you, yourself, can interact with. There’s a good chance you can’t read code (even if they gave it to you), and reassurances aren’t very reassuring when the deadline is getting close. You will sleep better at night knowing exactly where things stand, and it’s a pretty awesome feeling when your boss asks you how it’s going and you can reply with a demo.

You must define your expectations of frequency of updates and access before starting your project. Well organized developers can give you access to the updates shortly after they are written —even resulting in daily new functionality to try out.

Have Regular Meetings With Your Developers

If you have working code, you now have the opportunity to give feedback and make changes as needed. Obviously there will be plenty of bugs and missing functionality early on, but it might turn out that a feature you thought you needed really isn’t, and something you didn’t think about is mission critical.

You should only bring one or two people to the meeting. This meeting is not a good place for aggregating ideas or feedback from multiple interested parties. Collect that information beforehand to save time and confusion. This is your opportunity to review the working code that has just been added and prioritize next steps.

A good rule of thumb is to hold this meeting every 2-4 weeks during development. You should set this expectation before starting the project, so your developers can make it part of their estimate.

Focus on Your MVP

MPV stands for Minimal Viable Product. It’s the smallest set of functionality that will allow you to test your ideas. This can be a surprising challenge, as all of your functionalities seem important to your final vision. However, this step should not be skipped, as it will be one of the most informative parts of your project.

There are a couple of ways that a project can totally fail. First is that the technical limitations may keep your project from completing. This could be that technology isn’t developed far enough to achieve your goals or that these needs aren’t in your developer's skillset. You and your developer should identify any technical reasons your project can fail. Try to solve these as part of your MVP.

The second and scarier reason projects outright fail is because it’s a faulty idea. I have seen multiple large projects fail because people don’t find it useful. Sadly, this isn’t discovered until after they have been completed and launched to the general public. What’s worse is that since so much time and effort has been put in, leaders feel compelled to double down on the project. Use your MVP to test your ideas and theories. If everything checks, go out full steam ahead. If not, this is your opportunity to test your next big idea.

Many years ago I worked on a children’s check-in system. Check-in has an unbelievable amount of requirements: phone numbers, filters, name tags, and on and on —all of which are critical pieces of functionality. So what was our MVP? We had a tablet with every kid’s name on it. They could click on their name and it would check them in. That’s it! It seems laughably simple in comparison to how the system evolved. Eventually, all the normal features were built out because we were confident that parents and kids would be receptive and that we had the ability to hit our goals.

Review with Stakeholders and Users

A stakeholder is anyone who has an interest in the project succeeding. Your goal is to make sure that the way things are going serves them. Over and over, I have tried to think of everything in a project only to show the work to a stakeholder who reminded me of a mission critical feature they needed. While things do come up while reviewing plans, it’s during mid-development demos that their needs really come out.

I say stakeholders and users separately because they really are different groups. Stakeholders are usually co-workers that are in the same building. Users, however, can be anyone and are often quite diverse in demographics. Getting a sample of people who will be using your product and asking them to test it out while you quietly (and often painfully) watch, can be one of the most informative and humbling parts of any project.

On one occasion I had to create a custom UI element for a ballot that would be sent out to every church member. After three days I had it working on desktop and mobile, testing it on every device I could think of. I had no doubt that it was bullet proof, but because it was going out to all members I decided to do a quick round of user testing. I walked up and down the halls asking anyone I could find to fill out the ballot. It worked perfectly for everyone… except for one person. She would touch the buttons long enough to register as a long press and get frustrated it didn’t work for her. I would have never found that issue if I hadn’t spent 15 minutes asking random people to try it.

Have a Plan for When the Plan Changes

It can be easy to think that being Agile means not having a plan, or even not having it all planned out. Really, Agile is about validating your plans as quickly as possible. My experience has been most plans are about 90% good enough and there is usually enough give and take to get the last 10% done.

But.

Things happen. Sometimes we get into a project and find out that our plans need to change —sometimes by quite a bit. User feedback will show shortcomings. I’ve been part of projects where the developer’s work didn’t meet expectations. In extreme cases we just need to cut our losses and cancel the whole project.

If you have an in-house development team, this probably isn’t going to be a big deal. Come up with a new plan and work toward that instead. However, if you outsourced your project and have a contract and a statement of work things can get messy.

Your contractor won’t be very happy about the expanded scope if you start adding new features to a fixed-bid project. If you start removing functionality, you may feel that the agreed upon price is no longer accurate. I don’t think I need to tell you that canceling a project will, at the very least, feel messy.

The reality is that Agile is hard to put into a contract. It’s much easier to say you will make this exact thing for this exact price. Consider, instead, asking for a Time & Materials contract with a budget constraint. Even if you are paying hourly, you can still get an estimate to know about how much the project will cost. It can seem scary to not have a clearly defined contract, but if you are keeping up with the working code, you will know long before how things are going.

Conclusion

It’s easy to think that Agile is something programers do. You give them your idea and they Agile it into existence. But in reality, Agile is about the relationship between product owners and the team that builds that product. It’s designed to help you get the exact product that you need in a way that keeps developers healthy and you sane.