Scrumology

Enabling Agility

The Evolution of Done

Mar 11

Posted by David Bland in agile, lean, scrum | View Comments

Many of you are probably familiar with the concept of done as it relates to iterative software development.
definition of done
It comes in many flavors, from working lines of code to acceptance criteria, and can change from tasks to features to releases. While I agree as a community we should continually grow the definition of done, only recently have I heard others, (Eric Ries & Dave McClure) speak to evolving done in a significant manner.

Instead of tread milling on the technical aspects of code coverage, let us challenge ourselves to close the learning loop and measure the customer impact of our code.

Please do not take the previous sentence as a slight against the proponents of clean code. I’m actually commending you, as without your efforts we’d not be in a situation where we could leap forward in this manner.

Let’s face it, the underlying issue here isn’t that our code is buggy, but instead that we have no empirical data to measure our progress.

I am a Developer, it is the Product Owner’s job to prioritize the backlog in terms of customer value. Let him deal with this, I just want to code!

As a community we are quick to blame the Product Owners as the reason no one uses our code, yet we are doing very little to enable their success. Product Owners are typically not a technical bunch, and they may not be aware of the available solutions to gather customer metrics. We all should feel personally responsible for knowing the impact of what we create.

How do I measure the impact of my code on the customer?

It is a great question, and not one I can answer for you. I can, however, provide you with a bit of guidance on how to answer it for yourself.

I recommend having a discussion with the Product Owner on a metric of progress for your work. Do they have even have one? Please do not respond with velocity.

Velocity is to Value as a Speedometer is to Temperature.

You’d be surprised how many highly functioning teams efficiently crank out iteration after iteration with zero bugs, only to have no one use their product. Work with your Product Owner and find a metric that makes sense for your product that can be measured in an empirical manner. It could be click through rates, page views, unique visitors, SEO or a plethora of other values that relate to your product.

Next, be certain to include the metric into your definition of done. Ask the hard questions early on when you are defining the stories. Having these metrics incorporated into your software development process will help close the value gap between your team and the end product.

Finally, once you have a solution in place, do everything in your power to shorten the time it takes to measure the customer impact. If you released code and it took 3 months to learn of about its value, take steps to shorten it 2 months. If it was 2 weeks, find ways to make it 1 week. Ideally you want to cycle through the learning loop quickly and close out your work in progress.

Even if your initial assumptions are wrong, evolving the definition of done to measure customer impact is crucial to your success. Stop blaming the Product Owner, and start learning!

Tags: , , , ,

Everyone Has a Voice in Retrospectives

Mar 1

Posted by David Bland in agile, retrospectives | View Comments

It can be difficult to get team members to be vocal in retrospectives. I’m always wary of the stronger personalities controlling the conversation, and I’ve found that going around the room calling people out by name can have mixed results. After reading a recent article on effective retrospective formats, I decided to write my experience with finding every voice.

Step 1 – Red & Green. Distribute 2 colors of post-its and a sharpie to each team member. Explain how we are going to use the next 10min to write independently. I recommend starting simple with red & green, and also having a legend on the whiteboard to help people remember which is which. You’d be surprised how quickly they forget! Use the green post-its to write down what helped the team during the iteration, and the red post-its for what hindered them.
scrumology retrospective
Step 2 – Every Voice. Go around the room and allocate 3-5min for each team member to stand up and discuss their post-its. Have the team members listen while the post-its are stuck up on the whiteboard 1-by-1. It’ll look a bit unorganized at first, but after the 2nd or 3rd person you should begin to recognize common threads throughout the conversations.
scrumology retrospective
Step 3 – Group Organization. Have the entire team come up to the board and categorize the post-its into themes. This is important because it is a group exercise, rather than having the facilitator do it by himself.
scrumology retrospective
After the team comes to a general consensus, have them sit down and talk about the groupings. It should be easy to visually recognize the trouble areas, as they are most likely in red post-it clusters. I recommend starting the conversation with those and ending with the green collections. Be certain to call out action items as needed throughout the discussion.

Feel free to customize this format as you see fit. You can spice it up with an egg timer to denote the end of the writing exercise, or add new colors for ideas that do not fall into the helped or hindered buckets. Be aware that the less vocal team members may write very little at first.

In the end, it isn’t important that you stick to a script, but instead ensure that each and every voice is heard.

Tags: ,

It’s an Agile Sabotage

Feb 25

Posted by David Bland in agile, enterprise | View Comments

agile sabotage
Agile adoptions in the Enterprise are difficult and complicated, perhaps that is why I often read stories on Top Down vs. Bottom Up techniques. I feel as though we focus too much on these and overlook the Middle, which can lead to disaster.

Middle management is arguably the toughest obstacle in any large scale Agile adoption effort. This is most apparent in situations where they’ve repeatedly fired people below them to make ends meet. An environment like this does not exactly foster job security and yet middle management becomes adept at navigating the murky waters of office politics. Anything new and disruptive in nature such as Agile, is generally not received well.

Top down Agile adoption is the way to go, you must have executive buy-in!

In a top down approach, one would assume that mandates from above would be followed within reason. However those in middle management can seriously hinder an Agile adoption by sheer incompetence or worse, sabotage. Unless your top down approach has eyes from above keeping tabs on things at the day-to-day level, there is a good change middle management will screw it up.

Grass roots Agile is the most rewarding, and you’ll be a beacon of success for the rest of the company!

With grass roots Agile, one would assume that your successes would be recognized by the executives as you deliver value early and often. However more often than not, those success stories are reported up the chain by middle management, not by the worker bees themselves. Middle management can craft the message as they see fit when sitting down to update their superiors. I’ve witnessed people take credit for work they did not even begin to understand and massage the communication to further secure their job. It happens every day.

Middle management can make or break your Agile transformation.

I recommend that anyone stepping into the Enterprise do their homework on middle management. While your Agile efforts may have a three pronged attack on the top, middle and bottom of the organization, I suggest burning significant calories on the middle. Spend one-on-one time with them and try to understand their background by asking them how they achieved their status within the organization. Gather insight into their personality, and their thoughts on new techniques or ideas. When on site during the transformation, make it a point to be involved with their day-to-day activities to address any fears they may have.

In conclusion, don’t get too wrapped up in Top vs Bottom and overlook the Middle. Your Agile transformation may just fail as a result.

Tags: ,