If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.
In “Fixed Budget, Fixed Scope? Be Agile Anyway.” I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.
In software development, this is the exception rather than the rule.
For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple. Everyone you need is in one room. When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar). The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:
The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.
In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.
Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale. Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged. Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.
Resolving Wasted Effort
If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture. This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction. You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness. No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.
For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets, value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values). The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value. For some teams, a set of wireframes can all but replace “cards”. An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.
The Product is Everyone’s Deliverable
To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”. While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software. A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:
Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.
Having started my career as a Business Analyst, this is painfully resonant. It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.
Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:
- Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off. Every other artifact is is a tool for getting working software in the hands of users. Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
- UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future. This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features. The upcoming 2 to 3 features should have relatively actionable wireframes. The team should feel certain about the UI design of the current and next sprint.
- Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen. Some screens absolutely benefit, many do not. A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process. Wherever possible, establish a paradigm for a product is intuitive to build. If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
- Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).
Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product. Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products. Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.