I am an Agile Coach. I believe in the tenets of Agile and am sold on its value. I enable others to be Agile. However, due to misconceptions and bad applications of Agile, examples are plenty when Agile has hurt where it was meant to help.
One of the contrasts of Agile and Waterfall, is in the amount of documentation. Agile has taken the Use Case documents, the architectural and technical detail design documents and scattered the plethora of information into series of user stories. A user story is a tangible unit of work resulting in user delight in the form of a new capability. It takes user pain away in a meaningful way even if it is a small functionality such as radiating the status of an application throughout the process (on a website).
The detailed requirement documents of waterfall take months in which timeframe paradigms supporting the requirement change. It is the reason why in Agile, we make requirements golden at the “Last Responsible Moment” in smaller, bit-size chunks. All this works wonderful in theory. In application if not done right, the machine breaks down. Listed below are Agile process smells or pitfalls hurting teams because of improper application or misunderstanding of the practice.
Vertical Slices of work in Siloed Component-Based Model
I repeat, “a user story is a slice of work resulting in user delight.” User could care less there are ten APIs to be built or which technical framework programmers must use. User only concerns in the capabilities they wish to receive from the product. Does the word processor I am using allow me to type my blog and share it in one click?
All good so far. It is the reason why we create stories vertically to focus on the impact to the end customer. This good intention gets punished in an organization fostering experts in niche skills instead of full stack developers. Let me rephrase. When software teams are built around key types of skills, the web service team, the front-end team building the UI, the database team, the Java team, the SQL team, the JS team…there is an awful number of handoffs, and consequently, waste in the system. This model produces experts in the field (DB guy, network gal…) with idea that experts will take requirements and deliver them in a mighty pace. It is a gain received at the risk of self-created silos. When the developed experts leave, they take with them their knowledge that should have been spread around to begin with.
So, in these organizations with horizontal teams a vertical backlog (for the end customer) results in stories with large cycle time (because teams need to wait for “the other guy” to commit, finish and deliver before they can). Large cycle times equal large feedback loops. Large feedback loops result in potential missed opportunities of improving fast and pivoting. Sometimes, it is okay. A lot of time, not. A vertical backlog for such an organization is dragging the horse to the well, but horse will not drink until all its buddy horses arrive.
Reduced documentation = no documentation
Delivering potentially shippable software in two-weeks cadence can be mind-boggling and chaotic (until it becomes muscle memory). Sometimes in the whirlwind of it all, hallway conversations take the place where key decisions on a user story are made. Agile is big on co-location and hallway collaborations, let me be transparent. Synergy existing in people eating together, coding together, storming together, and getting back together is priceless. But a hierarchal organizational structure with borders, requires alignment of understanding across those borders. For example, most large organizations have a separate end-to-end testing teams. When a user story is committed to be worked upon does the PO or the developer on the team or the end-to-end tester, do all of these cross-functional units perceive the requirement with one lens? Are all of them included in these hallway conversations? Same argument for distributed teams.
In the waterfall world, I can confidently say the documentation is organic because it is instituted and reviewed multiple times. So, where its drawback lies in the lack of speed to respond to change, the pro is requirements when well-written are clearly understood and prescriptive. Can it hinder innovation from the techies? Sure. But the business knows what it wants and has taken the pain to write it out in great detail.
So, beware that becoming Agile does not mean compromising on the quality of documentation. It simply changes when you are focused on refining what.
Anyone can write a user story
I have coaches highlight the bottleneck (waste) in the system in numerous Agile trainings. Look, if you wait on one gal, the product owner, to finish writing all your user stories for a team of 8 developers, then you may go slower.
So, the whole team should be trained on writing user stories. The whole team should be trained and empowered to write user stories. However, there are pitfalls here to watch for.
Too many cooks spoil the stew. Or a clear voice missing in the product, or have you heard of the bystander effect? When lots of people are standing and witnessing the same wrong, everyone thinks someone else will act, not me. End result, no one responds. Everyone thinks everyone/others can write stories, so not me. I have seen this one too many times.
So, I differ from my fellow agilists in this advice. I feel Product Owner should have a clear, crisp vision. The vision needs to be disseminated from the PO to the teams in how features are broken into stories and what each story entails. However, the PO should not limit the innovation of the team and encourage questions and collaboration to improve the requirements and embody the whole team spirit. If the PO is absent, the team should feel self-sufficient to step in, but the team writing the stories does not replace the vision guiding the product.
Because when the PO takes the back seat and depends on the team to self-organize in creating and writing their own stories, result is never good, I assure you.
Acceptance criterion can change mid-sprint
Agile puts processes in place enabling the team to respond to change and incorporate customer feedback, etc. However, the last responsible moment as a rule for acceptance criterion formulation is ahead of the sprint start, period. Changes mid-sprint should be exceptions and not the norm. It is unfair to accept the development team to pivot with their heads spinning round the clock. The stability is desired within the sprint.
All these problems are experienced when Agile is misunderstood or a sentiment is abused to an extreme end. I am sorry to inform that Agile is not a cure all for the documentation. It does not mean crappy or no documentation. We are still obligated to do a top-notch job. Nothing changes there no matter the methodology.
Featured Photo by Tom Pumford on Unsplash; Inline Photo by David Travis on Unsplash