Beyond the Sprint: Kaizen, #1

By Daniele Davi'

Unlock the Secrets of Agile Leadership with this indispensable guide by Daniele Davì. Designed for Agile practitioners at every level, from developers, scrum masters, product owners, agile coaches, to transformation leaders and executives, this book offers a wealth of insights to propel your career forward. Dive into over 50 thought-provoking articles that delve into the evolution, challenges, and advantages of Agile in today's fast-paced world. For scrum masters and Agile coaches, discover invaluable strategies for navigating organizational change and fostering a culture of continuous improvement. Agile practitioners will uncover hidden truths behind Agile practices and gain practical tips for driving positive change within their teams. Product owners will learn how to cultivate an Agile mindset and envision the future of their products. Senior developers and engineering managers will find guidance on overcoming common Agile anti-patterns and unlocking organizational success. And for CTOs and DevOps professionals, this book provides essential insights into Agile transformation and the keys to fostering innovation and driving business agility. Whether you're looking to succeed in your current role or advance your career to new heights, this book is your essential companion for mastering Agile leadership and achieving lasting results.

In Part One, journey through the pre-Agile era and witness the evolution of business agility. Uncover the hidden truths behind Agile definitions, practices, and frameworks, and gain valuable insights from real-world experiences. For scrum masters and Agile coaches, discover invaluable strategies for navigating organizational change and fostering a culture of continuous improvement.

In Part Two, explore the Agile landscape and gain practical tips for driving positive change within your teams. Product owners will learn how to cultivate an Agile mindset and envision the future of their products. Senior developers and engineering managers will find guidance on overcoming common Agile anti-patterns and unlocking organizational success.

In Part Three, empower your organization with the keys to unlocking success. Discover essential insights into Agile transformation and learn how to foster innovation and drive business agility.

In Part Four, gain valuable insights into coaching Agile organizations and cultivating an Agile mindset. Learn practical tips and techniques to drive positive change and achieve lasting results.

In Part Five, master Agile leadership and achieve lasting results. Whether you're looking to succeed in your current role or advance your career to new heights, this book is your essential companion for mastering Agile leadership and achieving lasting results.

• Language: English
• Publisher: Daniele Davi'
• Release date: May 14, 2024
• ISBN: 9798224642588

Book preview

Beyond The Sprint - Cover

Beyond the Sprint

Insights from the Frontline of Agile Leadership

Daniele Davì

Independently published

Copyright © 2024 DANIELE DAVI'

All rights reserved.

Beyond the Sprint: Insights from the Frontline of Agile Leadership

No part of this book may be reproduced in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the author.

Copyright © 2019-2024 Daniele Davì. Portions of this book have been published between 2019 and 2024 on the author's blogs: danieledavi.com and gramland.medium.com.

First edition published in: 2024

ISBN: 9798324733711

eISBN: 9798224642588

Imprint: Independently published

PV20240510050-57KCM3

The information contained in this book is based on the author's experiences and research. While the author has made every effort to provide accurate and up-to-date information, the author and publisher cannot be held responsible for any errors, omissions or for any actions taken by readers based on the information contained in this book.

Characters and events portrayed in this book are fictitious. Any similarity to real persons, living or dead, is coincidental and not intended by the author. The author has no affiliation with any of the organizations mentioned in this book and the views expressed in this book are solely those of the author. Any mention of specific companies or products is for informational purposes only and should not be interpreted as an endorsement or recommendation by the author.

Book design, logo, and illustrations by Daniele Davì

All rights reserved.

To Simay and Leonardo.

Contents

Introduction

PART ONE   The frontline of software development  in the Pre-Agile era

Manifesto for Agile Software Development

Ante-Agile, Agile, Anti-Agile:  the evolution of software development practices

Presenting the Manifesto for Anti-Agile Software Development

Explaining the anti-values

Explaining the anti-principles

The Now of Agile Manifesto between Tjukurpa and Komorebi

The Agile Revolution

Shiny Object Syndrome: trends, ethics, and the dark side of Agile

PART TWO   Beyond Agile Definitions

Agility, Agile and Scrum definitions

