Lean/Agile Values

After many years, I have finally found a set of values that effectively and pithily encapsulate my way of working in technology-heavy environments. After many years, I have finally found a set of values that effectively and pithily encapsulate my way of working in technology-heavy environments. In a previous post (still far and away the most popular on the site), I gave my opinion on how the Agile Manifesto should be read. In it, I very much relegated the most quoted part — the four X over Y comparisons — to the level of status report, to be read as thus far, here’s what seems to help, rather than a true statement of values. Certainly I think that those comparisons are a good, pragmatic set of heuristics, and are excellent to guide behaviour in the face of uncertainty. Too many people though seem to use them dogmatically, and fail to see the line following, that clarifies that it’s a balance, and the lesser valued end of the comparisons are also useful. Result: much disposal of babies along with bathwater. And perhaps a major factor in my scepticism is that it really is a highly context sensitive status report. And I’m looking for a higher set of values that are more perennial, and speak to a systems level perspective. That really summarises what I’m about as a delivery leader, and where I seek to turn the volume up for customers as a consultant and coach. Over the years, I’ve seen a few other[/su_tooltip] value statements that are really good and I’ve learned a lot from, but none of them are...

Lean/Agile Values

After many years, I have finally found a set of values that effectively and pithily encapsulate my way of working in technology-heavy environments. In a previous post (still far and away the most popular on the site), I gave my opinion on how the Agile Manifesto should be read. In it, I very much relegated the most quoted part — the four X over Y comparisons — to the level of status report, to be read as thus far, here’s what seems to help, rather than a true statement of values. Certainly I think that those comparisons are a good, pragmatic set of heuristics, and are excellent to guide behaviour in the face of uncertainty. Too many people though seem to use them dogmatically, and fail to see the line following, that clarifies that it’s a balance, and the lesser valued end of the comparisons are also useful. Result: much disposal of babies along with bathwater. And perhaps a major factor in my scepticism is that it really is a highly context sensitive status report. And I’m looking for a higher set of values that are more perennial, and speak to a systems level perspective. That really summarises what I’m about as a delivery leader, and where I seek to turn the volume up for customers as a consultant and coach. Over the years, I’ve seen a few other[/su_tooltip] value statements that are really good and I’ve learned a lot from, but none of them are comprehensive, or pithy, enough. And they all have the off-putting dogmatism thing. I think I may have found what I’m looking for. In...

Free Workshop: SAFe City Simulation in Stockholm

I’m delighted to announce that we (AvegaGroup) will be running Mark Richards’ awesome SAFe City Simulation as a free workshop in Stockholm on 27th August. For Free När:                         2015-08-27  17:00-2x Plats:                       Elevatelokalen, 3:e plan, Avega Stockholm Format:                    Hands On Simulation Målgrupp:                Productledning, Program och Portfolio ledare Publik:                   Öppet för alla intresserade men bara 20 platser Förtäring:                 Ja A consistent problem in product development in large organisations is prioritising multiple stakeholders’ needs within a constrained capacity to produce the best roadmap. Too often this is achieved by loudest voice/biggest boss first scheduling. This workshop outlines a different method, using Cost of Delay economics to produce a rational sequencing that forms the basis of a roadmap. Attendees will participate in a simulation that prioritises high level epics, breaks them down into features which are then prioritised and planned in a product roadmap. For an introduction to the method, please see The Principles of Product Development Flow (Reinertsen) Black Swan Farming (Maersk Line Experience Report) Weighted Shortest Job First (WSJF) Abstract (Scaled Agile Framework) Välkomna Elevate genom Martin Burns Powered by...
The Rock Paper Scissors Lizard Spock of Teams

The Rock Paper Scissors Lizard Spock of Teams

Once a software delivery system grows beyond about 20 people, program-level structure emerges and requires management for system-level optimisation for collaboration and trust. Search Search for: TagsA3 ACE AgileAtLarge anti-patterns avega capacity change coaching conference continuous delivery continuous improvement culture cynefin DevOps dreyfus empathy flow gemba go and see hansei high-performing impediments job kaizen lascot14 leadership learning management manifesto meta norway organisation poland Reinertsen SAFe scrum speaking sweden team training transformation values visual management waste WiP As a team grows, the number of communication channels within the team grows exponentially, according to the formula: Channels of Communication = (n*(n-1))/2 This is why Rock Paper Scissors is a pretty dull game that becomes vastly more interesting when you add just two more possibilities. You go from 3 relationships (each member of the set beats one and only one other and is beaten by one) to 10, in which each member beats and is beaten by two other members. Let my good friend, Dr Sheldon Cooper, explain: Definitive Rules Scissors cut Paper Paper covers Rock Rock crushes Lizard Lizard poisons Spock Spock smashes Scissors Scissors decapitate Lizard Lizard eats Paper Paper disproves Spock Spock vaporizes Rock And as it always has: Rock crushes Scissors Given that software teams working on anything but the simplest of systems nearly always have to stay in pretty close co-ordination to be effective, it’s unavoidable that as a team grows, teammembers spend a greater proportion of their time communicating, and a lesser proportion thinking creatively about how to solve business problems with code. While it’s true that the definition of organisations is that humans working together...

The Two Agiles


Warning: Invalid argument supplied for foreach() in /home/amplifiers/amplifiers.se/wp-content/themes/Divi/functions.php on line 7692
There are two distinct benefits of Agility. Assuming either is universal and exclusive causes unnecessary conflict: Agilists need to appreciate and value the diversity and find context-specific balance. We are uncovering better ways of developing software says the manifesto, while fudging the question about what ‘better’ means. Exactly what you’d expect in a superficial peace treaty. But by ducking the major source of conflict and focusing on the easy stuff, it pretty much guarantees further conflict. Since its very inception, the Agile community has been riven by conflict. The very manifesto event was essentially a peace treaty between different groups and individuals who had some very different ideas about what they were writing. Like most intractable conflicts, these are not driven by conflicting answers to a question, but different views of what the question is. In Cynefin terms, we are in Disorder, and the clearest conflict is between two Cynefin domains, each of which addresses a different business question. It’s no surprise that the conflict is illustrated through the first two Agile Principles. Early and continuous delivery of valuable software This school of thinking emphasises minimising Cost of Delay, and says that if you start delivering value earlier, and incrementally, you will deliver a lot more total value than if you wait until it’s all delivered. You can find this all over flow-based approaches, in Theory of Constraints, DevOps and Kanban. Move the value through the system faster. Smaller batches, moved more frequently. Deploy often, minimising the time from developer desktop to production. Often in this school, we work to identify reducible uncertainty and variation. Elephant Carpaccio is a...