Andrew's Agile

What's the opposite of fragile?   Most people's immediate answer is "robust" or "resilient". But consider… if we subject something that is fragile to stress, shock, randomness or volatility, we can expect that it will be harmed. If we do the same to something that is robust or resilient, we can expect that it will resist harm - but won't be any better off than when we started. But what if something that is subjected to stress, shock, randomness or volatility actually benefited ? That would be the opposite of fragile: antifragile. This is the core theme of Nassim Nicholas Taleb's book Antifragile: Things That Gain from Disorder .   What does fragility and antifragility look like?   As human beings, we often think of things that have uncertainty or randomness as having a range of possible outcomes that are centered around some "most likely" outcome, as in the diagram below.     However in many domains, there is an asymmetr

When I walked into the room, I noticed the haphazard arrangement… 3 short rows of 4 chairs each here… a circle of chairs over there… a couple of comfy couches and chairs surrounding a coffee table in that corner… 4 chairs around a small table… and some chairs in random locations, as if shaken up like a cupful of dice and somehow landing on their feet. I sat in the front of the 3 short rows. Other people were arriving, sitting down in various places in the room. We were waiting for the session to begin. After a while, something entered my awareness… at the circle of chairs, there was a lively conversation. At the comfy couches, there was a lively conversation. At the chairs around a table, there was a lively conversation. But in the rows of chairs… we had greeted each other as we sat down, but we were not now engaged in conversation. I turned to the people near me in the rows, pointed out what was going on in the other circles, and suggested that we turn our chairs into a circle. Lively

In conversations regarding technical debt (and technical improvement), I often hear that there is an understanding gap between technical people and business people. As an experiment, I thought it would be interesting to attempt to bridge that gap by illustrating what technical debt looks like, with an analogy. The Conversation Setting: “Widgets Inc.”, a manufacturing company that makes widgets Characters: Max – VP Sales – responsible for making sales commitments to customers John – Plant Manager – responsible for manufacturing the widgets January 2nd: Max: Hi John, tell me where we are from a production perspective. I have two big customers breathing down my neck. John: Our current capacity is 1000 widgets a month. Max: John, I need you to do better than that. We’ve just committed to deliver 1500 units each to two customers by the end of February. John: Well… our capacity of 1000 per month includes time for scheduled maintenance as well as time for improvement projects that will in

In The Humble Build-Up Chart – Communicating with Stakeholders , I discussed how a build-up chart can be used to show progress and projections – to achieve communication with stakeholders. Today, I’d like to address a couple of ways in which a build-up chart can be misleading. Done-ness? In Why Scrum requires completely “Done” software every Sprint , Christiaan Verwijs digs into what it means to produce a “Done”, useable, and potentially releasable product Increment (as defined by The Scrum Guide™). One way our build-up chart can mislead us is if what the build-up chart is tracking as “done” is not “Done”, usable, and potentially releasable. Looking at our sample build-up chart below, note the solid blue line that indicates progress-to-date. If the work that has been tracked here is not completely “done” and in a releasable state, then there is likely hidden work that will delay the actual release. Examples of work that might not be revealed by the build-up chart: Manual regression te

Many of us work in environments where the question “when will you be done with X?” matters. Some of the examples I have seen recently are: The business team wants a certain set of functional enhancements as well as performance & scalability improvements. Can we get both done? Will one need to take a back seat to the other? A customer has a “deployment window” that we want to hit with a certain set of functionality. Do we look like we will make it? If not, what adjustments might we make? A customer wants an early warning if the cost of a project is likely to go over a certain amount. One of the tools we have in our repertoire for answering these kinds of questions is the humble build-up chart. In its simplest form, the build-up chart looks something like this: The target scope (of which we are asking the question: when will it be done?) is represented by a target line, in this case, just below 150 points. The progress so far, and anticipated progress, are represented by a line repre

“No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.” – attributed to Heraclitus What happens when we come back to Agile training? As part of our commitment to being an Agile organization and supporting the growth of our people, in 2016 we held 2-day training events for our team members. The training was CSM ( Certified ScrumMaster ) specific – but we felt it would be valuable for everyone, not just those people whose role included Scrum Master. We achieved almost 100% – as in, almost everyone in the company attended, and almost all of those took and passed the CSM. More importantly, with senior management and business leaders attending alongside engineers, the training created conversations and shared understanding that helped us make significant strides in our ability to succeed and deliver value using agile mindset and principles. Two years later, a lot has changed. Our business has shifted. One of our product lines has enough teams on