When we ask an experienced scrum master, product owner or developer define a user story, they usually understand that “…every user story must be INVEST-able…(taken from B. Hartman’s post)”.
When we further elaborate on the “INVEST” part, we discover that splitting a user story is done vertically (along features), not horizontally (along components e.g. applications layers). Why is this important? Because when we split vertically, and cross-cut through multiple components, a user story represents a potentially shippable product increment (PSPI). On the other hand, delivering, UI/UX by itself, or business layer by itself, or database by itself, does not present value to a buying customer (the aforementioned are just unintegrated components).
Sometimes, we hear the analogy of a sushi roll, applied to a user story slicing technique: “…each user story must represent a thinly sliced sushi roll that provides the taste and flavor of multiple layers (caviar, seaweed, rice, tuna, avocado, etc)…”
Now, imagine an organization that undergoes agile transformation. Typically (and we are not suggesting that this is how it should be), transformation efforts originate within R&D, where agility comes in the form of improved engineering practices, such CI/CD, TDD, unit test coverage, trunk-based development, test automation, etc. This is all great but technology alone, is just one layer of an organizational sushi roll. Just like seaweed of a sushi roll, R&D improvements are not “tasty” enough: additional organizational layers must be also included in the effort and it must be done from the very beginning (not in later phases).
What are some of the layers that must be included in deep & narrow agile transformations:
Business & Operations: it is imperative to have real customers and users intimately involved in agile transformation efforts and make them closely aligned with technology partners (not through layers of organizational layers of reporting and control). This requires organizational DE-scaling (flattening) and identifying and empowered/well-positioned strategically product owner, along with stakeholders and SMEs. Organizational DE-scaling, is a very serious undertaking that heavily depends on genuine support @gemba, by executive management (not just support in spirit and funding).
HR: Subjective individual performance appraisals, a.k.a. IPAs (and individual bonuses) performed by line managers should be abolished or, at least, changed to team-based performance, with more objective distribution of discretionary moneys. One of the biggest problems that IPAs cause is internal competition and rivalry among employees, and it further prevents collective ownership and responsibility sharing. Also, a career path and promotions must be decoupled from employees’ “I need to become a manager” mentality.
Budgeting & Finance: For agile teams (Scrum, Large Scale Scrum, XP, 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), R&D improves its chances to spend more time on research and experiments, without fear of missing a promised (my management) delivery dates. Also, if traditional, year-end fixed budgets that cascade down from the top through fake portfolios, programs and projects, to fund temporarily assembled ‘project teams’ are substituted by dynamic, rolling-wave, pro-DUCT centric budgets, we can much more effectively fund long-lived, product-aligned cross-functional feature teams.
Vendor Management & Legal: Relying on same-old vendors-partners that are just convenient to engage with, because they are listed in a vendor management system, may hinder adaptive ways of working. If legal contracts are written in a legacy fixed-everything language, they will, most likely, optimize for “us vs. them”, instead of “us together”, referring to a client and vendor company. Engaging a vendor company on fixed-everything SOW, when a hard year-end delivery date is expected, yet requesting it [vendor] to work in an agile fashion (e.g. Scrum) and deliver incrementally, is very unlikely to happen: a legal contact shall prevail. Including vendor-workers in internal teams (e.g. Scrum, Kanban, XP), while still treating them as ‘external workers’ and communicating with them through engagement managers and leads, would defeat the purpose of teaming, diminish transparency, collaboration and knowledge sharing. Organizations should apply a different set of standards and benchmarks, when selecting vendors that are expected to engage in agile work. Agile contracts and SLAs should be used instead of traditional ones.
Real Estate & Facilities: Having agile teams co-located under the same roof is a huge win: e.g. Scrum team dispersed around the globe (and/or widely separated time zones) 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. For teams that have to work virtually, state-of-art technology must be available to offer the best possible audio and video experience. 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, overseen 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 do that.
What Is A Parallel Organization?
It is an autonomous organizational structure that is built from ground-up, right next to the original organization, in a way that allows meeting all of the aforementioned organizational characteristics (and more), but on a much smaller scale. Instead of doing broad & shallow “big bangs” of superficial changes, while fighting tough battles across an entire enterprise that involve tens of thousands of people and lead to an enormous resistance from everywhere (fear of unknown, uncertainty about impact, huge economic risks), it is best to run a future state-to-be organizational design experiment, by providing maximum possible support to a new structure, without putting at risk (including, reputational) the rest of an organization.
This approach requires a lot of support that must come from the very top of an organization, with executive managers willing to make deep and narrow, systemic organizational changes, to build an organizational structure that would be simpler, flatter and more consistent with a company’s system-optimizing goals (e.g. short cycle time, customer centricity, product focus).
It is imperative to understand that a parallel organization is not just a mini-clone (“mini-Me”) of the original organization. It is a completely new (flattended) structure with improved HR norms and policies, budgeting/finance and other organizational domains.
The following quote that describes sushi-roll-like parallel organization in Large Scale Scrum (LeSS), by one of its co-founders C. Larman:
