The aim of this post is to show that recent trends in Agile trainings, emphasizing improvisation over principles, can do a great disservice to teams and projects.
Using Agile buzzwords doesn’t mean a successful product, results do. When organizations attempting Agile don’t strike a balance between flexibility and discipline, the Agile process is often blamed, not its crappy implementation. For an Agile process to succeed it takes knowledge and discipline to stick to its guiding principles. It’s not “Agile” to fly by the seat of your pants. It’s just irresponsible. Likewise, it’s not “Agile” to be dogmatic. After all, our goal is to produce the right product at the right time, not “be Agile”.
To see how insufficent Agile training can adversely affect an organization, we’re going to look at a recent project I was on and apply the formal Agile principles from the Agile Manifesto. We attended an Agile training near the beginning of the project that deemphasized more formal Agile practices and instead focused almost entirely on writing good user-stories. We’ll see, given this training, how our project team failed each of the Agile principles, which ultimately led to some missed deadlines and unnecessary personal conflict.
Let’s first get a bit of background on the project.
Table of Contents
NCBI needed a web-based CRUD app allowing NCBI administrators journal administrators, and article authors to upload new articles and edit existing ones to PubMed. PubMed is a huge database of biomedical literature of over 24.6 million records that tens of thousands of medical professionals, biomedical researchers and patients depend on daily.
The previous way of adding new citations and correcting existing PubMed citations was complex and inefficient. The project was supposed to be a model project for NCBI because it was the first high visibility project at NCBI to use Django with a REST API backend and new development processes like Agile, continuous integration, emphasis on testing etc.
The team consisted of:
- Product owner: A non-technical NCBI manager responsible for PubMed. She was to deliver the application to a skeptical group of librarians who viewed the application as a threat to their current jobs.
- Scrum master: Ill-defined. The project manager had just been formally introduced to Agile. This team member was very good at setting schedules and assigning tasks, but inexperienced with Agile and uncomfortable at effectively clarifying requirements from the product owner.
- Developers: A pool of three developers, including me, with varying degrees of coding experience.
- Chickens (https://en.wikipedia.org/wiki/The_Chicken_and_the_Pig). Various folks, managers and random developers, each with their opinions and no clear role on our team.
Before we analyze what happened along the way, I’ll give you a quick event summary:
- A limited group started worked on requirements gathering, initial user-interviews etc.
- A “lead” developer was brought in. She was a relatively inexperienced programmer and had little Django experience, but she did have previous experience programming PubMed’s web interface. Management decided that she’d be trained in the new web-stack with this project.
- I was brought in to help the lead programmer get up to speed. In the first meeting I suggested, given that little plumbing was set up, we start organizing sprint zero. After the meeting the product owner spoke to me, questioning the need for this. I agreed with her, not wanting to cause conflict especially after just being brought into the project.
- We began an unfortunate cycle of design, coding, training, testing and back-tracking. Feathers were ruffled, people got upset, and the project became mired in politics. The blame game started.
- A “project doctor” was brought in, people were “fired” from the project (not me). We stopped calling the project “Agile”.
OK, now let’s review all of the Agile principles and see how misunderstanding or ignoring them led to churn and poor morale.
Satisfy the Customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In Agile projects the product owner is the proxy for customers. He/she should know from experience and from speaking with potential customers what they are likely to need. Negotiating priorities with the product owner is key to assure we will meet customer needs. In our project we
lost sight of this for several reasons.
First, many of us conflated Agile project management with certain Extreme Programming techniques such as Test First Development (TDD). Extreme Programming is about developer practice, while Agile is about managing the project as a whole. The two are not the same, though many Extreme Programming techniques are often used in Agile projects. TDD, for example, emphasizes the cycle of breaking a problem into small pieces, solving each one imperfectly, refining the solution, and moving on to the next small problem.
Specifically, in TDD developers tackle difficult problems by:
- writing an automated unit test addressing a small piece of the problem
- writing the least amount of code possible to make the test pass
- refactoring the code to make it clean
- running the test again to make sure it passes
For a difficult problem, which is hard to grok, this practice helps developers make progress without having to get their head around the entire problem at once. But TDD simply doesn’t apply when interacting with product owners.
A product owner wants to see something done, not a partially done, nor does a project owner want to see an inelegantly solved design problem. In our project, the product owner clearly stated that she wanted a professional graphic treatment to help get reluctant customers onboard. Instead of focusing on her satisfaction, we were intent on getting basic functionality working first. We assumed the most important thing to get done first was the application’s functionality, and that she would accept refinement in future sprints. But we were wrong.
Instead, we should have negotiated and accounted for a holistic graphic treatment before each sprint bagan and explicitly defined our definition of done for each story.
To make matters worse, the scrum master fell back on old habits: he focused on shepherding JIRA tickets instead of recognizing the priorities of the product owner and ensuring we met them. The scrum master’s job should be to help the team communicate, negotiate competing priorities, and ultimately ensure the product owner is satisfied. This wasn’t possible because the scrum master was not properly trained in the very basics of Agile.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
In Agile, what the team produces per sprint should be small enough that if things change the team isn’t overly invested in what they’ve already done. This requires a balance between agility and design.
In our case, we resisted change, instead of embracing it. This was due to the breakdown in formal Agile processes. For example, given that the product owner needed a clean visual design to appease her customers, we could have, from the beginning, spent a one-week sprint designing one small section of the page, without implementing any functionality. We could have simply provided a non-working HTML mockup and had the product owner approve the look of that section before making the app work.
This is elementary Agile. Do short iterations, make sure to get small amounts right, and check in with the product owner often so you don’t get too heavily invested in the wrong thing. Once folks are too invested in the road they’ve already gone down, they’re naturally resistant to backing out.
The training we attended did not emphasize these basics. Rather it focused on writing user-stories at the expense of explaining the how, and more importantly, the why of Agile practices. Worse still, the trainer dismissed such things as distractions, stressing that teams should use whatever processes lead to fulfilling the stories we so lovingly crafted in class.
In practice, our sprint planning meetings and reviews (if you want to call them that) became design meetings and laundry lists of tasks. Sprints were extended, tasks were confused with stories and sprints were no longer properly scoped. Chunks of functionality became bigger and bigger, and when change was required the sunk costs were too great to justify change.
Instead of seeing changing priorities as an opportunity for growth, the developers became annoyed at the amount of work that would be wasted in order to implement a given change. The product owner, finding it hard to get her changes implemented, worked around developers pitting them against each other, trying to “sneak” changes in. The sprint’s scope expanded mid-sprint, deadlines were missed and the cycle continued.
Business people and developers must work together daily throughout the project.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
We, generally, only communicated in person once a week during our team meeting. We used Slack, but nothing beats face-to-face communication. In our case there was no excuse not to interact face-to-face because we were co-located. In this time of messaging, email, JIRA etc. we are often lulled into thinking we don’t need to have an old-fashioned talk. Communication tools can be great, but they’re often inefficient and don’t properly convey tone. I suggested doing daily scrums, but nobody wanted to do them, thinking they would be a waste of time. Of course scrums can be a real time-killer, but when done according to “the rules”, they are focused and last no more than 5 minutes. It’s the scrum master’s job to ensure this.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
We should assume team-members are good at what they do, otherwise they should be fired, or be moved to other positions. People generally give back what they get. Choose motivated people and then give them the power to make decisions.
Here’s an example of how we did not engender trust in this project. The REST API for the backend and the web UI didn’t mesh well. In fact the API wasn’t much of an API at all. It required understanding the underlying database implementation details. Using our approved web framework (Django) wasn’t a great match because we had to write code to map form inputs to the proper REST endpoint. After wrestling with this for a while, I decided to use Angular’s two-way data-binding. It worked fabulously well for our needs. For example, reordering citation authors, which was taking days to implement before we chose Angular, took a few minutes to implement once we went with Angular.
But management second-guessed the choice. They didn’t think it fit with other technological decisions that the organization had made. My view was that using Angular was the right tool for the job. It increased productivity and made the job much more fun, especially after it became clear that the backend developers were unwilling to alter their REST API.
Progress stalled as management discussed the “advisability” of using Angular in an offical role. Eventually the Angular code (which was working perfectly) was torn up and we were forced to use pure Django for this particular functionality. I can’t tell you the damage this had on team morale, not to mention the delays and unnecessary work this backtracking caused.
Working software is the primary measure of progress.
Adhering to this principle could have made the project more successful. Though we generally delivered working software after each sprint, we did not consistently demo the stories for the product owner. We extended sprints with no real consequences. This blurred the definition of “working software.” Sure the app basically worked after each sprint, but did we completely implement every story? Sometimes yes, sometimes no. It’s hard to measure progress and consistently perform with unstable expectations.
To measure progress, you also have to know when tasks are complete. We didn’t clarify the definition of “working” or “complete” for each story during sprint planning meetings. For Agile to live up to its potential, all players must agree on what done means. For the product owner (quite reasonably) done meant each feature worked and that it looked right. She didn’t want vanilla HTML. She wanted professionalism. Progress was hard to measure because we were continually going back to fix things we considered done that the product owner did not.
Sustain the Pace
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
First, we found it hard to maintain a particular pace because the sprints weren’t sufficiently disciplined. In Agile we measure pace with story points and sprints. When sprints sometimes last a week and sometimes two, it’s impossible to measure and predict rate.
Second, we didn’t measure effort in a disciplined way. We didn’t use story points or any quantitative measurement of how much it costs to implement a feature. Because we didn’t do this we also couldn’t predict our future performance, nor properly adapt to new requirements. We didn’t set aside time for a sprint retrospective when we could have honestly discussed and captured what went right and wrong over the past few weeks. Those who don’t know history are doomed to repeat it…
Lastly, developers were often pulled off the project mid-sprint to work on some other project’s emergency. This is a real Agile no-no. There’s a huge cost to changing context, and to predict and maintain pace we must be able to predict what we’ll be working on next. Folks either did not understand this principle or felt that accurately gauging effort was too academic. Unforunately I think the training encouraged this carelessness.
Know When to Design (and when not to)
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
These three principles are related. Agile does not mean don’t design, rather it means designing the right things at the right time and implementing them correctly. If doing so means having a designer or technical lead, then fine. As long as the team buys into the roles and expectations in advance.
In our case, we used this project as a training ground for our new technology stack with a few inexperienced people. This is not inherently bad, but assigning a technical lead with REST/Django experience and a seasoned scrum master would have been wiser.
While Agile doesn’t preclude design, designing everything up-front is also not ideal. Wanting to be “user-centric”, we constantly consulted with a “UX expert”, leading to analysis paralysis and too much churn. Successfully implementing any methodology implies wisdom, which in turn requires balance. This is only possible for properly trained pracitioners.
If you are looking into Agile as a product development methodology, I’d first suggest proper training. Ensure the class strikes the right balance between formal Agile methodology and flexibility. Not every Agile process will be right for every organization. Interview the instructors and figure out their opinion on these issues.
If you can afford it, develop your first Agile product with a consultant acting as a scrum master, and train your staff by example. Launching into an Agile project without proper context is a recipe for disaster. Effectively it’s the worst of both worlds–none of the advantages of waterfall, with none of the advantages of Agile.