Integral Agile Journal
Posted on: June 7th, 2018
We’ve all had the experience of being in a group where everything is flowing really well, people are aligned, and everyone’s energy is high. Then one person says or does something that seems to pop the bubble, and the flow of good ideas stops. The typical response in these situations is a kind of uncomfortable silence followed by a disinterested push to get back to the topic at hand. Everyone in the room can sense that something is different but few are aware of what happened, and almost nobody is aware of the actual phenomenon at work.
Posted on: May 2nd, 2017
Why do we do anything at all? What motivates us to get up in the morning, and come to work? When you think about it, the morning rituals we go through to arrive at a set location at a particular time, with a bunch of other people who feel just like we do (in their own way) in order to do a series of activities most of us could frankly care less about if we weren’t being paid to, does not lend itself to model that results in a happy, engaged workforce where the focus is on the Team more than the Individual.
Posted on: March 6th, 2017
Anyone who has created a truly Agile result at any level of any organization can speak to the elegance of how everything fits together, how information flows, and the way in which actions taken at the smallest task level both impact and are directly informed by everything taking place at larger or higher levels. The most seasoned Agile practitioners will (if they’re being honest) tell you that these “uber” results are very few and far between, but when they happen, there is an elation that seems to roll through everyone involved, that is difficult to express or quantify.
Posted on: March 5th, 2017
The most accurate way to measure the success of any Agile team, is by validating the actual Business Value delivered with the delivery of working software, and measuring performance based on your Key Performance Metrics to see whether your product is performing to expectations. This is something we call a Long , or Customer Feedback Loop.
Posted on: January 5th, 2017
The business value of a product is defined by the product owner as part of the process of developing the product vision and initial product roadmap.
Business value is very specific to the type of product being developed but examples may include:
Posted on: December 10th, 2016
This next series of posts will talk about what we mean by “Value,” and how we know whether we are delivering it.
If you ask anyone you work with if they think they are delivering value to the business or to their product, they will most likely say “yes” (if they say “no” you probably have an interesting conversation ahead, stick with it!). If you were to ask them what they thought delivering value meant, they would probably tell you about the many activities they perform throughout the day, but how do we know whether they are valuable?
Posted on: October 9th, 2016
Monty Python gives so much we can use in our transformation strategy!
Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not some farcical aquatic ceremony! – Servant Leaders
You think you’ve had a hard time? I’ve been chained to the wall for five years, and they only hung me the right way up yesterday! - Retrospectives
Posted on: September 10th, 2016
“Our team is going Agile,” “where are you on your Agile journey,” and “what is the most important Agile metric,” might be some things you’ve heard or thought about lately. The answers to these and the many other questions or descriptions I’ve heard in my adventures across the enterprise have been at times confusing, at times contradictory, and sometimes even quite amusing.
Posted on: August 8th, 2016
The goal of the Definition of DONE agreement is many fold, and it exists not only to create a standard by which teams can operate so that they can feel confident that when someone says, “I’m DONE!” they know precisely what that means, but also to ensure that all involved stakeholders understand when, why, and how to engage with a given team, and what they can expect from their contributions.
Posted on: July 8th, 2016
In order for the team to review the work done in the previous Sprint/Iteration, a Sprint/Iteration Review is held. Note that this is not the occasion for the team to present the work to the Product Owner.
This Review meeting should be scheduled for the first available time slot after the end of the previous Sprint/Iteration and last 30 minutes for a single team, or up to 30 minutes per team for multiple teams in a single program. It is common for teams to schedule the first 30 minutes of their Sprint Planning meeting to review the previous Sprint.