Why Agile Development is Crucial to Keeping Projects on Time and on Budget

One of the confusing elements of agile and scrum development efforts is that functionality completed is not necessarily ready to be delivered or even ready to be tested. The difference comes from interdependencies. A piece of the code may be completely ready on its own, but full functionality requires some other piece of code to also be finished.

That’s why a project can have 60 percent of its code completed, but not be able to deliver 60 percent of the project’s functionality. You can easily have a giant body of code completed, but some functionality cannot be executed due to those interdependencies.

Having an agile scrum master in place is essential to address and work through these interdependencies. They can make intelligent choices about what code to push out at which points in order to deliver the greatest level of functionality and test-readiness at every stage. Scrum masters work closely with the development team to make these decisions collectively. When you build a system in a proper scrum fashion, the goal is to deliver business value with each iteration. The customer should be able to say at every stage, “Yes, this provides value to me as a business.”

If you approach a time-boxed schedule with an agile approach, you’re going to have strong confidence that, when you get to the end of the time box, you’re going to have the functionality and security you expect. That security aspect is key. Testing code on its own will show errors, but clean code can’t be shown to be secure until it’s tested and interacting with all of the other code it will touch.

Sometimes A is secure and B is secure, but the intersection of A and B isn’t. That’s where those interdependencies kick in again.

What happens when things go wrong?

A few years ago, Starbucks discovered this security reality in an embarrassing way. Their iOS mobile app used a popular crash analytics program called Crashlytics. That program seemed innocuous enough. When the program detected the app about to crash, it captured as much data as it could in a temporary log file so that the data could be later analyzed to figure out what caused the crash.

Starbucks tested its mobile app extensively, and it tested Crashlytics extensively. But it didn’t look carefully at what was being captured. It turns out that shopper passwords were being captured and then stored in clear text. That was a major security no-no. When iTunes did its routine backups, it included the temporary log file data—which then placed those clear text passwords for Apple servers as well as on the desktop machines associated with that phone. Bottom line: When someone did some routine penetration testing on the Starbucks app, those clear text passwords became known.

So, yes, interdependencies matter — a lot.

The Crisis Without Agile

Another part of the scrum master’s job is to plan all schedules, timetables and deliverables based on practical realities, dependencies and the needs of the customer. Scrum masters should never make assumptions that everything will happen as planned.

Consider “Jerry,” a hapless project manager who didn’t pay enough attention to Murphy’s Law. Jerry is sweating as he opens a project status call, saying, “I just updated Microsoft Project, and after we factor in the last change request and Kim’s skiing accident, we’re never going to make the deadline. We’re going to need to slip, but the CEO has already announced a go-live date.”

This scene, or one very much like it, is an all too familiar nightmare for software project managers, for developers, and for the client. The usual next steps are also all too familiar: overtime, corner-cutting, and pious pronouncements to “work smarter, not harder.” The project becomes a death march.

Programmers are people too.

One of the first widely-known agile methods was Extreme Programming (“XP”) which, among other radical ideas, proposed a rule that XP should allow projects to maintain a sustainable, humane pace.

Working overtime sucks the spirit and motivation out of your team. When your team becomes tired and demoralized, they will get less work done, not more, no matter how many hours are worked. Becoming overworked today steals development progress from the future. You can’t make realistic plans when your team does more work this month and less next month.

Requirements change continuously over the life of a project. As a result, there is no such thing as a completed project. Every project has technical debt, unsatisfied requirements, and “nice-to-have” features that have not been implemented. Eventually, a project may be abandoned. When this happens, the likely cause is an accumulation of desired features that, for one reason or another, couldn’t be implemented.

Hence, it’s better to have a project that fully implements some of the desired features than one that partly implements all of the desired features.

Agile methods uniformly practice incremental development and incremental delivery – construction of parts of the software to completion in short development cycles. This is one of the Agile Principles:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

This is neither new, nor unique to agile methods, but it’s only with the development of the agile approach that tools and processes for consistent continuous integration and delivery have become available. In an agile project, the software is built and delivered in short development cycles, which provide a testable implementation of the system to the customer in a regular cadence.

Delivering Business Value

Agile methods commonly capture requirements using use cases or user stories. There are the inevitable arguments about what these are exactly, and what their contents should include, but there is general agreement that they should represent these things:

• The customer’s view of the system, stated in the customer’s language
• End-to-end functionality of some function of the system
• Business value as recognized by the customer.

In agile development, each iteration is built around the stories or use cases to be developed. Since these represent business value to the customer, it follows that after each iteration, there is a new system version that adds business value to the customer.

Agile and Spiral Convergence

The effect is that in agile development, instead of trying to run toward a finish line, the project is delivering better and better approximations of the desired system, each approximation delivering business value but perhaps not all the business value desired. Instead of running toward a finish line, the agile process delivers many arrows, each landing closer and closer to the bulls-eye. Each iteration is a deliverable system in the sense that it fully satisfies all the requirements implemented to date.

The Crisis, Revisited

Jerry is smiling as he opens the staff meeting.

“Good morning, everyone!” he says with a Robin Williams delivery. “I just heard from Kim. She says her surgery went great, and she should be back to work, on crutches, in a couple weeks. As you know, the product owner has asked us to change the layout of the user’s dashboard; he feels that’s really important, but he’s willing to let us push the graphic charts into the next delivery, so we are planning to label the release next Wednesday the ‘gold’ release. Assuming no unexpected deal breakers, we’ll be ready to go live on the first as promised.”

“Good job, everyone. I appreciate all your hard work.”

Flint Hills Group uses agile software processes and can deliver ongoing project functionality. Get your free estimate here.