So you think you know Agile? You’re probably doing it wrong. As a full-service React Consulting team, we’ve seen it all—rigid processes, never-ending sprints, and clogged QA pipelines. These “Agile” teams suffer because of a disconnect between what they think Agile is and what Agile should be. In this post, we’ll break down the mistakes we see when teams aren’t using Agile properly and how to solve them to improve software delivery and developer morale.
What is Agile, really?
Agile is a philosophy that works to better deliver the software stakeholders want. Agile grew out of difficulties and frustrations encountered in previous development models, ones that prescribed that software should first be well-specified, then engineered, and finally delivered in full.
The pre-Agile models come with significant risks. When software is delivered in full, the needs of the customer have likely shifted by the end of the project and may not have been well understood to begin with.
But Agile is different. By having a constant communication channel, changes can be made to the requirements before time and effort are wasted on implementing the wrong thing, and new work can be evaluated for suitability.
All Agile processes and structures should flow from the values and principles of the Agile Alliance. Every technical decision, every ritual, and every role should have a "why" that can be traced back to one or more of those values or principles.
Conversely, we often see "Agile" teams implementing all of the processes and structures of Agile, yet they still struggle to reap benefits. The common thread between the struggling teams is that they treat their approach to Agile as a rigid practice when they would benefit much more from being agile!
Faux Agile: The Dangers of Mimetic Isomorphism
You may have heard the joke calling something the “wish.com version” of a more iconic item. Not to pick on Wish specifically, but it is representative of a category of marketplaces populated by sellers with no brand reputation selling items whose sole appeal is low prices.
For example, you could buy wireless earbuds that have nearly the same shape, size, and color as Apple AirPods, but upon receiving them, you find that the similarity ends at aesthetics—they’re difficult to pair with your devices and have terrible sound quality. The no-name earbuds are mimetically isomorphic to AirPods in that they copy enough visible characteristics of AirPods to make them sellable but not enough functional characteristics to make them useful.
We’ve seen countless teams fall into the trap of observing something that someone else is using to great success but then replicating it incorrectly due to incomplete understanding. Deeply understanding a problem domain is the key to finding adequate solutions. Without that understanding, degraded copies of solutions can take the place of well-suited ones.
When these faux Agile solutions cause friction or damage, it's tempting to fall back to a mindset that the solution must be right because we copied it from successful people, so it must be merely a case of poor adaptability if anyone is slowed or harmed by it. This mindset is as terrible as it is pervasive!
Characteristics of Faux Agile
Faux Agile occurs when an Agile framework is applied to software development, but the framework is only mimetically isomorphic to real Agile values and principles. Faux Agile is a superficial copy of Agile, one that can show the appearance of Agile practices without regard to fulfilling the principles.
In faux Agile, a Scrum coach imposes sprints of certain lengths and meetings at certain times and days, and a product owner or other management type is the single chokepoint for all communication within a team and between the team and the stakeholders. The communication and introspection that these tools provide are oriented toward the team's micromanagers and limit the developers rather than promoting better outcomes.
Faux Agile Red Flags
In this assortment of Programmer Gothic vignettes inspired by real-life experiences, experienced developers may find a flavor familiar to their own experiences, whilst newer developers may want to examine them closely to help identify red flags.
Ceremonies
Agile ceremonies are supposed to alleviate blockers and keep projects on track. In faux Agile, however, ceremonies themselves become blockers. These vignettes highlight the red flags of faux Agile found in ceremonies.
Stand-up
A daily status meeting happens (or doesn't happen) depending on whether the Scrum Leader is available. The time of the meeting varies on a daily basis, with its regularly scheduled time functioning as a suggestion. Developers are expected to be available for any time slot that the status meeting moves to. If a developer isn’t available, they must send their status to the Scrum Master via private message. At some point, there is a mandate to state the issue number of each issue a developer has completed or is working on, despite nobody looking at the issue tracker during the status meeting.
Lesson: The daily meeting is not status reporting to management. Stand-ups and other status meetings are for the developers to ensure that no one is blocked by a resolvable issue and that the deliverable is on track. Critically, stand-ups do not need to be run or managed by any one person. If rescheduling is needed, it should be done by consensus.
A second daily meeting has to happen on a call with the developer team in India because the remote team owns the domestic team on the org chart. The first daily meeting, which doesn't include the remote team, is the only one where anything useful comes out of it.
Lesson: Friction due to externally imposed team organization leads to schisms. These two distinct teams have nothing to do with each other and only communicate because of external organizational pressures. This is an indicator that engineers are not permitted to self-organize and thus will perform sub-optimally.
Retrospectives
A retrospective happens. Sometimes. Everybody hates being there. Every developer is expected to have at least one comment each about what went well and what could be improved. These items get written into a Google sheet, but there is nothing moved into the issue tracker as actionable material, much less put into play for either of the next two sprints. The next retrospective sheet is copied from the old one with two subheadings, "PREVIOUS" and "NEW," for each regular retrospective heading. The last retrospective's "NEW" problems become "PREVIOUS" problems despite not being fixed when they were new. The only discussion allowed on an item is an oral explanation that the writer of the item is required to give.
Lesson: Retrospectives yield actionable items. If a change reaches consensus, then there must be a plan to implement the change, and that plan becomes a tracked issue. No one in this scenario feels empowered to change the retrospective format to something more palatable, but in a truly Agile environment, everything is on the table for retrospectives, including how retrospectives are conducted.
Demos
Demos rarely happen. This is fine because code rarely moves past review. When demos do happen, they are usually done from the developer's local machine or from the dev server. We're still not sure whether the client wants the feature that the developer is demoing. Neither is the client, but maybe they'll have an answer three days from now.
Lesson: A team unable to demo has a more fundamental problem with a lack of delivery. Items aren't making it to production. A demo should consist of "things you can use today." It's okay if the client later decides that they do not want the feature—it can be stripped out again—but part of putting it into production is to gather that knowledge through user testing and feedback.
Sprint Planning
Sprint planning meetings happen the day before a sprint starts and extend into the day the sprint is supposed to start. The commitment has already been made by the time the meeting starts, and the only purpose of the meeting is to have developers put story points on issues.
Critically, identified bugs are never added to this commitment; they'll find their way into the sprint scope later without pushing out any existing work. When everyone's planning poker cards are revealed, only the highest estimator is called on to justify the number, which is a problem when the major motivator for the number is unfamiliarity. That least familiar developer will be browbeaten into adjusting down, then later assigned the issue as punishment. The issue's only other content is a title copied from an Excel sheet the PO drew up; it will never receive a description or clarification.
Lesson: Sprint planning needs to be integrated into each sprint, and it's probably better late in the sprint when issues have reached code complete and are passed off to QA. In the story above, the next retrospective should identify:
-
A need for a scheduling change in sprint planning, maybe taking more of the last day or spreading it throughout the sprint.
-
Defects are incorrectly treated as not affecting scope.
-
Estimation is being abused to encourage overcommitment.
-
Incomplete issues are being put into play.
Each of these is an addressable issue, but if the team doesn't feel empowered to fix them, not only will they not be fixed, but their effects will also fester and create these problems:
- Sprints will start progressively later, be incompletely specified, or both.
-
Sprints will always run over time, or unaddressed defects will accrue, or both.
-
Velocity, as measured in story points, will appear to decrease.
-
Sprint commitments will not be met, or both.
-
Issues will need to be sent back for remediation, work will not meet the intended purpose of a story, or both.
Personnel
There's a Product Owner, a Technical Product Owner, a Product Manager, a Project Manager, a Scrum Manager, an Agile Coach, a Technical Lead, an Engineering Manager, and an Architect, in addition to rank and file developers. The daily status meeting takes 40 minutes and has to be done by everyone walking around in a circle talking into a speakerphone dialed into Webex so the Director in charge of your project, who is in a remote office, can hear your status for the day, as can everyone stuck in traffic on the way into the office.
Lesson: The ideal team size is five to seven and should not be top-heavy with managers and gatekeepers. Daily meetings are, again, not for reporting status to managers and, in general, do not need non-developers to speak.
If a daily meeting exceeds fifteen minutes, it provides no value to anyone. If the meeting is occurring when people are still trying to make it to the office, it needs to be rescheduled.
This particular story comes from a time before widespread video chat, but phone calls without video are too narrow a band for the communication needed between developers to understand when someone is reporting a blocker and asking for help.
Developer talent is evenly split between full-time employees and contractors. One day without warning, all the contractors are terminated. The team's expected velocity remains the same.
Lesson: This isn't unique to Agile projects, but personnel churn on a software project should generally be avoided. The intra-team trust required to power an effective Agile project is built over time, and having to regenerate it with new personnel is a drag. Per Brooks's Law, this applies doubly when a software project is under a time crunch.
Deadlines
The Start button for the current sprint in the issue tracker usually gets pressed on what is nominally the third day of the sprint, when at least one engineering resource finishes the development phase for a ticket and nothing else in the previous sprint is listed as To Do or Ready for Dev. Other devs are still working on the previous sprint at that time. The dev starting on the new sprint might be pulled back at any time if the committed code doesn't pass review.
Lesson: All devs should be done with dev work at the end of the sprint. Sprint deliverables arriving late is a sign of overcommitment and should only need to be remedied once by reducing the next sprint scope (doubly for the next sprint to handle the overtime issues in the current sprint, then singly afterward).
If it happens repeatedly, there is an issue with sprint commitments or developer friction, and sprint scoping becomes a prime target for the next retrospective.
The previous sprint's deliverable is lumped into the deliverable for the current sprint since QA hasn't started on it yet. Production hasn't been updated in three months.
Lesson: The delay in QA can be an indication of overloaded sprints, low software quality, a backed-up QA pipeline, or a combination thereof.
Roadblocks to production mean CD isn't delivering to production, which can mean that user acceptance testing isn't passing or is understaffed, or even that UAT has passed, but product ownership thinks the deployment isn't ready!
Perfectionism is a real and common pathology in Agile teams, and the only remedy is developing the humility to put something incomplete out to users and get the feedback to drive its further refinement.
Communication
A small cabal comprised of product owners and the scrum master relay all communication from stakeholders to developers. The stakeholders are largely unknown to the team, and there is no way to reach out to them. There is no user testing.
Lesson: This communication structure runs counter to the fourth principle of Agile, "Business people and developers must work together daily throughout the project."
When all communication runs through a chokepoint, there can be no customer collaboration (the third value of Agile). Without collaboration, teams are guaranteed to miss opportunities to respond to changes in the stakeholder's needs or preferences.
A dozen content teams across an organization are responsible for populating the platform the engineers are working on. The content never materializes, making the application nearly useless. The engineers are blamed. One day a new VP assembles the team and announces he is now in charge. The previous VP is marginalized, and the well-liked engineering manager is fired. The content is still not made available.
Lesson: The need for collaboration can extend beyond customers, and in this case, it was essential that the developers met with the content teams to try to understand and mitigate their hesitancy to deploy their content into the new system.
That didn't happen, so providing content in a format that the new system required was deprioritized across the board. Tight control on contacting content teams meant that engineers didn't even know whom to reach out to, and the project as a whole suffered.
Technical Processes
Developers' local database changes are handled by a different mechanism than staging and production. There are two projects, and only one has a migration engine for the databases. The other project has to route all change requests through the technical advisor, who has no database administration experience, for manual updates.
Lesson: CI/CD and DevOps are key components of an Agile workflow but can be hamstrung by recalcitrant human processes. In the specific case of databases, it's best to start any project with considerations made for data migrations, but even a project that's far along can retroactively apply them. Special care must be taken when choosing cloud technologies since developers need seat licenses or equivalent technology for local development.
Conclusion
True Agile prioritizes effective software delivery based on constant communication, adaptability, and fulfilling the values and principles of the Agile Alliance. However, many teams fall into the trap of faux Agile, implementing superficial copies of Agile practices without fulfilling its core principles.
To truly harness the benefits of Agile, teams must embrace a deep understanding of the problem domain, empower developers to self-organize, foster effective communication, prioritize delivery and user feedback, and ensure technical processes support continuous integration and deployment. Only by embracing these principles can teams truly succeed in their Agile journey.
Look out for part two of this post: How to Do Agile (The Right Way). We’ll cover how we successfully use Agile principles to lead projects to success, improve developer morale, and speed up software delivery.
How Bitovi Can Help
Bitovi has been practicing Agile since our earliest days, and our longest-tenured people are some of the loudest advocates for strong Agile teams. We are constantly experimenting with our own production practices and working on tools to assist Agile project management, like our Quick Software Project Estimator. We have a long record of getting projects from off the rails to back on track, and we can do the same for yours. Schedule a free consultation with our Agile Project Management Consulting team to learn more.
What are your faux Agile red flags?
Share them in our Community Discord!
Previous Post
