Purpose of a case study:
The purpose of writing a case study was to re-live the experience of Large-Scale Scrum (LeSS) adoption, by going back in time and memory to everything that was done by me – the agile coach, trainer and organizational design consultant at a large financial institution. This engagement was done in conjunction/partnership with my former trusted colleague Stuart P. (also, an experienced agile and software engineering coach). Writing this case study gave me a great opportunity to self-reflect (retrospect) and think about what I could have done differently back then, if I had to go through adoption again. The name of the organization, as well as names of people, products, projects, applications, components, etc. that were involved in the study are intentionally withheld, for confidentiality and privacy protection reasons.Nevertheless, hopefully the case study, when published on less.works will serve as a guideline to others, in their attempts to experiment with LeSS adoptions in their respective organizations. It is worth nothing that many existing LeSS case studies on less.works had provided my former colleague and me with some great references when we worked on our artifact piece.
More About my Mentor:
Dynamics of Case Study writing:
From time to time, my mentor would also share his own experiences and give his own perspective like mine, or related situations. This made our mentoring more interactive, engaging and fulfilling.
How did I decide on the scope of my case study?
One of the most important mentoring ‘aha moments’ for me was the decision on how many LeSS experiments that were actually used during LeSS adoption did I really want to describe in detail, as a part of my case study.Here, one of LeSS adoption concepts came to rescue: Deep & Narrow is better than Broad & Shallow. I consulted with my former colleague-coach on how many of our LeSS experiments and experiences do we really want to discuss and how deep. We agreed on the shorter list of experiments that represented the crust of our work and could be aligned with logical and chronological sequence of events, as we remembered them. We made our selection described experiments, based on what we felt was most important during the adoption, relevant to the case study and memorable to us, as coaches. I consulted with my mentor on the final list and the overall approach and based on his recommendations, proceeded with deeper dives into the case study.
A picture is worth a thousand of words.
Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.
Experience Report by Guest-Blogger Ram Srinivasan
Experience Report by Guest-Blogger Mark Uijen de Kleijn
LeSS Graphic Art
Personal Memorable Moments
Next LeSS conference (2019) – Munich, Germany
- Wrote Extreme Programming Installed (also with Ann Anderson)
In 2009, developed for Scrum Alliance the Certified Scrum Developer program
- Taught the first Certified Scrum Developer (CSD) course
- Have been curating the Scrum Alliance’s Agile Atlas website
- Created the SA’s official Scrum description, Core Scrum
- Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.
This is what Chet had to say about the course:
“Chet Went to Craig’s LeSS Course”
Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.” That pretty much sums up my feelings about Agile at scale.
Craig’s organizing principle for the course is that in order to successfully use these ideas, you must own them. Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself. To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.
Some more Kodak moments from the event are below:
Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.
More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.
With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum. It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework. On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.
Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner? Well…
- LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner. LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block. Understanding basic Scrum made understanding of LeSS very easy for everyone.
- The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in. Everyone in class was an educated customer. Importantly: there were no attempts to change LeSS (or change training content 😊 of LeSS), to make it better fit conditions of organizations, where people came from.
- Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.
The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)
One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many). And it goes as follows:
…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle). ‘Agile’ won because of the reasons that are described here. Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible. We all have to be careful with the meaning of words we use, to avoid this painful irony😉.
Here are some Kodak moments from the event:
Tonight -a great presentation by Malik Graves-Pryor of Natoma Consulting, as he shared how his company leveraged LeSS to achieve stunning results, while facing challenges and learning lessons.
At the Thursday October 12, 2017 NYC Large Scale Scrum Meetup, Malik Graves-Pryor shared his company’s LeSS case study, “Web and Mobile Applications Agile Transformation”. He covered the extensive issues the company faced at the beginning ranging from only 1-2 releases a year with hundreds of defects, and how they transformed over the course of several months to an organization that released monthly, and then continuously, with low defects and high customer satisfaction and engagement.
The discussion covered the merger of the Sales and Product Management Pipelines, adoption of technical practices leading to a DevOps-focused culture, how to take the necessary steps to build trust and cooperation within the organization, as well as the road-map they used to iteratively migrate the organization to continuous integration and deployment.
The interactive discussion spanned two hours with attendees raising questions and issues about the case study, as well as correlating them with their own challenges and aspirations.
Presentation deck is available at Natoma Consulting website for download.
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:
[also, cross-posted on less. works]
Large Scale Scrum (LeSS). It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner. In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.
What is Organizational Design? To understand it better, let’s look for analogy in construction industry. What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).
Imagine two buildings: Building A and Building B.
Building A uses brick as its main foundation block. In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick. Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.
Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick. Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor. Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall. Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.
When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems. Waste removal can be mostly done manually, by building residents. Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.
Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.
This is what building A looks like:
Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.
Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement. The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between. This means that the overall weight of building B is dangerously high (foundation can crack). The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design. If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.
Waste disposal is a serious issue for Building B. While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper 😊), there is a huge amount of waste that gets accumulated at middle floors – and it sits there. It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized). Sometimes, waste gets moved to floors above; sometimes – below. This creates an illusion of waste removal. But waste remains.
Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order. This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.
Finally, building inspection and maintenance is a nightmare for Building B. Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.
This is what building B looks like:
Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.
Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams. There are no additional roles required for coordination. Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).
If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick. Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks). Now, LeSS becomes LeSS Huge. The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint. In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together). Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.
By design, LeSS foundational structure is very lean: flat, fungible and cross-functional. There is no waste or overhead with roles, responsibilities, events or artifacts. Everything is very minimalistic. If any waste is generated in LeSS, it has practically nowhere to hide.
Because there is so much transparency in LeSS, waste is seen immediately. Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively. Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist. There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.
What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.
Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!
Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures 😉.
Signed: ____________The Organizational Building Management 😉
What is the best Sprint length? Who decides on Sprint length? Are there any exceptions? What are some of the most common mistakes people make, when making decisions about Sprint length?
Let’s start from grassroots and answer the following basic question: “What is Sprint main goal?” And while looking for an answer, let’s refer to the Scrum Guide, where the goal of each sprint is clearly described as “…increment (a.k.a. PSPI = potentially shippable product increment) that must be in usable condition and meeting DoD (Definition of Done)”. From the Scrum Guide perspective, it is also clear that while being potentially shippable, an increment does not necessarily have to be shipped. Why is it so? For PSPI to be shipped, it must also represent MMP (Minimal Marketable Product) and the decision about what is marketable comes only from Product Owner and it is based on several factors, including long-term strategy and economics.
(Note: End-of-Sprint deliverable, sometimes, is also referred to as MVP (Minimum Viable Product) and is described well by Roman Pichler here.)
Sprint Length and Release Economics
Speaking of economics, lets recall the relationship between Transaction Costs (Shipping) and Holding Costs, also described in “The Principles of Product Development Flow” by D. Reinertsen. By analogy, if applied to Scrum product development, ‘batch size’ would represent a volume of PSPI and ‘cost’ would represent all combined efforts, associated with production deployment (e.g. integration, end-user training, marketing announcements, etc.).
How does this relate to Sprint length?
While each Sprint is supposed to produce PSPI, it is only Product Owner’s decision ,when to release it (MMP), depends on finding a “sweet spot” between the two types of cost: Holding and Transaction, or if spoken, in software development terms, costs of code deprecation/aging and costs of deployment. On the graph above, it is illustrated by the lowest point of Total Cost curve and it is responsibility of Team and Product Owner to determine what it is.
Corollary to having both strategy and economics changing over time, release frequency may change as well. It would be natural to assume that sprint duration and release frequency are related too. Indeed, the need to release more frequently may lead to sprint shortening, and vice versa.
Are there any other external factors that may influence Sprint frequency of a single Scrum team? The most classic example would be Scrum by multiple teams that sprint together (e.g. LeSS, S@S): develop the same product, for the same Product Owner, and share the same a backlog. While release economics principles would still apply, the situation with scaling may become more complex if multiple teams are tasked to select a shared cadence. One assumption comes to mind immediately: if multiple teams sprint together (synchronously), then their shared PSPI (overall output) will be more substantial (“voluminous”) than that of a single team, and from a Product Owner’s point of view, may sooner merge the gap between PSPI/MVP and MMP (more about factors influencing Sprint length below).
In other situations, e.g. in non-scaled settings, individual Scrum teams could be dependent on other teams (Scrum, Kanban, Waterfall groups, etc), separate organizational domains or external vendors that operate on their own cadence. In such cases, product backlog refinement and sprint planning becomes even more challenging. As a result, sprint length, as well as frequency of scheduled production releases may be impacted.
Who Ultimately Decides on Sprint Length?
Just like any other decision about Scrum team dynamics, the decision on sprint length belongs to a team. Nobody should be deciding how to structure or manage work, on behalf of people that actually do it. Neither Product Owner, nor stakeholders, nor management, nor anyone else. Teams that are new to Scrum may experiment with sprint length at the beginning, while trying to optimize to conditions that are very specific to a team’s dynamics. The best time to self-assess and decide if sprint length should be changed is during a retrospective, when decisions about process improvements are made; and it is done by majority voting. Only in rare cases, when a team has a difficulty to reach consensus, ScrumMaster , who owns Scrum process and plays the role of an arbitrator in retrospectives, can step in and help a team make a choice. This should happen rarely, as frequent lack of consensus might be a sign of deeper team dysfunctions. Initially, during team formation, and before ScrumMaster is elected, Scrum/Agile coach may help team with sprint length selection. Mike Cohn describes his personal experience in a similar situation here.
Factors to be considered while selecting Sprint length?
As a rule of thumb, sprint length should not be shorter than 1 week and should not be longer than 4 weeks. If there is a strong reason to make sprints shorter than 1 week (e.g. could be driven by production release frequency requirements), Kanban, instead of Scrum, could be considered, since it offers, on demand and almost instant, release capabilities. On the other hand, extending sprint length beyond 4 weeks may lead typical challenges of waterfall (sequential work, silos, hand-overs).
Statistically, anywhere between 1 and 4 weeks, a team should be able to establish a steady and healthy cadence to do product development.
Shorter sprints do have certain advantages:
- More frequent sprint reviews and retrospectives – shorten feedback loops that allow applying improvements to product and process development, respectively.
- Shorter sprints require lighter sprint planning and, subsequently, reduce the risk of going too deep into a product backlog and selecting items for a sprint that do not meet DoR (Definition of Done) and are not INVEST-able.
Shorter Sprints may also bring some potential challenges:
- For example, the ratio of time spent on sprint preparation and process management to time spent on actual product development could be high – too much procedural overhead.
- Additional important prerequisites must be met, before moving teams to shorter sprints. For example, if a sprint becomes too short (e.g. 1-week) and there is no full test automation and no TDD, then a team may have a difficult time, keeping up with testing: after completing a few sprints, as the amount of code base increases, manual testing will fall behind. As a result too much work may fail DoD by Sprint-end.
Relationship between Sprint length and Scrum Maturity
It would be reckless to claim that there is a direct cause & effect relationship between sprint length and maturity. Some research indicates (some was done by Jeff Sutherland) that for as long as a sprint is under 1 month, there is no strong and immediate correlation between sprint length and performance. But anything beyond 4 weeks lowers performance and introduces elements of waterfall dysfunction to a team’s dynamics.
What is, by far, more important than sprint length is sprint length consistency. While in early stages of sprinting, it is normal for a team to experiment with sprint length, if length “juggling” continues into later sprints or happens ad-hoc, it could be viewed as a sign of deeper problems. Some teams falsely believe that by periodically extending a sprint they will be able to get more work to Done state. Thinking more systemically, this is a false assumption, as cadence- and task-switching, especially done by multiple teams, can significantly lower overall output. Further, inconsistent sprint length will lead to difficulty of sprint planning, unstable velocities and unreliable long-term forecasting.