How Agile Failed — A Retrospective

Everything ended with a frozen screen and over six-hundred thousand dollars lost. It began with an eager team faithfully committed to the Agile Manifesto. A rebellious improvement over traditional document based specifications. The only issue was a lack of instruction.

While true, some of the names and requirements have been changed to protect everyone involved. In the end, ten people were fired and a once successful company declared bankruptcy. The writing of this story is to serve as a universal retrospective of what not to do.

One may assume the team involved was incompetent. Based on this project that seems accurate. However, most had completed Master Degrees in Computer Science with class topping GPA’s. Even the Project Manager was a 30 year veteran of managing complex projects. They understood how to make software. It was just from the old paradigm of Waterfall Specifications. Agile was thrusted at them without anyone ensuring it was understood.

Continuous Delivery

First, states the manifesto, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” When the doomed project started, the team committed to two-week sprints. Planning to deliver working code at the end of each iteration.

The Project Manager meet with stakeholders and created a requirements specification. Afterwards, each requirement was translated into a User Story. For example, the requirement of “have a toolbox icon in the upper right-hand corner that when pressed displays tools to make manual calculations…”, became, “As a user I need a toolbox in the upper right-hand corner that displays…”

These stories were almost verbatim to the Requirement Specification. The only real change was the words, “As a user.” The fault was not on the Project Manager as they were doing their best to dress-up a Waterfall project into Agile. Instead, the blame should be placed on leadership for trying to disguise the methodology used.

If a project begins with hundreds of pages of documentation, it is not Agile. An Agile product begins with a loose set of requirements that can fit on a standard sheet of paper. Starting with something like, “A user registers, confirms their account, and signs in. Afterwards, they are taken to a map interface with various points of interest…”

As the project progresses, clarifying questions are asked of the stakeholders. For example, “Can a user sign-in and register using social accounts?” Instead, the doomed project had every conceivable question pre-answered with a scope that appeared to belong to an Apollo Moon Launch.

Changing Requirements

The second part of the Agile Manifesto explains, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” This was a favorite for the stakeholders of the doomed application. Every few days included additions, changes, and new features.

The Project Manager divided each User Story into tasks specific to each development role: design, front-end, back-end, and infrastructure. At the beginning of each two-week sprint, the work was assigned based upon story completion. The only issue was that during the sprint, stakeholders made sweeping changes to what constituted complete.

First, there were design changes. An expected addition once the ideas turn into working screens. However, this blocked front-end developers from creating them. Second, was new functionality. Some requiring changes to the underlying infrastructure. Another large problem for a team committed to delivering the same number of stories.

At the end of the first sprint, the team was four weeks behind schedule. The problem is schedule. As an Agile project does accept change but also gives cost estimations for implementing those changes. Both as man hours and time delays. Thus, the stakeholder can choose between the new feature at the expense of other items being completed during that sprint.

The team on the doomed project did not realize this and began frantically working around the clock to deliver everything. As a side effect, many shortcuts were taken inside the code. Including a critical mix-up with feature branching that made every “fix” overwrite previously tested code with past problems. A problem spanning hundreds of code commits.

Developers started to hate work. Project Management began making apologies to stakeholders. Leadership hosted a series of high-tempered meetings. Everything and everyone involved began to unravel.

Delivery

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale,” is the Agile version of show and tell. The project of doom did not deliver during the first sprint. Or the second. Instead, the entire team was busy trying to deliver code that seemed to be getting worse with every code merge.

Most teams create an automated process to both test and merge feature updates to the development branch of the project’s codebase. The doomed team did the same. However, due to ever demanding deadlines, developers removed failing tests from the process. No longer caring for the overall success of the project, it was every man for themselves in a vain attempt to keep their jobs. Blame was rampant and the team was anything but.

The core issue was a lack of understanding about changes to the requirements. For Agile to work, the stakeholders must be given the reality that out of n number of man hours the team can deliver x number of stories. This team delivered stories, but it was the kind that tried to account for the lack of progress — not actual working software.

Thus the root cause for the projects trouble came from trying to deliver beyond what was possible. This problem began with leadership not pushing back with stakeholders. Had true Agile been followed, a less completed but working version of the code would have been delivered. Instead, a feature rich mess was all they accomplished.

A major risk with software development is the cascading effect. One small problem ignored early in the process has the potential to derail the entire project. It can be as simple as a tired and overworked developer accidentally committing to the wrong branch. This in turn results in a Team Lead forcing the changes into a repo and overwriting the bug fixes from the night before.

Instead, each project should begin with a robust CI/CD (Continuous Integration and Continuous Delivery) System. An automated means of enforcing quality and merging features into the codebase. Including fail safes for dangerous behavior.

Collaboration

“Business people and developers must work together daily throughout the project,” is the Agile means of removing the stigma of client and contractor that was and is prevalent in many organizations. For years, companies looked at IT (Information Technology) as a service provider to the rest of the business. Not a strategic tool like other internal departments such as finance and marketing.

