Focus On What To Leave Out

Last Updated on Tuesday, 21 January 2014 10:02 Written by Rick Austin Tuesday, 31 July 2012 05:30

As an avid photographer I’ve learned a lesson that sometimes a well composed photo depends more on what is left out of the photo. More is not always better and can sometimes ruin what could have been a good composition.

As an example, this photo is as was taken. I realized there were distracting elements (the house, dead tree) and the composition was just not one that created a compelling photo. The highlighted section is where the final crop was made. I left out more than I left in and I believe the end result was a more pleasing composition. You can see the final image here but that is not relevant to this article.

I believe this concept can be applied to software development. We talk about determining the minimal marketable features, those that must exist for a product to meet the user’s needs. This requires us to be very intentional about what we leave out. The Standish Group notes that 45% of software features are never used and only 20% are always or often used. Those are astounding figures that illustrates the tremendous potential for wasted effort and time in a software development project. We must become better at composing a frame that contains only those features required to satisfy our customers and leave everything else out of the frame.

These unused features come from many sources: product owners, customers, and even the software development team. We get caught in the trap that we need to capture everything, provide all possible features, or convince ourselves that while we are working in some part of the code there is little cost in adding just a few more capabilities. As well meaning as we believe we are, these non-necessary features exacts an ongoing cost. Costs from unused features that must continue to be tested, increased difficulties for adding new features, and increased technical debt.

Recently I worked with a client that was debating on whether or not to add a capability to allow multiple items to be selected and then updated with the same information or just provide the capability one item at a time. From the customer’s perspective the real requirement was to be able to select an item and update. Doing so for multiple items would be a nice to have but _not_ necessary. After much debate the product owner made the the decision to not add the multiple select capability. It was not a minimal marketable feature and should be left out. It was a beautiful thing.

Always be mindful of what is necessary and be very aware of the true cost of adding capabilities that appear simple to deliver but do not contribute to the final composition. Be ruthless in cropping out unnecessary elements and focus on those items that create a great composition.

Learn More

What is a Qualified User Story?

Last Updated on Thursday, 2 August 2012 10:18 Written by Derek Huether Thursday, 26 July 2012 11:55

User StoryRegardless of the client I work with, the teams seem to initially struggle with understanding how big (or small) a User Story is, relative to Epics, Features, and Tasks.  It doesn’t help when they first ask how big user stories are and my first response is “it depends“.

It’s not uncommon to find team members asking if they can call smaller stories a minor or sub-story or a larger story a major story.  But then they get distracted by colors of index cards or some ancillary attribute.

The Distinction

Those who identify what the business wants (you may call him or her a Product Owner) take a stab at breaking down stuff to manageable chunks.  You can call those chucks an A/B-level requirement, epic, theme, feature, or spike. It doesn’t matter what you call it.  But when the team estimates that stuff, it is still sometimes (more often than not) too big to fit into a sprint or iteration or just isn’t ready to be worked.

We need to label [this] to set it appart as work that will be committed to next.  Either it will be scheduled in an upcoming sprint or it will be pulled to the next step on a Kanban.  To be clear, I’m not saying the team should start working on [this], merely because they think it is small enough to be completed within a predetermined cycle.  Until your team has sufficiently defined and mapped requirements, developed acceptance criteria, and removed all known blocking dependencies, it is still not a Qualified User Story.

Though I still use the term User Story as that placeholder for conversations, I believe the Qualified User Story more appropriately identifies a placeholder for conversations that meets a definition of ready and allows the team to commit to complete something within an estimated period of time.

Image Source: Pictofigo


Learn More

That’s Not Agile!?

Last Updated on Monday, 3 December 2012 05:55 Written by Mike Cottmeyer Tuesday, 24 July 2012 05:00

Agile at the Enterprise Level is not about the two-week inspect and adapt cycle… it’s about small batches and flow.

You may have noticed that LeadingAgile is growing… and we are growing fast. Why? A large part of our approach to selling involves deeply understanding what our customers need and helping them craft solutions that meet them where they are. Some of the companies we work with are inventing new markets and creating emergent new products. Many of them though are desperately trying to figure out a way to deliver against defined commitments to existing customers. They desperately need some ability to do what they say they are going to do.

