What is VALUE?

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?

The wisdom of Monty Python

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


The Role of an Agile Coach

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.

What is a Definition of DONE, and why do we need one?

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.


Posted on: June 5th, 2016

At the end of each Sprint/Iteration, a Demo meeting is held where the Team shows what they accomplished during the past 2 weeks. Given that Agile is an empirical process, and the goal of every Sprint is to product Potentially Shippable Software, only work that meets the Definition of DONE is demonstrated at the end of the Sprint. The Demo usually consists of the development team, the Scrum Master, the Product Owner, but is essentially an open meeting, and all stakeholders, leaders, and interested parties are invited and encouraged to join to observe the team’s progress.


Posted on: May 7th, 2016

The purpose of Sprint/Iteration Planning is for a team to identify and commit to the total amount of work they think they can to accomplish within a 2 week period. In order to have a successful Sprint Planning meeting, there needs to be an organized, prioritized backlog with a sufficient amount of stories in a READY state for the team to pick up and complete within the iteration. A typical Sprint Planning meeting proceeds as follows.


Posted on: April 5th, 2016

Many new agile teams attempt to create stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy Small requirement, but it fails at Independent and Valuable (as part of the Bill Wake’s INVEST model).

Typically, large User Stories can be split using several of patterns. Here are two general rules of thumb in determining the right split to make:


Posted on: March 5th, 2016

These next couple of posts will take things down to the most basic of Agile requirements: the User Story. A User Story is a tool used in the Agile development methodology to capture a description of functionality from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a software requirement.

User Story is a brief statement of intent that describes something the system needs to do for the user. We write them to relate business objectives and value:

Empirical Management

Posted on: February 14th, 2016

Aliases: Adaptive Management …

Your company has been using a traditional approach to management of engineering projects. Now, senior management wants to change how they manage and execute projects so that they can better deliver software – faster and cheaper.