Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

I recently started writing a book review on Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. Check out the first part of my review. I have read Chapter 1 entitled Explained (View from the Outside). It was a very interesting chapter that set Crystal Clear as the answerer to Alistair Cockburn. It made many aspects of the Crystal family clear in my mind. I enjoyed the questions, and the answers were insightful and helped me to put the ideas into a whole picture.

At the moment I am reading Chapter 2 entitled Applied (The Seven Properties). Frequent Delivery, Reflective Improvement, and Osmotic Communication made sense to me and aligned somewhat to my own beliefs. When I started reading the fourth property, Personal Safety, certain parts seemed fine, while others set off warning bells. I believe that the purpose of any team is to progress. This is achieved through trust, respect and unity.

Cockburn says “Once personal safety and amicability are established, a useful, playful dynamic may emerge. People may wage competition with each other. They may argue loudly, even to the verge of fighting, without taking it personally. In the case where someone does take it personally, they sort it out and set things straight again.” - page 31.

The statements above concern me. Cockburn addresses trust by saying that people will not take it personally. Respect is lost because they “… May argue loudly, even to the verge of fighting”. I would be unable to say that I respect someone if I yell at them or even raise my voice. Now unity is completely destroyed. For some reason our society and many societies around the world not only condone competition, it is seen as a way to judge attributes of excellence in an individual. This is not a good sign for our progress towards unity in human civilization.

I agree that being polite and not stating one’s opinion is harmful for trust. However, it is preferable to use consultation instead of competition. Imagine that a team is encouraged to compete with itself to achieve better results. Would there not be feelings of resentment or heightened levels of stress? Now imagine a team that is encouraged to consult and raise the team together without focusing on individual success. Would not this team feel excited to be around each other? Would they become fast friends and grow as a unit? Would family members of the team be enthusiastic to be included in picnics and socials?

Now the big question:
What is better, individual success or team unity that add value to not only the team but all who interact with them?

I will continue to read this book and post my reviews. I find it interesting that this book has helped to see the confusion that is happening all around the world in terms of progress, success, and human development.

I welcome any comments on my posts.

I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.

I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.

I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.

What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?

I have been working with Agile for a few months. At Berteig Consulting we are using OpenAgile to run our small business. As such we try to use various tools to make our life easier. I have already mentioned that we use CardMeeting for our cycles and tasks. I have tried using PlanningPoker for online estimation. It seems useful, but maybe our team is too small to make great use of it. I am also looking for other ways to manage the reflections and learning from each cycle.

I have received an email from David Wolrich of CardMeeting that states: “Anyways, I rely on the trickle of news from legitimate organizations like yours to let users know that CardMeeting is still around, that I am still adding features, and to generate interest; thanks again.” So maybe some of you could try it and give him a shout. Much like other free applications on the net such as Drupal and Neo Office this one could become more robust and useful.

I am wondering if I am spending too much time on tools and not enough reading and researching Agile methods. I am enjoying reading about Agile success stories. Anybody know of small businesses that have documented or written about achieving success in Agile? Is there an Agile bible or maybe a book about the best ways to succeed using Agile?

So this is the question that I am wondering: Are tools better than books when it comes to Agile?

Scrum Study Guide, “The Best Tool for New ScrumMasters”, is now available at Scrum Study Guide. This guide is designed to be an editable tool for helping ScrumMasters do their jobs effectively. With the Scrum Study Guide you are able to keep track of the rules of Scrum, to keep structured notes on your own job as the ScrumMaster, to maintain a list of online reference material, to assess the progress of your team, and to organize the obstacles you are working on.  It also contains a wealth of reference information for learning along the way.

This is the project I’ve been working on for the last several months that has reduced my output here on Agile Advice.  It represents a huge investment of my time as well as several other people who have assisted me in this including Paul Heidema and Garry Berteig.  Purchasing the Scrum Study Guide, aside from its usefulness as a tool itself, will also give you substantial discounts on other services offered by Berteig Consulting Inc.  Finally, if you like it, you can help to share it by letting us know who should get a discount on their purchase of the Scrum Study Guide.  Enjoy!

The Definition of “Done” is an important concept that helps us understand how to produce working, potentially shippable software at the end of every Sprint. Previously, I wrote about how to expand the definition of “done” from the perspective of the team’s skills, capabilities and work processes. This time around, let’s look at it from a more tactical perspective: how do we identify things that should be added to the definition of “done” and when do we do this? (more…)

This might be impossible, but I was thinking that it would be cool to have a single reference of all the possible agile practices.  Obviously, since “agile” is not a single defined method, we must take the word “comprehensive” with a bit of humor (or a grain of salt).  I’ve attached a spreadsheet that represents my first draft (it’s in OpenOffice.org format so that you don’t have to worry about me spreading viruses - if you want it in MS Office format, email me at mishkin@berteigconsulting.com).  I’ve split the practices up into several sections including: “Agile Skeleton”, “Common Practices”, “Basic Scrum Practices”, “Optional Scrum Practices”, “Extreme Programming Practices” and “Lean Practices”.  I’ve stopped there because I’m not an expert on other agile methods such as Crystal, Agile Unified Process or Feature Driven Development.  I imagine that this list will be useful for teams to do self-assessment and to think about ways they might improve.  Perhaps it could be used in a retrospective setting.  Berteig Consulting coaches use something similar to this to assess the effectiveness of their engagement with clients.  If you think of practices I’ve missed or other potential uses for a list like this, let me know in the comments.  My intention is to convert this to a wiki and make it available under a Creative Commons license once it is a little more refined.

Agile Practices List (OpenOffice format - 68KB)

I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.

(more…)

Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.  These Patterns of Agile Adoptions are described as three sets of contrasting options:

1. Start Small vs. Go All In
2. Technical Practices First vs. Iterations First
3. Stealth Mode vs. Public Display

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.

What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?

(more…)

I just read a recent article on PMHut called “Schedule Questions: Pair Programming and the PNR Curve“. There is much in this article that is important for agile project management… and much that should be avoided at all costs!

(more…)

While it may look like Agile teams all work in big empty “common rooms”, the truth is that people need more than that. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.

(more…)

Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.

by Paul Klipp

For a decade now, agile processes, of which the best known is probably eXtreme Programming, have been gaining wide acceptance among developers, but many customers are still in the dark. Agile sounds good, but what does it mean? This is a quick and dirty preview of what you can expect when you choose an agile process.

(more…)