Businesses need to be predictable… they need to be able to regularly and reliably make and meet commitments. If you talk to these companies, many of them will tell you that they need to be predictable 12 to 18 months out. Personally… in most markets… I don’t think that is a reasonable expectation. For one… it is tough to really know how you are going to build the system that far out, and two… it is VERY unlikely that what a company thinks it needs 18 months from now is actually what it is going to need in 18 months. Needs are changing and markets are changing too fast.

For most companies we work with, the sweet spot is 3 to 6 months. If the product development organization can reasonably hit a 3 month commitment and have at least a high level idea what things will look like 6 months out… that is something we can work with. Even if a team is sprinting two weeks at a time… if they don’t know where they are headed 3 to 6 months into the future… chances are the organization is thrashing and the team will get frustrated. Even agile teams don’t like getting yanked around.

Getting Predictable

So… how do we get predictable 3 to 6 months out? First of all… let’s apply a principle that we know from team-level Scrum. For a team to make and meet a sprint commitment, the team must have some idea of what it will take to deliver the stories. If there is no acceptance criteria… if the stories are too big… if the team has no idea how to approach the work… we pull out one or more spikes to go figure that stuff out. A spike is simply a user story the product owner includes to help the team do the discovery and mitigate implementation risk and uncertainty.

The lesson here is that we can’t commit… even at the sprint level… to things that we don’t understand. There needs to be some prep work… in the case of a single user story… for a single team… for a single sprint… that is a spike. If we extend this metaphor up to the release level, that means that we shouldn’t commit to a release when we don’t have any idea how we are going to deliver that release. For a team to have a stable release plan… they need to know the Epic/Feature/User Story decomposition AND they need to have most of the release level spikes completed.

Release Spikes

What is a release level spike you ask? It is a slice of the product we build during the current release to mitigate risk and uncertainty in an upcoming release. We build the minimum set of user stories we can possibly build to understand the problem, prove the architecture, and define the backlog… so that when we exit release planning… we have not committed to work that isn’ well enough understood. It’s the same thinking we use at the sprint level, just applied one level up at the release level. Don’t commit to what you don’t understand.

So here is the rub… that means at any given time I need to have a well articulated backlog three months out… and a pretty good idea of what the backlog looks like three months after that. I usually refer to this as a three-month rolling wave plan. When I talk to folks about planning a well groomed backlog 3 to 6 months out… to many, that starts to feel like Big Up Front Planning… frankly it starts to feel like Waterfall. So… how do we plan forward… how do we mitigate risk… how to we get predictable without creating a big Waterfall Gantt chart?

3 Month Backlog?

The trick to establishing a rock solid agile release cadence and creating an organization that is able to make and meet commitments 3 to 6 months out… while staying agile… is all in how you write your requirements. It’s in how you define your projects. It’s how you schedule work in your organization. Frankly though… it’s not at the team level… it’s at the program and portfolio level.  Enterprise agility is about loose coupling between projects, and Epics, and Features… it’s about loose coupling at all levels of the organization. Remember that line in the Manifesto that says ‘we value responding to change over following a plan’?

That line doesn’t mean we don’t plan… it just means that we create plans that are resilient to change.

Small Batches and Flow

If at every level of the organization we focus on smaller batches… we focus on flow… we focus on limiting work in process… we focus on getting work done… we always maintain the ability to inspect and adapt. We always have the ability to change our mind as we learn new things about our product. We always have the ability to respond to change as we learn new things about our customers. Planning is how we mitigate risk… planning is how we define what we are going to do. We don’t throw up our hands and give up on planning… we look ahead and create plans that are resilient to change.

I’ll tell you… if you are having problems selling agile to your leadership team… it’s probably because the messaging you are using doesn’t resonate with them. Again… most of the folks that use our services care deeply about predictability. Do what you say you are going to do when you say you are going to do it. When things change, our plans will be resilient, and we’ll communicate and manage expectations accordingly… but leading with a message that says we can’t make and meet commitments is a non-starter. 3 to 6 months of well groomed back log helps that.

Enterprise Agile is more than Sprints