Agile SDLC — Software Development Life Cycle

Scrum as a SDLC

Scrum, Security and  Quality Assurance

Scrum and CMMI — Capability Maturity Model Integration

Kanban — the garden, the restaurant and the dump

PART THREE   Navigating Agile transformation  between promises and failures

About sprints, hamster wheels and ground-dog days

To be or not to be Agile?

Does Agile work? And who should answer the question?

Agile doesn’t work

Who gets to say who is Agile and who isn’t?

Stop!  Stop hiring Scrum Masters!

Overcoming organisational inertia

10 Red Flags indicating your organisation's need for transformation

The importance and impact of trust in organisations

Are you an Agile sales representative?

PART FOUR   Coaching Agile Organizations

Unlocking organisational success: who holds the Scrum Master’s leash?

A non-definition of almost done

No time for Agile meetings

Can Subject Matter Experts be good Product Owners?

Product Owners don’t need to be technical to be good

Envision, imagine, anticipate the future of your product

Questions bag to improve your Product Owner skills

What is a Spike in Scrum?

Lean and the 12 types of waste

Run Daily Scrum like a pro

Burn-down, burn-out, Stranger Things: the upside-down world of sprint metrics

Simple Agile metrics

PART FIVE   Cultivating an Agile Mindset

Kaizen

We Are Agile — How it started

How a strong team culture helps the team heal

Ways of eating, working, evolving in a bitesize

Living Waterfall, living Agile

Changes are welcome

Update yourself

From strangers to champions: leadership condensed in a goodbye letter

Leadership Redefined:  a coach's legacy through gratitude messages

Acknowledgements

About the Author

Other books from the same author

Beyond the Sprint

Insights from the Frontline of Agile Leadership

A Kaizen Book

DANIELE DAVI’

www.danieledavi.com

Introduction

I love writing. I do it almost every day, and I try to keep a consistent publishing rate of articles on my websites and blogs. Often it is more useful to me than to others. Sometimes I receive explicit appreciation for my contents from readers. At times I get some satisfaction in knowing that what I write can be useful to someone and even implicit statistics breakdown offers me useful feedback. I can see how many visitors and readers my blog has monthly, how many likes, mentions, reshares, and other types of interactions.

Shakespeare, Hugo, Čechov, Wilde and any other author could have only imagined what parts of their masterpieces the readers would like. Surely, they could get feedback from other authors, friends, collaborators, or get the reaction of the audience watching their show, on a specific day and place. They couldn't see what every single reader would underline in their manuscript or where they would put an annotation. The platform I use to publish most of my articles (Medium) allows me to see when someone underlines my content, what sentences create the most interest, what articles are added to favorites lists, or thematic reading list. Readers can comment or clap and I would know the name (or username) of the person who interacted. In a sense, I am luckier than many great authors, as the technology offers me statistics, numbers, evidence, comfort, protection, and support to overcome the impostor syndrome.

Unfortunately, the other side of the coin is that digital content can theoretically disappear at any moment. The platform I use may shut down, some backup may get lost, and if that will not happen before, anyway one day I will be so old that I will not renew my domain, I will not be able to update my WordPress or I will not anymore be around to manage the hundreds of articles written during the years. A temporary, fragile, and fallacious solution to this issue consists in publishing these articles as a hard copy. The solution is temporary because all things have an end, including our civilization, planet, solar system... and printed copies are less durable than the digital copies. Once something is published online it is almost impossible to unarchive it from the web. A printed book doesn't survive contact with fire, water, or damp.

Digital content is easily searchable, more consumable, and more useful. A printed magazine from the '80s or even an encyclopedic volume from the '60s are ways to store info that aged pretty badly. Nowadays, even for printed magazines it is better and easier to access and consult the digitalized version. Only a collector would find value in printed items and only if the author, content, and edition would be really important. Yet, digital content is immersed in a fast-growing ocean of noise and data production. And with so many people publishing content generated by AI, who knows if we (whoever writes and produces unique and original content) are the last generation of creative content human creators.

