When we ask an experienced Scrum developer what defines a good User Story, the answer we hear almost immediately is that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.
When we further elaborate on “INVEST” part, we hear that splitting user stories should be done Vertically (along features), not Horizontally (along components or applications layers). Why is the latter condition so important? Because when split vertically, and cross-cutting through multiple components, a user story has a much higher chance of representing a potentially shippable product increment (PSPI). Delivering, UI/UX alone, or business layer alone, or database alone, does not present value to a buying customer.
Frequently, we hear the analogy of a sushi roll, when describing story slicing: “…every User Story must represent a thinly sliced sushi roll that provides taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…”
…Now, imagine an organization that undergoes agile transformation. Predominantly (statistically), transformation efforts stem from Technology, where agile improvements come in the form of introducing good engineering practices, such CI/CD, TDD, unit testing, test automation, automatic deployments, etc. But technology alone, is just one layer of an organizational sushi roll. Sure, just like seaweed alone, it may be tasty enough for starters, but without adding additional flavors, it is not a complete, tasty meal.
Other organizational layers need to be included as well, when identifying a slice for agile transformation experiment. A slice does not have be too thick. If organizational slice is too thick, it might be too big to “swallow and digest”. But still, even when sliced thinly, an organization must include enough layers, to be considered as complete meal.
What are some of those layers? Let’s consider a few:
Business & Operations: it is imperative to have real customers intimately involved in agile transformation efforts and make them closely aligned with technology partners. This requires identifying and providing a strong support for some key agile roles, such as product owner, stakeholders and SMEs. Often, this requires organizational realignment and changes to sphere of influence.
HR: Subjective monetary rewards that are based on individual performance assessments and fueled by invisible internal competition among employees, must be discontinued, in favor of incentives that promote teams’ collective ownership and performance. An organizational slice that wants to become more agile will have a much higher chance for success if HR policies were genuinely supportive of the initiative of the efforts.
Budgeting & Finance: For agile teams (Scrum, Kanban) that use adaptive planning and iterative development, and continuously have their work re-prioritized by business, it is imperative to have flexible budgets (“flexible spending”). By unlocking a rigid budget corner of what is known as Project Management Iron Triangle (budget, scope, timeline), technology dramatically increases their chances to do research or conduct new experiments, if an opportunity presents itself (often, unexpectedly). There is also a higher chance that more Scrum teams would be built out faster, if budgets were flexible and not done as ‘budgets against the wall’ (‘the world ends on December 31st’) – more flexibility to acquire new talent.
Vendor Management: Relying on same-old vendors-partners that are just convenient to engage because they are listed at the very top in a vendor management system, may no longer be viable. Engaging vendor companies on “fixed-everything” SOWs, while expecting them to work in an agile fashion may create tension and friction. Considering vendor-workers and a part of an agile team (e.g. Scrum, Kanban, XP), yet still treating them as ‘external workers’ and structuring communication with them, by going through engagement managers and ‘on-site leads’ would defeat the purpose of teaming, diminish transparency, collaboration and knowledge sharing, as well as would be un-supportive of healthy dynamics and interaction, expected of agile teams. Organizations should apply a different set of standards and benchmarks, when selecting vendors that are expected to engage in agile work (e.g., development, installation, configuration, etc.). Contracts and SLAs should be supportive of agile (adaptive) ways of working.
Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe is not as good as Scrum team placed on the same floor. (Note: Please, do not confuse a single Scrum team spread thin across multiple locations with multi-site Scrum product development, when many, whole teams are collocated but separated from peers-teams by geography).
However, putting a team on the same floor is not sufficient. Interior design must be supportive of team collaboration and dynamics: ‘caves & common’ (read A. Cockburn about XP), information radiation techniques (lots of whiteboard space, flip-charts), breakout areas, extra space to accommodate extended user community during sprint reviews, etc. – is all required. It is unfortunate but it is pretty common to see so-called Scrum team members sitting in a long single row, next to each other, spear-headed by a line manager (usually, a window seat), all joining a daily stand-up call by phone (while sitting!) and ‘reporting on status’, while staring at an electronic story board on their respective monitors. Agile teams don’t want that.
As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman: