Archive for the 'agile' Category

21
Nov

Announcing: Big Visible Cruise

Over the past couple of days, I’ve been pulling together a simple Information Radiator for CruiseControl.net. The idea behind the project is to use the power of visualizations to provide simple, visible, and informative displays that expose the current-state of your automated continuous integration builds.

I threw this app together very quickly a week or so ago and I’ve been amazed at how addictive it’s become. In our team room, we have a dedicated monitor that is always running the application. The result is that you know exactly where the builds stand as soon as you enter the room.

I initially wanted to put this together as a temporary solution to picking out what items we will use to show our build status. We always bounce back and forth about Nabaztag, orbs, lava lamps, and other physical things to show our build status. It’s usually easier to find an extra monitor than it is to get a purchase request approved for a wireless-enabled rabbit. Big Visible Cruise is the same idea, it’s just a visualization instead of a physical device. Judging by how much we all enjoy seeing it, it will probably stick around in addition to any physical device we pick up.

You can find out more about the project at http://code.google.com/p/bigvisiblecruise/. After the holiday I’ll post some pictures and explain how we are utilizing the big display in our team room.

In the meantime, you can likely get an idea from looking at the display while it’s monitoring three different projects in the following screen shot…

This shows that I have three projects (Foo, Bar, and Some Project) being run on my CCNet server. In this example Foo and Bar are successful and Some Project is broken.

The other state that isn’t represented in the pic above is the “building” state. When a project is building, the row representing the project will turn yellow.

By default, BVC will poll every 15 seconds. I recommend using BVC with CCTray so that you have a big visual display along with auditory clues about your build process.

Big Visible Cruise is being released under the MIT license.

If you’re interested in WPF and/or information visualization, I’d love any contributions :)
I plan on providing some interesting visualizations over the next couple of months. Let me know what you’d like to see on the RoadMap page.

24
Oct

Remote Pairing

I’ve been spending roughly 4 - 8 hours a day doing remote pair-programming lately. Although there are always connectivity issues (usually once or twice per day), it’s still only a minor nuisance. Overall, I’m really enjoying the experience and it’s starting to feel pretty close to side-by-side pairing.

The tools that I use on a daily basis include Microsoft SharedView for screen sharing and Skype for voice and video. The combination of these two tools seems to work very well (even over wireless).

SharedView is still in beta, but it is a very nice, minimal, and responsive tool. With the exception of the ads (integrated into the tool), I’m impressed. I’ve used many other tools in the past but this one just seems to fit the way I work better. The features like the ability to see other mouse pointers, clicking, and highlighting is a very nice feature.

Right now, the only thing that consistently bugs me is the quality of my headset (junk). I’m hoping to pick up a new one in the next couple of days.

24
Aug

Learning From Journalism - The Inverted Pyramid

In developing and envisioning software, it’s easy to forget about prioritizing value. Even with agile development teams, it’s common to see “sets” of functionality prioritized instead of rank-ordered. One idea that I’ve been pushing hard on lately is to not let anything into the backlog that’s not prioritized (as in rank-ordered).

Why? Well, one place we can pull ideas from is the inverted pyramid approach to journalism. The inverted pyramid approach is a common metaphor in journalism to avoid “burying the lead.” The “lead” of an article is the beginning of the article that conveys the core information of the story.
Journalism (and the publishing models of newspapers and periodicals) is a great place to look for ideas and inspiration for agile approaches. When a newspaper has to be distributed, it has to go. A newspaper isn’t held up for individual journalists to finish their articles. Sound familiar? This is exactly the same as doing time-boxed activities in agile approaches.

The essence behind the inverted pyramid (from Wikipedia):

The triangle’s broad base at the top of the figure represents the most substantial, interesting, and important information the writer means to convey. The triangle’s orientation is meant to illustrate that this kind of material should head the article, while the tapered lower portion illustrates that other material should follow in order of diminishing importance.

This makes perfect sense for a couple of different reasons (all of which have their own parallels in agile development):

  1. If everything doesn’t match up perfectly in the layout or limited real estate of the paper, the end of the story can be cut out without sacrificing the important essence of the story. This also allows for the staff to quickly make room for late-breaking news or for additional advertising.
  2. The reader of the story doesn’t need to read the entire article to understand the core elements of the story. In fact, they can usually get almost all of the information by just reading the first few sentences.

