Put our talent to work
One of the confusing elements of agile and scrum development efforts is that functionality completed is not necessarily ready to be delivered nor even ready to be tested.
This is due to interdependencies within the project at hand. A piece of the code may be completely ready on its own, but full functionality requires some other piece of code (which the first code relies on) to also be done.
That’s why a project can have 60% of its code completed, but not be able to necessarily deliver 60% of the project’s functionality. You can easily have some giant body of code that is done, but no functionality can be executed due to those interdependencies.
This is why having a scrum master is so essential. They can make intelligent choices about what code to push out at which point, to deliver the greatest level of functionality and test-readiness at every stage. When you build a system in a proper Scrum fashion, you’re always delivering business value with each iteration. The point is for the customer to 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 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.
A painful lesson in application security
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 phone 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 security no-no number one. When iTunes did its routine backups, it included the temporary log file data—which then placed those cleartext passwords in 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 cleartext passwords became known.
So, yes, interdependencies matter—a lot.
The all too familiar experience
Another part of the Scrum Master’s job is to plan all schedules, timetables, and deliverables based on practical realities, not assumptions that everything will happen as planned.
Consider a project manager who doesn’t follow Murphy’s Law and who opens a project status call by saying, “I just updated the 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 people paying for the software being developed. The usual next steps are also all too familiar: overtime, corner-cutting, and pious pronouncements to “work smarter, not harder.” The project quickly becomes a death march.
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, “nice to have” features that have not been implemented. Eventually, a project may be abandoned. When it is, it’s probable that it was because of an accumulation of desired features that, for one reason or another, couldn’t be implemented.
It is almost always 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. Again, this is part 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’s representatives 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
- Presenting end-to-end functionality, from the initiation to completion of some function of the system
- Leading to a business value recognized by the customer.
In agile development, each iteration is built around the stories or use cases to be built; since those represent business value to the customer, it follows that after each iteration, there is a new system version that represents some business value to the customer.
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 bullseye. Each iteration is a “deliverable” system in the sense that it fully satisfies all the requirements implemented to date.
The crisis, revisited
Returning to the scenario of a project manager not following Murphy’s Law, here’s another take on what could have happened if they were following an Agile workflow.
(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 graphics charts into the next delivery, so we are planning to label the release next Wednesday the ‘gold’ release. Assuming no unexpected dealbreakers, we’ll be ready to go live on the first as promised.”
“Good job, everyone. I appreciate all your hard work.”