Individual outcome can be accountable and not the emergent behavior

Something that I am thinking about... In a predictable, closed system, nailing down the accountability of an agent is feasible. However, in a complex adaptive system, the outcome is due to the interaction of many agents. The individual agents are accountable for their own actions but not emergent behavior or outcome. Large organisations are complex systems, however, the processes and policies are created with an assumption of predictability and individual accountability which are tied to the outcome. When the individuals KPIs and salary are tied to the outcome of a system with complex emergent behavior, individuals start demanding more control so that the outcome can be predictable. This, in turn, creates more stress on the system.

Newsletter 37: Why Sprint 0 is a cardinal sin

Interesting Articles Why using Sprint 0 is a cardinal sin for all Scrum Masters A Scrum Master using Sprint 0 is just as strange as an astronaut believing the world is flat. Scrum Masters should know better! Unfortunately, there still are many Scrum Masters who start their new teams with Sprint 0. In this article I will try to persuade you there is no convincing reason to use Sprint 0. So let’s start by figuring out why Scrum Masters introduce the concept of Sprint 0 to their team. What is Sprint 0? There is no official definition of Sprint 0, as it is not part of Scrum.   Sprint 0 conflicts with the core of Scrum Imagine you would strip Scrum of everything to reach the core of what Scrum is about. You would remove all the roles, events, artifacts and rules of Scrum to reduce it to its absolute essence. Scrum boiled down to a single sentence for a software development context would be: Deliver a working product every Sprint Sprint 0 clashes with the Empiricism of Scrum The foundation of Scrum is empiricism. Empiricism asserts that knowledge comes from experience and you should make decisions based on what is known. By doing you will learn more. You may use this learning to do better than you did before. By starting with Sprint 0, you have no product increment to inspect at the end of the Sprint. Therefore, your team will not run into the challenges involved with doing a real Sprint. Sprint 0 results in reduced transparency: you will not encounter the real obstacles involved with doing Scrum. This leads to worse inspection and less adaptation. You can read the rest of the article here     Look at Capability, not Title. Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team? With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment. This has unearthed strong opinions. Unfortunately, they don't converge on a single word or phrase. A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create”  a “Done” increment. Read the complete article here.   To read the rest of the articles and posts... You can subscribe to the newsletter here