The point I’m really trying to get across here is that for most enterprises, agile isn’t about the two week inspect and adapt cycle… it’s more about smaller batches and flow at the program and portfolio level. It’s more about limiting work in process of major initiatives. It’s more about establishing a predictable and reliable delivery cadence that gives executives options for managing their business. Being agile isn’t about making it up as you go and not writing anything down… it’s about reliably and consistently putting products into market that your customers will use.

Learn More

Minimally Marketable Features and Flow

Last Updated on Thursday, 2 August 2012 10:19 Written by Peter Callies Friday, 20 July 2012 10:50

In the context of software development, flow is the movement of new features from idea to use by a customer. The shorter the amount of time between idea and use (i.e. the faster the flow), the faster value and revenue are realized.

Features are decomposed into stories. Typically, these stories are ordered from most important to least important.

As I was recently monitoring the flow of features through a development system, I was observing many of them sitting in the Develop phase for a long time. When I investigated, I discovered that many of the features had been completed to a certain depth of functionality and then teams had moved on to other features.  If time allowed, the team would come back and complete more of the stories that defined deeper functionality of the feature.

Essentially, the teams had been using the stories within a feature as a negotiating point with product owners.  Initially, I thought this seemed like a perfectly acceptable practice, but there are a few problems with it:

  1. The teams weren’t being transparent and predictable about that they’re going to deliver. They said they were going to deliver a feature, but the definition of the feature was ambiguous.
  2. It’s difficult for the business to communicate externally what the content of a release is. The name of a feature usually is based on all the stories that define it, including those that are negotiable. When teams don’t complete all the stories in a feature, that leaves the business to try to determine what a feature really does and what it doesn’t do, communicate that to customer, and to plan the uncompleted stories into a future release.
  3. Teams end up with a large amount of work in process (WIP). When teams have a large number of features all being worked at the same time, it is difficult to know which is the most important and teams have to do inefficient context switching to float back and forth between them.
  4. Features don’t move into and out of the Develop phase in a smooth flow. Teams end up moving large batches of work all at once. This makes the teams less flexible and less transparent. Additionally, if they are able to move items through the Develop phase in a faster, more predictable, more transparent manner, they might ultimately be able to release more frequently which would deliver value to customers more frequently.

A better alternative would be to define features in a truly minimally marketable manner. Don’t include the negotiable aspects of a feature in its definition. Use those aspects to define a different, smaller feature.

Learn More

Agile at the Speed of Trust – Relationship Trust

Last Updated on Thursday, 2 August 2012 10:20 Written by Peter Callies Friday, 13 July 2012 06:51

Once Self Trust is established, the second wave of trust, Relationship Trust, can be tackled.  The Speed of Trust defines 13 behaviors as being critical to establishing trust in a relationship.  Although the book focuses on interpersonal trust, these behaviors also are critical for groups of people to establish trust within an organization.  Here are some of these behaviors that first made me aware of the strong link between trust and Agile.

Create Transparency

Every time I review the section named “Create Transparency” in The Speed of Trust, I’m reminded that transparency goes up and down.  Not only do teams need to be transparent with the work they’re doing, “product owners” (used generally, not in specific scrum terms) need to be transparent.  When a product owner is transparent about business challenges, risks, and opportunities with a team, the team becomes much more trusting in the product owner.  The team believes the product owner has considered many options and has reasons for the path chosen.  Additionally, it allows the team to understand the constraints the product owner is under.

Transparency is ” about being real and genuine and telling the truth in a way people can verify.”

The counterfeit is illusion: pretending, seeming rather than being, making things appear different than they really are.

Deliver Results

Mike recently gave a presentation that included a slide stating, “Introducing agile is never the point of introducing agile; better business outcomes are the point of introducing agile.”  This is one of those “well, duh” statements that is easy to overlook when we get too focused on the mechanics of agility, but delivering business results is what it’s all about.

Delivering results is the easiest way to build credibility.  In an Agile team setting, we break small batches of work up into small, meaningful, achievable pieces.  We define the success (i.e. results) for each piece up front in the form of acceptance criteria so everyone knows what result we’re trying to achieve.  Then, we operate in short iterations, rapidly delivering results that are confirmed by the product owner.  We build credibility and trust that allows us to accelerate our delivery of results.  It’s a wonderful cycle!

When we scale Agile, we do similar things.  We are constantly grooming our program or enterprise backlog, ensuring that we’re working on items that will deliver the most meaningful results for our company.

