Welcome to the Home of Scrum!

In this article, I want to clarify the need for agility in modern businesses and what agility in organisational design actually is. Today’s mainstream organisation structures are systems we inherited from the industrial era when employees were illiterate and the leaders were educated, market-entry criteria were high and markets were predictable. We see that the future of many established businesses has become uncertain. Businesses need to exceed customer expectations in buyer-driven markets. Customisation is the norm and copying a competitive advantage has never been easier. Innovations and changes supersede at an increasingly high pace. For example, in the financial sector, many disruptors enter the market. These newcomers do not carry the burden of legacy IT systems and can offer new services at the flick of a switch. They put pressure on the existing businesses. The hierarchical organisational design Hierarchical organisation structures were created in the industrial era (approximately 1890). They were designed to optimise for: Accountability: Easily locate the cause of errors. Efficiency: Factory workers are resources that can be optimised. This design produced an organisational structure with separate departments for every task that a business requires: Production, Accounting, Sales, Marketing, HR, IT, etc. Within these single-function departments, tasks were further split over functional or technical specialist teams. This organisational design looks much like a pyramid and suggests that there is one person or a small committee of leaders that steer the whole organisation. This organisational design has undesired side effects. Steering mechanism Leaders steer the company using a vertical feedback loop: Command is flowing from top to bottom Control is flowing bottom-up in the form of reporting. Value is created in a horizontal flow (for example from R&D to production, packaging, delivery and customer support), but the steering mechanism is vertically oriented. Commands are issued at the top of the organisation and need to be decomposed across departments to become executable by specialist workers. The centralised command is delegated over multiple management layers. These are vertical handoffs. For each handoff, there is a change of context that requires reformulation and reinterpretation of commands as they drizzle down the hierarchy. That’s also why feedback data gets skewed as it bubbles up. Investments are required to decompose the work and to implement reporting structures. Specialist teams Many teams and departments only perform a single type of task. To assemble a working product, all work delivered by teams or departments needs to be assembled in the value chain. This requires many horizontal handoffs, which are sources of misalignment due to information scatter and communication barriers. This complexity is commonly managed by adding coordination roles, which leads to thick management layers. (I have been in companies where each team member had three different managers to report to!) On top of that, people in charge of coordination do not do the real work themselves which increases misinterpretations. Customer feedback Nowadays, a company’s chances of survival are low if it takes too long to create (new) products. Our company becomes slow if we need a number of teams, each producing a part of the product, to be able to create possible customer value. The specialised team approach creates many dependencies between teams when we try to create customer value. We only know if our product (or change) is successful after releasing it in the hands of the customer because that is when we get real feedback and our assumptions are validated. The slower our company is, the longer it takes before we get customer feedback, i.e. return on investment (if any). That’s why when speed is low, development requires big investments. Product understanding Deep specialism creates difficult communication at the product level. That’s because the teams have a local focus on specialist tasks without sufficient customer-centric context. Some teams do not even know what value they are creating from a customer point of view: the workers have never seen a real customer or they don’t have one because they deliver so-called “products” to another department. Local optimisation Because resource optimisation is one of the primary goals, the organisation will try to produce constant flows of specialist tasks to keep everybody fully utilised. If there is not enough work available, teams will find work themselves. Chances are big they will over-optimise their part of the product, i.e. produce things that the customer does not want at all. Design changes Leaders experience difficulties in getting the organisation to deliver customer value, even on relatively short term plans and want to improve the situation. To improve the performance of their organisation, they replace managers, add teams, reorganise to redistribute responsibilities, run value stream optimisation projects, introduce Scrum teams, etc. Internal communication campaigns and reorganisation programmes are needed to mobilise the employees because it’s quite a challenge to get everybody informed. After a while, the applied solutions lose their effect. This is because the measures taken do not address root causes. For example, if we transform our existing silo-teams into Scrum teams, delegation, handoffs and information scatter will not disappear, because that change does not resolve the silo-problem. The problems become less visible temporarily, giving an illusion of improvement. Many organisational design improvements do not interfere in the system deeply enough to create a systemic, sustainable change. Six Agile ingredients To mitigate the undesired effects of a traditional organisational design, consider updating the organisational design with some Agile ingredients. 1. Organise around value creation Over time, organisational optimisation goals have shifted from accountability and efficiency towards focussing on producing value. The organisational structure was not changed to support such very different optimisation goal. We should organise ourselves around the creation of customer value. This means that all effort done in the organisation that does not create value or contribute directly to value creation is wasteful and should be eliminated. Adhering this rigorous approach will make coordination and management roles redundant. And this implies that producing value is done in close collaboration with the customer. 2. Empower self-organising teams Our work is complex and without the freedom to be creative, it is unlikely people will produce the highest possible value. We should provide people who create value with value-driven goals. We hand over decision power on the work to the people who actually do the work. 3. Speed To obtain speed, communication lines need to be short and the number of communication lines needs to be as small as possible. We prefer smaller groups of people to self-organise and do the work. Next, we eliminate inter-team dependencies by ensuring each team can deliver value independently and by giving teams a synchronous shared goal to stimulate collaboration. Finally, centralised product management is faster because it simplifies product development effort. 4. Flexibility Single function or specialist silos as a building block for organisational design create inflexibility. We need to restructure the way we govern and run our organisations in such a way that the ability to change is intrinsically embedded in them. We should stop having single-function teams or departments. Flexibility is attained if all (or most of) the teams have all the knowledge required to create customer value independently. By consequence, the work that needs to be provided to the teams can be the same for all teams, which simplifies product development effort. 5. Learning The difference between extinction and survival in the wildlife is the flexibility to deal with unforeseen situations and the ability to adapt, or in other words the ability to learn. It is no different for business-life. To increase chances of survival it makes sense to try to create an organisational environment that allows us to do lots of learning. We need to embed empirical feedback loops to create fast continuous improvement cycles on the product, the processes and the organisational structure. 6. Servant leadership When employees are highly educated people, transferring responsibility for delivering value to self-organising teams should not be a problem. However, doing so requires trust and a different management mindset. Leaders should give people direction and create a learning environment. Leaders steer by providing the teams vision, structure and policies. Feedback data is collected by measuring “outside-in” rather than “inside-out” (customer-generated outcomes versus internally generated output). Summary For over 200 years the hierarchical organisation structure has proven to be stable and reliable to deliver customer value that makes profits. In the 21st century, organisations should update or change their model with agility to face the rapidly changing world. The six ingredients for an Agile organisation design are: Organise around value creation Empower self-organising teams Optimise for speed Optimise for flexibility Optimise for learning Guide with servant leadership

