Retrospective: Setting Expectations

March 12, 2013 by Leave a Comment

Use this retrospective exercise when you want to help a team set expectations, practice empathy and generate working agreements that move the team forward.

Expectations

Setup

For this retrospective you’ll need sharpies, post-it notes and a wall, window or whiteboard on which they can be stuck.

Setting Expectations

At the heart of this retrospective exercise is defining expectations for yourself and your teammates. Start by explaining that on most teams, there are varying expectations. Some people expect different things from different people and from different roles. The exercise as described below is focused on a Scrum team, but the questions could be adapted for any team.

Ask the team to describe their expectations of the Scrum Master

  1. Be clear that these are not personal expectations of the particular team member who is currently in that role, but the expectations you would have of any Scrum Master on your team.
  2. Ask the participants to write down 3 to 5 ideas, each on separate notes, that describe what they expect of the Scrum Master. (Adjust the minimums and maximums for your group)
  3. Have the participants put their stickies on the wall or board in one big group

Repeat this process for the Product Owner role and the Development Team

Group Ideas

Now that some ideas have been generated, move the participants towards gaining insight by grouping them in like categories.
  1. Using Mute Mapping, have the participants group the stickies, while keeping them in their Scrum Master, Product Owner and Development Team boxes.
  2. With the help of the participants, name each grouping.

Generate Insights, Investigate Assumptions and Practice Empathy

Move through each role and explore the ideas generated by the team. Share that you hope to create a working agreement after discussing these ideas. Some questions might include:
  • Ask someone who is in a different role what might make it difficult for the Scrum Master (or Product Owner or Development Team) to live up to the expectations on the board.
  • Ask if anyone might change their behavior based on what they now know other people expect of them
  • Ask the participants if the expectations listed for a role seem too easy, too hard or just right
  • Ask if anyone is surprised by anything or if there is an expectation that they think is unrealistic
  • Ask if anyone feels strongly about a certain expectation

Create a Working Agreement

Now that the team has a more clear picture of expectations and they have thought about the difficulties of other people in other roles, work with the team to generate a working agreement. Some possibilities include:
  • No Excuses – We refuse to accept excuses when things go wrong
  • Be Brave – We will declare our intent when communicating by declaring “I’m going to be brave…”
  • Core Hours – Everyone will be physically present in the team room for at least 6 hours between 9AM and 5PM
 
Filed Under: Agile, Scrum

Answering “Are We on Track?” With a Burndown Chart

January 10, 2013 by Leave a Comment
Recently, on twitter, Tobias Mayer asked if anyone was still using burndown charts as described in the original scrum literature:
I personally enjoy using burndown charts and like exploring the different stories they can tell given the multitude of ways you can design them. I am currently working with a team that is using a commitment driven approach to planning who also uses a burndown chart of remaining task hours. I replied to Tobias with:
 

This seemed to spark a big discussion with a lot of people chiming in with their opinions and experiences. The discussion followed the usual Agile Twitter Debate Formula™ involving charges of not being agile, assuming mutual exclusivity with other practices, general misinterpretations of various points concluding with the usual series of just-do-what-you-want-and-lets-stop-arguing-about-this tweets.

Since twitter proves time and again to be a terrible place to expand on things, I figured it was worth explaining my original tweet in a little more detail here.

Value vs. Work

One of the first issues that came up in this discussion was that the sum of tasks for a particular user story don’t necessarily add up to any real meaningful value, so since tasks themselves don’t represent value, we shouldn’t be tracking them.
 

So, fair enough, tasks don’t represent value so let’s track story points instead. While I think that a burndown chart of story points can tell a story, I like to tell lots of stories so I usually use this in conjunction with other artifacts. I’ve also seen plenty of teams who have a burndown chart of story points that goes sideways for three days and then everyone realizes that they’re not going to get everything done by the end of the sprint. Whoops!

Do we have enough gas to get there?

Imagine that you and some friends are planning a road trip to an outdoor music festival. You all hop in the car and get going. Being a beautiful day, you suggest taking the scenic route and stopping on the way to take a group photo. As you’re driving, the GPS on your dashboard is squawking commands and you’re fairly confident that you’re heading in the right direction. After a few hours someone in the backseat asks “Hey, do we need to stop and get gas?”

At that moment you look down and realize that you’ve got a quarter tank left, with some quick math and a glance at the GPS you determine that you do not have quite enough gas to make it to the music festival and having passed the last gas station before your destination you can’t stop and get more. Your only choice is to break the bad news to your friends and negotiate taking the group photo on the way back from the music festival.