The counterfeit is delivering activities instead of results.  Just because you’re busy doesn’t mean you’re delivering meaningful value.

Get Better

In Agile, we routinely inspect and adapt at levels ranging from pair programming to release retrospectives.  If we’re doing it right, we’re not only identifying things we can do differently, we’re actually implementing actions to effect change and improvement.  We have many feedback loops built into the way we work.

The Speed of Trust states, “When people see you as a learning, growing, renewing person — or your organization as a learning, growing, renewing organization — they develop confidence in your ability to succeed in a rapidly changing environment, enabling you to build high-trust relationships and move with incredible speed.”  One of the keys in that statement is people being able to see that you’re getting better.  It’s not enough to do it in a closed room.  It needs to be paired with “Create Transparency” to have maximum impact.

The book lists two counterfeits to Get Better:

  1. The person who is always learning, but never producing (i.e. the eternal student).
  2. Trying to force-fit everything into whatever you’re good at (i.e. thinking everything is a nail because you have a good hammer).

Confront Reality

In Agile software development, we focus on delivering working tested code in very short time frames.  We demonstrate that it is working and tested or we don’t call it done.  We continually confront the reality of code that isn’t working or isn’t meeting expectations.

If we’re doing proper retrospectives, we’re confronting the reality of how we work together most effectively.  We “share the bad news as well as the good, name the ‘elephant in the room’, address the ‘sacred cows’, and discuss the ‘undiscussables’.”

The Speed of Trust notes that confronting reality leads to open interaction and fast achievement.  Think about a project that has gotten off track.  Think about how often you’ve attended standing status meetings for that project where real issues are avoided and the project continues to founder.  There’s nothing fast about achieving meaningful results in that situation.

The counterfeit of confronting reality is “focusing on busywork while skirting the real issues.”

Practice Accountability

The book notes that it is equally important to hold yourself accountable and to hold others accountable.  If we define personal and group expectations, we need to live up to them.  When we don’t live up to them, we need to hold ourselves and our co-workers accountable.

In Scrum, we have an opportunity to do this by reviewing the results of every sprint.  If a story didn’t get done, it’s the team’s chance to say, “That story didn’t get done because we didn’t do this, that, or the other thing.”  It’s also a chance for an individual to stand forth and say, “I let the team down.  I committed to getting that done and I didn’t.”

In a daily standup, the opportunity exists for team members to hold each other accountable.  If a person said they were going to get something done during the last standup and it’s not done, other people on the team should “call the person out,” inquiring about why the thing isn’t done.  After all, the individual’s actions lead to the team’s success or failure.

Accountability is tough!  It goes against many of the examples we see in society today.  Most people look for excuses and scapegoats.  As the book says, most people play the victim, blaming the outcome of their actions (or inaction) on anything or anyone but themselves.

It takes courage to be transparently accountable and it takes fortitude to hold others accountable.

Keep Commitments

To keep commitments, you first need to make commitments.  Say what you’re going to do and then do it.  If you’re using Scrum, you do this every sprint.  In a scaled agile environment, you might do this every release.

The Speed of Trust cites two studies, one showing “keeping promises” as the number one behavior in creating an ethical culture, the other showing “not doing what they say” as the number one trust breaker.  Clearly, keeping commitments is critical to trust.

The counterfeit of keeping commitments is making commitments or promises that are so vague that you can’t be pinned down.

Extend Trust

Extend Trust is the capstone of all the other behaviors.  There are a couple of powerful sentences in The Speed of Trust that really represent Agile’s principles of giving people what they need to be successful and allowing them to self-organize (within reason, which is a much different topic that I am trying to cover here):

  • “Extend Trust is based on the principles of empowerment, reciprocity, and a fundamental belief that most people are capable of being trusted, want to be trusted, and will run with trust when it is extended to them.”
  • “When [trust is extended], people don’t need to be managed or supervised; they manage themselves.”

This somewhat lengthy post just touches the tip of the iceberg.  As I was writing the post, I realized I could have written an individual post on each one of these behaviors, not to mention the six other behaviors I didn’t touch on.  If the synergy between Agile and any of these behaviors resonated with you, I really encourage you to read the book.

Learn More