Should the PO really balance the level of technical debt? I just had this conversation yesterday at Sweden's "big" agile conference, Agila Sverige. There were many interpretations, understandings and strategies around this. I think it mostly boiled down to these two ways of looking at and arguing around it: On one hand: what is different about technical health/debt, than say features targeting a key stakeholder's user base? Isn't tech debt/health just one aspect of the product, coming from one stakeholder (Development Team in the tech case), that the PO needs to balance with other aspects? On the other hand - the Development Team is accountable to the (technical) quality of the increment (and thus the product), and continual refactoring is something they perform on a daily basis, as needed, to keep the product's tech health in check. Two Cases, Two Sizes In the conversation that was had, this more or less boiled down to two cases: A) the work that needs to be done, is such a big change that it may not be completed in a Sprint and/or will require a major effort from the team. Risk and Cost is "real" and is considered to be on a level where the PO should at least be informed. I.e., this work needs to be challenged by other work and decided upon, at least in part, by the PO when the right time to do this work, is. B) the work to carry out is not of the size above, and thus is just part of Dev Teams daily work and accountability. Development Teams not spending enough time doing B type of work, might more often end up with A types of work, requiring them to more often argue/explain/motivate why that work is important to the PO. This is not the only way to end up with A type of technical rework, but not paying enough attention to technical soundness, coupling and cohesion, etc, may very well be a source of this type of work. I also argued, that If this happens a lot/often, the Scrum Master should perhaps pick this up (that A happens a lot), and help the team assess whether they're spending enough effort on design and implementation strategy. Tech Debt Inventory List So what about assembling some of those B-sized things in a list, so we don't loose track of them? Isn't this a violation of the idea the the Product Backlog is the only source of work? Again, I'd like to argue both ways: Yes, if this list starts to grow, such that it regularly accumulates into A-sized work, then this may become a problem. No, this is not a Product Backlog where the value of items needs to be weighed against each other by the PO. This is just a small reminder of things we should fix in the short term as we conduct our regular development of selected PBIs. This is similar to working with a test backlog (as described by Kent Beck in Test-Driven Development) - it's just a way to help the Dev Team stay focused and do their normal work in the Sprint. Final Words Scrum is a small framework. The world is big, and there's no way one size fits all. So - as with everything Scrum, empiricism wins: try one way of doing it, reflect upon it and then keep as is or try something different: inspect and adapt. Other Resources In a fairly recent Scrum Pulse, Mark Noneman talks more broadly about Dealing with Technical Debt - what it is, where it comes from and ways to live with and adress it.

The topic of my blog today is another one that is common on client’s sites. The use of the terms Showcase, Show & Tell or Sprint Review. In this situation, there is likely to be a broad mix of people fulfilling the Scrum Master roles.

A Sprint Goal is not often something people think about when using Scrum. Turns out it’s really important for teams to act as teams. Find out why in Robb Pieper's latest video blog from Responsive Advisors.