Are We on Track?

I view a burndown chart of hours remaining as a gas gauge. It doesn’t tell us anything about if we’re going in the right direction or if we’ll ultimately get to our destination, but it can be a useful way of making sure that you’ve got what it takes to make it there.

Most importantly, tracking hours remaining isn’t about tracking hours, or management making sure people are busy or any of the other treacherous things suggested during this twitter discussion. For me, tracking hours remaining is about all of the questions and things you uncover as a result of asking “Are we on track?” and the answer that follows.

Filed Under: Agile Tagged With: , , ,

Building a Self-Sustaining Ecosystem through Agile Coaching

September 19, 2012 by Leave a Comment

I was recently fortunate enough to attend the Culture Conference in both Philadelphia and Boston. Even more so, I was able to enjoy the company, conversation and new relationships as a member of the party bus that traveled between the two conferences.

As we drove over the George Washington Bridge, I was having a conversation with Dan Mezick about the role of Agile Coaching in ethical billing and creating learning organizations. I’m a firm believer in the idea that as Agile Coaches, we should strive to foster an environment of organic learning and prescribe specific solutions only when absolutely necessary.

As Dan and I were talking, it occurred to me that an Agile Coach has a similar role to a planted aquarium hobbyist. One can think of a typical organization as a poorly maintained aquarium. There are frequent algae blooms, some of the fish have died, and the plants have discolored leaves and weak roots.

If handed over to an accomplished aquarium hobbyist, they would start by measuring chemical levels in the water to asses the environment. With continuous checking, day by day and week by week, our hobbyist would slowly adjust and improve the balance in the tank. They might add or remove certain plants, invertebrates or fish. Over time, as a result of their actions, the aquarium would achieve a state of balance and the inhabitants would enjoy a harmonious co-existence.

Similarly, an Agile Coach might enter a dysfunctional organization and begin measuring and improving the organizational environment. Again, like the hobbyist, they would help the organization adjust its culture such that it too could become a thriving, self-sustaining ecosystem where the inhabitants live in balance and harmony.

This isn’t to say that once this state is achieved, the coaches work is finished. Just as the hobbyist needs to maintain the aquarium by adding and removing plants or fish, an organization committed to continuous improvement needs the help of the coach to keep learning and improving.

As Agile Coaches, I hope that we strive to build self-sustaining learning organizations rather than insert ourselves as linchpins in the ecosystem. I strive for the self-awareness to ask of myself “Am I just adding chemicals or am I helping the roots grow deeper and fish prosper?”

Filed Under: Agile Tagged With: , ,

Agile Principles: Progress Requires Working Software

August 7, 2012 by Leave a Comment
Working software is the primary measure of progress.
- Principles behind the Agile Manifesto

 

Pixel perfect design mockups, UML diagrams, detailed user stories, automated tests, thousands of lines of code and hours of discussions. These are just a few examples of the endless amount of stuff we can spend time creating, tweaking, editing, testing and reviewing. However, nothing shows progress quite like working software.

 

So what is working software? That’s going to be different for every team, but a good starting point might be “software that is deployed to and delivers value to the customer”. This means it might be ugly, imperfect, not-absolutely-intuitive and likely somewhat incorrect and that’s okay; you’re one step closer to making it meaningfully better.

 

This post is part of my series on the principles behind the agile manifesto. You can find the others here:
Filed Under: Agile Tagged With: ,

Jenkins CI Build Monitor

July 6, 2012 by Leave a Comment
Jenkins CI is a popular open source continuous integration server. I encourage teams to use continuous integration, however many teams setup the server, configure the automated e-mail blasts and think that’s all there is to it. Many teams don’t make the results of their builds part of an informative workspace. The team I’m currently working with fell into this trap and started having issues with failing builds going unnoticed. I looked around for some plugins and projects to help with this goal, but nothing quite met our needs.

Introducing Jenkins Radiator

I built Jenkins Radiator with a few things in mind:
  • We only care about passing jobs when all the jobs are passing
  • If a job is failing, it should be very obvious
  • If a job was failing and is being built again, we want to know
  • You shouldn’t be able to hide a job or otherwise ignore it, if it’s not important, get it off CI
  • A quick glance at the radiator from across the room should let you know if the build is green or not
Start Using Jenkins Radiator

Screenshots