My articles are entirely written, ideated, typed, and published by me. And it bothers me that my content could get mixed and confused with AI generated stuff. I am not against AI content generation. I use AI as a quicker powerful extension of the web (Clippy, Google, Wikipedia...) to correct my grammar, find synonyms, or gather information. But what I write is generated by my brain.

Suspending any judgement around the possibility that our world is just a simulation, for now, and for the sake of this topic I will stick with Descartes's philosophical milestone: Cogito ergo sum – I think, therefore I am.

So far, we have established that I love writing and publishing digital content and observing the interaction with readers has been great. I would like the same digital content to be stored in a paper format, a book rather than a magazine. Here I am, writing this introduction to my book, after maturing the idea to collect part of the articles written so far into a book.

This work is a classic example of repackaging previously published content into a book format. This collection of articles is arguably more serious than The Essential Calvin and Hobbes but funnier than annual letters to shareholders compiled in The Essays of Warren Buffett: Lessons for Corporate America. Someone might say it is like Dilbert without the pictures. The topic that unites these articles is mainly given by the professional life, changes and evolution of a software engineer that moves from hands-on engineer, to Scrum Master, Agile coach, transformation agent, engineering manager, sherpa, chief technology officer. Many of the common issues, debates and challenges observed and exposed in this book, are experienced daily by teams and organizations all over the world.

Whilst my original idea around this book was to use my published articles to write a homogenous, complete book about Software Development, Agile Coaching and Business Transformation, I realised that I have written so much material that wouldn’t fit in one book only. I also feel I will keep writing about these subjects in the close future. At the same time, I feel the urgency -justified or not- to preserve my articles as originally written and published almost with no edits. I realised that the articles I wrote up to now would cover many more topics and fill two or three books. Therefore, my decision, at least for this first edition, to collect the articles published so far around software development team safety, scrum, agile, lean culture, and practices and publish them as a collection.

What’s in here for you? Why should you read this collection of articles? Literature -fiction or not- tells the reader You are not alone. You are not the first one nor the last one, having similar issues: while writing code, while dealing with office politics, teammates, managers, colleagues, executives, coaches, clients. Believe it or not, many professionals have been in the same situations or perhaps worse ones. Nevertheless, your frustration is a valid feeling, emotions are data, your thoughts, and ideas important. You are not alone in facing your challenges. Some of these challenges and anti-patterns are exposed in this book together with some solutions or useful approaches.

I hope this book will make you feel less alone and more hopeful. I hope, while reading these pages, you will find the courage to go on, to feel more backed up, to understand that you are part of a community -mostly silent, sometimes vocal- across lands, oceans, industries, or jobs. And I like to think that this book will inspire you and support you in the good and bad days.

Enjoy the book!

PART ONE

The frontline of software development

in the Pre-Agile era

Manifesto for Agile Software Development

On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat. What emerged was the Agile Manifesto for software development.

Values

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Principles

We follow these principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in

development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity -the art of maximizing the amount of work not done- is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ante-Agile, Agile, Anti-Agile:

the evolution of software development practices

Have you ever developed software in the ante-agile (pre-agile) era? I did. There were individual developers pulled by different project managers, asked to interrupt whatever they were working on to complete trivial or gigantic urgent tasks. After being pressured and stressed, most of the time that request turns out to be either not so important, valuable, useful. Often, developers were working individually and partially assigned to competing projects according to the programming language they knew or even according to office politics. There was not always the idea of a team or a squad or other forms of cross-pollination. Each developer may have been reporting to a different project manager and if involved in three, four or N projects, that person would report to three, four, or N different people. Developers working on internally competing projects were asked every one, two or four hours why a task wasn’t yet done.

They were asked to write exhaustive technical documentation that no one would ever read, no planning, no alignment. In some cases, they would be able to make one or two go-live per year. Automation and testing were in some cases a luxury, an expensive dream, something considered a waste of time, resources, or money by managers. Continuous Integration, Continuous Delivery, Configuration Management, DevOps practices, all modern software development frameworks rooted in the Lean and Agile movements… were not there at all.