In addition to using this as a guiding principal for the prioritizing of the backlog (see reason #1 above), we can also apply this technique to our own writing for any documentation that we need to create (see reason #2).

I first ran across this concept while reading Made to Stick. One of the quotes from the book is by Dan Wycliff (an award winning editorial writer) who says:

“I’ve always been a believer that if I’ve got two hours in which to write a story, the best investment I can make is to spend the first hour and forty-five minutes of it getting a good lead, because after that everything will come easily.”

Practicing this approach can help us steer towards generating revenue faster (through prioritized features) as well as clear writing (by focusing on the important information).

21
Aug

The Power Of Silence

An interesting facilitation technique that I’ve learned to frequently rely on is silence. The first time I ran across the technique was in a CSM course taught by Hubert Smits and Tamara Sulaiman. One of the exercises that we explored was Silent Grouping. The exercise was great and worked very well in the context of the training session.

When I returned to work I started trying various techniques with silence and most of them went very well. The majority of our facilitated sessions were very large and it was usually a constant challenge to move off of side conversations and keep the group focused. One of the techniques that frequently returned good results was using time-boxed silence alongside various other techniques that are used often in agile meetings (brainstorming, prioritizing, sorting, grouping, etc.).

There just seems to be something about the ability to become rational, absorbed, and focused on the task when the “no talking” rule is in effect. It frequently seemed easier to drive towards consensus when the group used silence as a method for creating, grouping, and processing information.

20
Aug

Be Careful With Your Numbers

A couple of years ago I put together some collateral to use when “selling” agile to potential clients. As part of the effort to educate our sales team about agile methods I wanted to provide some strong evidence for our sales team to use.

The only numbers that I had seen at this point were the numbers cited in Agile and Iterative Development: A Manager’s Guide by Craig Larman. To say the least, the numbers were very impressive: Of those polled, 93% saw increases in productivity, 88% increases in quality, 83% improved stakeholder satisfaction, 49% reduced costs, and so on. I dropped these numbers in the collateral and I made every one of the sales members happy.

A few months later I was looking for some deeper numbers and I started to dig deeper for more quantitative data. The first place that I went to look for numbers was the study used that came up with the above numbers (by Shine Technologies in 2003).

When I started digging deeper, I realized that this survey has huge room for error. I’m not an expert on surveys or quantitative methods, but what I read didn’t leave me feeling convinced that it was worth publishing and standing behind the results.

After digging a little deeper, I noticed that these numbers (that I had been advocating) were based on a web-based survey that had only been taken by 131 people. Yes, 131 people and web-based. Ouch.

You can find the survey here.

Now, I don’t want to completely discount the survey and/or the results. This is important information; but I’m just not comfortable presenting these findings as “evidence” that agile works. I’m just not comfortable putting them up on my company website and I’m not comfortable putting them in my presentations. I believe in agile methods, I just don’t believe that this study “proves” that they are a valid alternative.

An interesting thing that I have noticed is that many individuals and many companies have used this survey as justification for agile initiatives. Last week (at Agile 2007) I saw these numbers presented multiple times in slide decks and I’ve seen them on plenty of web sites of vendors that are offering agile services.

Anyway, I just thought that this was an interesting bit to share about how you should always know more about the survey results and numbers that you use to backup any claims. Make sure you can stand behind your numbers and that you find out the information behind the numbers.

17
Aug

Agile 2007 - Parting Thoughts

Overall, Agile 2007 was a wonderful experience. I really enjoyed my time at the conference and attended some really good sessions (and a few that were really bad as well). This was my first conference and I’ll be back for sure next year.

My favorite sessions included:

(Follow the links for the abstracts, presentations, and handouts)

  1. Agile Enterprise Rollout–The Greening of the Software Industry (Jean Tabaka, Ryan Martens)
  2. The Role of Leadership in Software Development (Mary Poppendieck)
  3. Learning Kaizen from Toyota [with MindMaps] (Mary Poppendieck, Kenji Hiranabe)
  4. I Don’t Like Mondays - Improving Agile Team Collaboration Events (Jean Tabaka)
  5. Reaching New Heights: Learning to Adapt is Essential (Susan Ershler)
  6. Agile adoption at Google: Potential and challenges of a true bottom-up organization (Mark Striebeck)
  7. The Agile Enterprise: Real World Experience in Creating Agile Companies (Jeff Sutherland)

Some of the big-picture realizations that I came to:

  • Mary Poppendieck has turned into the Tom Peters of the software industry (well-deserved).
  • Lean thinking has started to move to the center of the agile universe (finally).
  • Executable specification / story-driven development is moving to the mainstream (finally).
  • Everyone wants to scale agile.
  • Everyone wants to distribute agile.

A few things that I’m concerned about:

  • Lean has moved to buzzword status. A lot of people are talking about Lean but I don’t think the majority understand the essence behind it. I think this will get better.
  • Everyone wants to make “Enterprisey” software with agile teams.
  • There are a lot of “agile” consulting firms that are full of shit.

And some other random thoughts…

I think the fact that everyone is focused on “scaling” agility to large teams and distributed projects and that there will be a lot of agile disasters over the next couple of years. Now that the bigger software companies are moving to agile, the teams are getting too big and they are adopting agile in scary ways (too big, too fast). I think that you need to evolve to big teams, not start out there. I would also (passionately) argue that you should focus on how to have smaller software instead of how to scale agile teams to accommodate large software. I seem to be in the minority.

Lastly, I really think that the organizers of the conference need to step it up. The programs sucked (hard to read, hard to navigate, mis-prints, missing pages, etc.), the event was really hard to follow (talk duration, locations, topics), the location of the conference sucked (tight hallways, hard-to-find rooms, etc.), and the beverages and food was awful (a big thank you goes to Rally for providing everyone with bottled water).

I certainly appreciate that everyone worked hard to put this together, but I expect the basics to be nailed for a major conference.

23
Apr

Nabaztag and Continuous Integration

I ran across this post earlier today about integrating Nabaztag with CC.Net.

I have to get one or two of these things for our current project :)