Consider where most technical teams were located in corporate offices — the basement. It became a running joke for years among technical staff that they worked in a cave. For Agile to be successful, the Technical Team must be viewed as a strategic arm of the organization, not a contractor. This is one of the responsibilities of Technical Leadership.

Collaboration involves each member of the team working together with the group. Regardless of role. Be it a Department Head, client, or executive. His or her duty is to be instrumental in reaching the project’s objectives.

Most projects still create levels of hierarchy between the stakeholder and development staff. A client wanting an update must first talk to their Account Manager who charges for the update. In turn, giving the request to a Project Manager who filters it down to the person actually implementing it. All with signatures and approvals along the way.

This was the method of the doomed team. They had layers between workers and owners that added complexity and confusion to the process. In Agile, there is no issue for a stakeholder to request a change directly to the developer given a sign-off process to avoid misunderstanding.

Consider a stakeholder trying a new feature at the end of a sprint. He or she may determine that the process given is too cumbersome in reality. Instead of going through multiple channels, the Project Owner can send a request on the team’s chat for the change. In turn, everyone is notified. The Project Manager can make a new story or new story task for the feature, the developer can estimate, and the work can commence the same day.

In contrast, the old model required extensive sign off due to the perception of IT being a contractor or internal vendor. A business cost that had to be controlled. In turn, IT Managers acted more like sales people, trying to convince the stakeholder of each and every alteration. Only implementing the change after days of negotiations.

Motivation

A big failure for the team of doom came from a disregard of the Agile value of “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Instead, the development environment was made toxic.

Once the Project Manager allowed any and all changes without altering the delivery schedule, the working conditions became hell. Add to that the catastrophic mix up of code merges and removal of failing tests by development and all trust was gone.

Developers who were once trusted to work from home were required at the office. Everyone was expected to remain available around the clock. Impromptu meetings were held to scold developers not living upto the expectation.

This resulted in a total lack of motivation for the project. While many wanted to quit, they had no time to look for another job. Not to mention, many had become convinced they were not good at building software. The team was down and management were fearful.

A major factor in successful execution of projects is motivation. In reading stories of how Steve Jobs demanded perfection from the original Macintosh Team, it is clear that those working on that project were motivated. Regardless of the monstrous work schedule, that team delivered with cheers, pranks, and smiles.

Based on accounts of Job’s demand for excellence, the amount of work given is not the issue. It appears the extra hours were volunteered by the team due to their desire to make something great. In contrast, a non-motivated team forced to work extra hours is a recipe for disaster.

Motivation is something that has to be cultivated. Employees wanting to remain employed will fake it to keep their paycheck. This is a problem as there has to be buy-in from the team on the importance of the project and a true desire to be part of it.

No project runs smoothly from start to finish. The difference between a minor set-back and a catastrophic event is usually perception. Working on both teams that accomplished big things and on teams that failed, it has become clear that the determining factor began with motivation.

Everyone on the team must be sold on the project. Each member must be trusted to do their work with minimal oversight and assurance that anyone can ask for help when needed. When people believe in the importance of their work they give their best. If those team members are competent in their role, as they should be, the project will exceed most expectations. Otherwise, the project will fail in one or more areas.

Communication

A problem for dispersed teams is the core value of Agile that states, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This is very important as it tends to alleviate much of the confusion.

Consider the project of doom discussed throughout this text. Their primary means of communication revolved around chat messaging. While good for quick question and answers, it leaves much to be desired. The problem is that face-to-face is not always possible due to geographic dispersion.

Part of most Agile sprints include daily stand-ups. These are short meetings referred to as huddles due to everyone standing. During the meeting, each team member (not just developer) explains three things: what they worked on yesterday, what they are working on today, and any blockers that is keeping them from accomplishing their task.

The reason for these meetings is for the Project Manager (may have another title) to remove blockers, get a feel for the teams progress, and address any concerns related the project. He or she meets with everyone to improve overall communication while cementing the teams role as a single entity responsible for success or failure.

The project of doom team sent chat messages of this to the manager each morning. In turn, the messages were never read by the entire team. For example, a Designer may never realize that the Front-End Developer was waiting on a screen update. Unless both took additional time and effort to communicate directly later. However, the designer may be blocked by the stakeholder for creating the screen.

When communication is in-person, people will illustrate their understanding through head nods, smiles, or frowns. For text, it is almost impossible to pick up on these clues. That is until a team member shows displeasure with the dreaded all caps.

While watching reality television about behind the scenes of major sports teams, it is revealed that coaches meet with their team in person. The star pitcher or quarterback does not get a text during a game on his or her performance. Instead, a face-to-face encounter occurs where praise and/or correction is made.

Progress