Jenkins Radiator Failing Jobs

Jenkins Radiator Passing Jobs

Filed Under: Agile, Testing Tagged With: , ,

Add Some Fun to Your Scrum Board

May 3, 2012 by Leave a Comment

Physical Boards Please

I recently started working with a team who had been introduced to scrum as part of their organization’s adoption of agile. Their only experience with scrum was through the lens of a popular agile project management tool that rhymes with alley, as in “After using this software I want to vomit in an alley”. When they had the chance to use a physical board, they jumped on it. I setup a very simple scrum board on the outside of a cubicle near the team. We used index cards and colored pushpins, the normal stuff. After a few days, the team was loving it. They enjoyed moving tasks around, pushing green pins into completed cards and keeping an eye on which tasks were in-progress.

Accidental WIP

That’s when I noticed something strange. When I setup the board, out of sheer laziness on my part (I kept pricking my finger reaching into the bag of push pins) I only provided them with three yellow pins and three red pins, one for each member of the team. In doing so, I had created this artificial WIP limit. The team treated the yellow and red pins as their “own” as in, “this is my yellow pin”. At first I just though this was a neat little side effect of the circumstances, but then I realized I could capitalize on the situation by adding some personality to the board.

The last time you played Monopoly™, the board game, did anyone make a big deal about choosing their token? I bet they did, that seems to happen every time I play. There’s always the guy who has to be the race car or the top hat or whatever. People are serious about their monopoly pieces.

So back to the scrum board. I wondered to myself, could I somehow affix monopoly pieces to these push pins? With a quick trip to eBay for a bag of random monopoly pieces and some super glue, I had the answer. Yes, it can be done.

I presented the idea to the team and let them know that if they wanted to use a special push pin they could, or if they’d like to use a regular one that was fine too. The initial reaction was all smiles, quickly followed by, “I’m gonna go first before anyone else picks the race car!”

Filed Under: Agile, Ideas, Scrum Tagged With: , , , ,

Retrospectives: Best Practices, Common Problems and New Ideas

May 2, 2012 by Leave a Comment

Here are the slides for my presentation at the May 2012 Phoenix Scrum User’s Group meeting. If you attended the meeting and have any further questions, please contact me, clayton@integrumtech.com.

Retrospectives: Best Practices, Common Problems and New Ideas
Filed Under: Agile, Scrum Tagged With: , , ,

Agile Principles: Tear Down These Cubes

March 5, 2012 by Leave a Comment
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
– Agile Principles

Manager, Tear Down These Walls

If you were tasked with designing a system that made spontaneous collaboration difficult, you couldn’t go wrong with the modern cube farm. Members of a “team” dispersed over an area of the office, isolated in their drab tchotchke ridden cubicles. Instant message, e-mail and chat might be great for passive communication, but when it comes to real collaboration, being physically present is essential.

But We’re Distributed!

Co-located teams are better than distributed teams. However, sometimes we cannot be co-located. That does not mean we resort to passive forms of communication and digital tools to convey our progress and ask questions. Skype is better than a phone call which is better than e-mail. Don’t underestimate your brain’s ability to gather important insight from the facial and body language of the person on the other end of that video chat.

Filed Under: Agile Tagged With: ,

Agile Principles: Self-Organizing Teams are Motivated Teams

February 29, 2012 by Leave a Comment
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
– Agile Principles

Self-Organizing

Allow the people doing the work to self-organize and discover the best implementation they can given what they know right now. Protect them from organizational politics and outside distractions, enable them to focus on the work at hand.

Self-Directing

While we encourage self-organization, we remember the need for direction. While the team does not self-direct, they need a clear vision and an understanding of success in order to attain the autonomy and purpose required to feel motivated.

Filed Under: Agile Tagged With: ,

Agile Principles: Collaborate Everyday

February 28, 2012 by Leave a Comment
Business people and developers must work together daily throughout the project. – Agile Principles

Email is not Enough

Working together involves more than exchanging e-mails about the software. It’s more than passive instant messenger conversations. It’s not reviewing a digital agile tool in isolation. Working together means collaborating, negotiating and exploring the software that is being built.

Too Busy for Success?

If you’re too busy to interact, fairly frequently, on a daily basis with the rest of the team, you’re too busy to enable product success. High performance teams don’t allow their schedules to be overrun by meetings. They don’t let anything get in the way of daily collaboration, negotiating and exploration.

Filed Under: Agile Tagged With: ,
«Older Posts