16
Apr

Collaboration Explained

Over the weekend, I read Collaboration Explained by Jean Tabaka. This is one of the best books that I’ve read in a really long time. The book is geared towards the facilitation of agile software teams.

The book includes a wealth of information on how to facilitate, prepare, and follow-up on many different types of collaborative exercises, meetings, and interactions within agile teams. There are a ton of prescriptive techniques that are very effective in dealing with multiple levels of teams through various stages of a project.

I can highly recommend this book for anyone acting in a coach, ScrumMaster, facilitator, participant, or leadership position on any agile project. The book is extremely insightful and entertaining. I went through two highlighters while reading the book :)

07
Apr

The Evolution of Teams

I sat down to catch up on a little reading this weekend and have been making my way through The Wisdom Of Teams. This is a very interesting book about the observations of various types and levels of teams, the way teams perform, and the characteristics of each respective type.

I’ve always viewed teams as teams and recognized good teams by “that feeling” that you get when you participate in one or see one in action. Beyond “that feeling”, I really hadn’t thought about the categorization of teams beyond a “good” and “not-so-good” level. This book has been very interesting because of the research and observations that they have done in grouping the different categories as well as comparing and contrasting the different types.

Throughout my time in the IT industry I’ve seen all these categories of teams and participated in each respective type. One very relevant point from the book is the discussion about the differences between working groups and teams. This really hit home with me because of the methodology changes that I’ve been involved with as both a consultant and an FTE.

The image below shows the different categories discussed in the book and the evolution of performance when moving along the curve.

One thing that I’ve noticed from starting up various initiatives to move towards agile methodologies over the past couple of years is the thrashing that occurs when you move from a command-and-control structure (usually accompanying traditional methodologies) to a self-organizing structure (more prevalent with agile methodologies).

It’s rare that a new agile team hits the ground and starts performing as a “high-performing” team in the first couple of months. I’ve never seen it happen when the team members are coming from traditional methodology backgrounds. I really think this can be expected because there is so much happening so quickly. This scenario is usually very disruptive and usually overwhelming from the standpoint of the individuals on a new team.

While the leap from “working group” to “potential team” can be a rough experience for many individuals, the progression from “working group” to “real team” (and possibly to “high-performing team”) is a pleasure to watch and a pleasure to be involved with.

So, what is the difference between a “working group” and a “team?” The book recognizes the basic distinction as performance.

“A working group relies primarily on the individual contributions of its members for performance, whereas a team strives for a magnified impact that is incremental to what its members could achieve in their individual roles.”

I think that the giant leap in forming a team for most individuals from a command-and-control structure is the blurring of roles and shared accountability that occurs on a team. Most individuals in command-and-control organizations or models think from the standpoint of individual contributions while a true team focuses on mutual accountability and the contributions of the team. This is a hard leap to make, but the benefits (both organizationally and personally) are usually tremendous.

01
Apr

Collective Intelligence In Biological Teams

There is a really interesting article here that looks at how various colonies and groups self-manage. This article has some interesting ramifications to thinking about how we communicate as humans and how we communicate in different team environments. There are also some interesting thoughts floating around in mind about how some of the tools that I typically use could be modified to be more useful.

Why Penguins Have No Commanding Officer [InsideKnowledge]