“Working software is the primary measure of progress,” is the part of Agile most important to stakeholder happiness. Consider it from their perspective. The project owner is excited to see their vision become reality. They have an idea of how it should be and want it as soon as possible.

While unrealistic to instantly deliver an entire project in short order, giving stakeholders an ever increasing body of completeness is the only way for a project to remain positive. The act of showing work as it is completed removes doubt and fear from the stakeholder. Fail to do this and animosity between stakeholder and the development team will grow.

As stated earlier, the project failed for the first month to give anything resembling working software. The project owners became distrustful of the team. This resulted in a rapid decline of the relationship.

The key to shipping working software is managed expectations followed by consistent progress. A team cannot and should not promise an impossible delivery schedule. Instead, the team should give a realistic pace of completion. In past projects, angry stakeholders became big proponents of the team due to simply delivering a working product.

Sustainable Development

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely,” is the crux for all to have a successful experience.

Working around the clock without rest is no way to deliver a successful project. Yet the entire team on the doomed project did just that. Instead of realistic expectations, the team was guided largely by fear. Management was afraid of the stakeholder, developers afraid of management, and everyone fearful of losing their job. In turn, the project owner was afraid of spending money on something that may never materialize.

In the end, nothing of value was delivered. However, a switch to sustainable development with one uncomfortable stakeholder meeting could of saved the entire project.

Technical Excellence

It is useless to deliver something that is broken explains this concept of Agile, “Continuous attention to technical excellence and good design enhances agility.” However, it must be included as much of the software ships with a large number of defects.

Going into technical meetings, the young engineers usually have an iPad or computer to take notes on. Yet, the grey haired veterans most often write on paper. When asked, one grey bearded technologist explained, “technology fails but I have never lost the data in my notebook.”

The premise is that everyone knows software fails. The longer people are around software, the less trust they have in it. Years ago, a software company CEO gave the mandate that their company would migrate to their just released software before rolling it out to customers. The development team pleaded with him not to do it. Yet, the wise CEO could not ask their customers to do something they would not. In the end, it proved to be a great way to ensure technical excellence.

The project of doom had no technical excellence. Its code was a horrible mess of mismatched design patterns, technologies, and one-off patches to get across the finish line. In fact, Quality Assurance logged more man hours than any other role.

Simplicity

“Simplicity — the art of maximizing the amount of work not done — is essential,” is the genius of great products and a key piece of Agile development. This is true because every feature added is an additional point of failure.

A few years ago, my family purchased a minivan. It had all the creature comforts and by all accounts enjoyable for long drives. After over 100,000 miles, the battery died and a jumpstart was needed to get home. As a result, the in-dash CD changer stopped working. A few months later the rear air conditioner went out. Then the front heat. Pretty soon, all of the things that made it enjoyable had broken. Turns out, the jumpstart created a short in the complex electrical system.

Had the vehicle been simpler, the jumpstart would not of shorted the electrical system. Yet that would mean fewer amenities. Yet, if the given a list when buying the vehicle of each feature with a complexity rating — many of the loved amenities would of been disregarded in favor of robustness.

The same is true for software. Start with a simple design and only make it more complex when absolutely necessary. The project of doom began as a detailed architecture document containing multiple complexities to support the vast array of features.

If the team had shared such a quantifiable list of each feature with its cost in terms of man hours, risk, and maintenance cost — the stakeholders probably would of eliminated much of the system complexities.

Architecture

One of the most controversial aspects of Agile is, “The best architectures, requirements, and designs emerge from self-organizing teams.” Considering Software Architects, Project Managers, and Engineering Leadership make a living from these tasks, this part of Agile is often ignored.

The project of doom had an architecture, lengthy requirements doc, and portfolio of screen designs. Yet, it failed. The alternative would of been to keep requirements simple as discussed earlier. Making the architecture simple and the screen designs less dogmatic. Not to say, things would not change. Just that the act of consistently delivering working software would quickly clarify each decision.

Despite the planning, most of the architecture decisions for the failed project came from individuals wanting to complete their task to sleep. Meaning multiple bad practices were introduced at all levels of code. Including changes to interfaces that remain to this day undocumented.

Another benefit to a team guided approach to planning is it always seems easier to add a feature to a working product than one being rushed in development. Therefore, developer are free to do their best work in thinking through problems as a team. This occurs daily for existing products. Often leading to additional improvements to other aspects of the system.

Reflection

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly,” is an Agile method left out from the project of doom. The team never had time to meet. Instead, they were busy trying to deliver something that could never be delivered.

However, this is the retrospective in how the team failed Agile. Not how Agile failed the team. Had the team done something similar early in the process, this retrospective would of been an example of best practices at work. Yet, here we are.

Conclusion

Building software is risky business. It is one of the few handmade items left. Something custom tailored. Thus it should be treated as bespoke and not attempted to be mass produced. This is the benefit of Agile. A method to create custom software as efficiently as possible.

To learn more about applying Agile, visit http://toddmoses.com