The evolution from opportunistic (i.e., ad-hoc) programming habits to structured methodologies led to improvements in both innovation and standardization. Introduced by pioneers like Ed Yourdon, Tom DeMarco, and Ken Orr, structured methods and diagramming aids became popular. In the mid-80s, under the influence of command-control management of the day, emerging prescriptive project management practices, and the growing popularity of waterfall life cycles, Monumental Methodologies (MM) were born. MM’s proponents wanted to bring in a level of formality and discipline into software development in an attempt to equate software engineering to other engineering disciplines. Although engineers are usually prone to embrace disciplined approaches, the middle management and office politics around them were often bringing chaotic and incoherent, always urgent requests.

The era of Monumental Methodologies and Computer-Aided Software Engineering (CASE) tools was a defining period in the history of software development that introduced a great deal of structure and formalism into a field that was wrestling both with its rapid expansion and with increasing complexity. At the same time, it clearly showed the pitfalls of an overdose of documentation, complicated tools, competing priorities, unclear responsibilities. In some places there were too many stupid and strict rules. In some others there was too much chaos.

Was it all like this, everywhere? No.

We know there were also some high-performing teams. But we know they weren’t the majority. One of the great things about software development is that the situation early on was so bad, and so much money was being wasted (billions of dollars each year) that people spent a lot of time studying why, so at some point there was data on everything, and many people not knowing what to do with it. One study conducted by Jim Coplien examined a Borland Software Corporation project called Quattro Pro for Windows. For the project one million lines of software code had been created. They took only eight people to write them in thirty-one months. That means each team member produced one thousand lines of code each week. That was the fastest of any team on record. These teams were exceptional not just because they were delivering impressive results, but literally because they were an exception compared to the majority. Something to study, hoping to extract a sort of formula, a natural law, or a biological or chemical or sociological truth.

Some of the ingredients used to cook the secret sauce of success in the above-mentioned Borland team became an essential element of Scrum (e.g., the daily meeting). Studying these successful teams inspired practices and frameworks that tried to synthesize the key factors of success. Engineers started taking into consideration these new ingredients: the people factor; everyone’s motivational need (autonomy, mastery, purpose); organising individuals in small teams with clear and meaningful purposes; the feedback loop typical of engineering empirical processes; having decision makers within the team; having some engineers sitting at the big table; self-determination, self-actualization, and self-organisation of autonomous teams; and many others changes.

In 1978, Tom DeMarco’s Structured Analysis and System Specification sparked the structured software development movement.

In 1986, after the explosion of the Space Shuttle Challenger, the team that was called to reform NASA, embraced some of the emerging new principles for software development.

In 1986 the Harvard Business Review published a paper titled "The New New Product Development Game". Most of the Scrum practices were just good practices used by people that didn’t care to label them. Scrum took them and codified them and summarized them on a guide… and nowadays too often Scrum practitioners misinterpret many of these practices. Scrum is not the only and not the first Agile framework.

The rise of Agile frameworks in the ante-agile era (before the Agile Manifesto was published) reflected a growing response to the madness of rigid, formal, and monumental methodologies. Agile approaches embraced the discipline envisioned by structured methods, yet in a way that valued flexibility, collaboration, and customer collaboration. The first Agile advocates began to understand the difference between formality (MM) and discipline. For instance, Crystal Clear and Extreme Programming (XP) are very disciplined, but not formal. In 2000, Kent Beck’s Extreme Programming Explained: Embrace Change, sparked the Agile software development movement.

On February 11–13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground — and of course, to eat. What emerged was the Agile Manifesto for Software Development.

Ante-Agile or Anti-Agile?

When I published the Manifesto for Anti-Agile Software Development my idea was just to use the format of the original Agile Manifesto to write a sarcastic and irreverent little list of anti-values and anti-principles I observed and experience both the in the ante-agile era (before the spreading of Agile practices) and strongly anti-agile (adverse to agility) environments.

The two words differ for one letter only (in the prefix) and the two worlds that they represents (ante and anti) are so similar to each other that after writing this manifesto and the respective explanatory articles, I realised these two worlds, the pre-agile one and the against-agile one, are so similar, that they are almost the same.

A business environment where people were unaware of Agile because