Archive for April, 2007

29
Apr

A Simple Guideline For Testing

Keep your tests easy to read…

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

Global Awareness Layer (Crisis in Darfur) - Google Earth

Be sure to take a look at the Global Awareness layer in Google Earth if you haven’t stumbled across it yet.

I recently got lost in viewing the information about Darfur. Google Earth has turned into a wonderful medium for viewing information that other media has a hard time matching.

In addition to the great medium, I’d also encourage you to take a look at the content that is provided (from the US Holocaust Memorial Museum) on the crisis in Darfur.

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]

01
Apr

CSM Training

 

I spent this past Thursday and Friday in Boulder going through a Certified ScrumMaster course at Rally. I’ve been working in agile environments for quite a while now and I’ve used XP and Scrum on quite a few projects over the past years. I wasn’t really sure what to expect from the course, but I can now say that it was definently worth it. The class was really good and well worth the time to attend. I learned quite a few collaboration techniques and enjoyed listening to the experiences of the instructors and participants.

I would highly recommend the course even if you have a lot of experience with Scrum. I can also highly recommend Hubert and Tamara.

01
Apr

Towards Permeable Scope

“Scope creep” is a term that tends to come up often when working on a software project. It’s an interesting term to think about because it usually means that the individual, the team, or the company really need to step back and re-think why changing scope should be a bad thing.

The last time I checked, my job was to solve business problems or create business opportunities for my customers. If this is the case, then why should I care if scope changes? Shouldn’t changing scope be a good thing? If the scope is changing then it likely means that the business has found a new opportunity or that we have received feedback on something that could add significant value to the market or to our customers. If my heart is in the right place and I really care about delivering value then change can be a good thing.

The problem with “scope creep” is not changing scope; the problem is really a process or mindset that doesn’t allow for change. Pouring concrete on your requirements might help with predictability, but it sure doesn’t help you build great software.

01
Apr

The Power of the Network

I’ve been fortunate enough to work at a ton of different consulting companies. The most valuable thing that I learned through working at all the different places I’ve been is the value of the internal networks that exist within kick-ass consulting companies.

It’s strange to me that most consulting firms completely gloss over the idea of building internal networks to expand knowledge and improve collaboration for the consultants that work there. This is a huge benefit for the consultants, the consulting firm, and the customers that use their services.

Now that I’m on the other side of the fence and I’m looking at a variety of different vendors, this has turned into a key criteria during the vendor selection process.