« September 2007 | Main | November 2007 »
October 29, 2007
Agile Groups on FaceBook
FaceBook is an extremely popular social networking site. It is also becoming an effective community collaboration site. The agile community is gradually starting to see the value of this environment. Here are four groups related to agile practices:
Agile and Lean Development Community (589 members)
Agile Project Management (218 members)
Extreme Programming (16 members)
Scrum (7 members)
Posted by Mishkin Berteig at 01:26 PM | |
October 23, 2007
Truthfulness in Agile
I believe in Agile. To the best of my knowledge and based on my experience, Agile methods are the best way for teams, organizations and communities to get stuff done. Doesn't mean it's easy though! The biggest challenge of Agile is in the need for truthfulness.
Most of us live and work in environments where the truth is not totally welcome. Maybe it's "little white lies". Maybe it's hiding behind the raw facts. Maybe it's withholding information. Maybe it's exaggeration. Maybe it's "rose colored glasses". Maybe it's self-preservation. Maybe it's getting attention. Maybe it's lack of confidence or over-confidence. Truthfulness is compromised on a regular basis in most work environments and in most interpersonal relationships.
Agile methods have several powerful benefits. To get those benefits, agile needs to be done right. To do agile right, requires truthfulness.
Why does agile require truthfulness? Because agile methods have fewer checks and balances, fewer gating points, far fewer bureaucratic procedures, than other methods. This lack of safety mechanisms means that it is possible to subvert a team using an agile method more easily than it is to subvert a high-ceremony, high-rigor, high-paperwork type method.
That said, there are
- some
Here is a worst case scenario.
Someone on the team is frustrated or angry about something. This person, let's call him Joe, decides he's going to lash out. He starts by spreading some not-very-nice-nor-accurate gossip that gets the other team members to not trust each other as much. He then makes up some sort of technical risk factor and starts to inflate his estimates and convinces a couple other people to do so as well... just in case. The team's velocity appears stable, but their actual output has decreased. The team is not yet mature enough in their interactions so these things are not mentioned in the retrospective. Joe gradually finds ways to demoralize everyone on the team. The team starts having more and more problems with code quality which slows it down. The process facilitator, Mary, notices these things. However, Joe was planning ahead. Joe has been talking with Mary to help her see how everyone else on the team is subverting the process, thus deflecting attention away from himself. Mary, also relatively new to her role, isn't careful about checking facts and steps on some toes. Now she is almost powerless to influence the team to get it back on track... and the final blow comes as Joe starts raising obstacles in the daily status meeting that are "made up" and designed to be difficult if not impossible for Mary to help with thus solidifying her impotence in the minds of the rest of the team. Ug.
Is there any way out of this? Not really. Intervention is possible by an experienced coach, but not guaranteed to succeed. The best thing to do is probably to disband the team get an expert retrospective facilitator in to try and extract some of lessons, and then try again with a new team.
What else could be done? Is there a specific intervention that could be performed given that we don't know that Joe is behind it all? Could this really happen in an agile environment?
Posted by Mishkin Berteig at 09:05 AM | |
Scrum Rules Cheat Sheet - Updated!
A few weeks ago, after my last update of the Scrum Rules Cheat Sheet, I decided that it might be a good idea to ask Ken Schwaber about what I had developed... He immediately asked if I had checked it against the rules listed in his book Agile Project Management with Scrum. Of course, I hadn't. In fact, although I've read the book, I neglected to read the appendix in which the rules are contained. So, I read it and updated the cheat sheet. I found that there were a few rules that I was "assuming" because I work with Scrum so frequently. As well, there were a few rules that I actually didn't remember. The cheat sheet is now getting to the point where I would like to break it into two pages, but then it wouldn't be a cheat sheet anymore... so with smaller font size... presenting, the new and improved Scrum Rules Cheat Sheet. Here is the original article about the Scrum Rules Cheat Sheet.
Posted by Mishkin Berteig at 08:19 AM | |
October 18, 2007
Agile Support - Helping You Get Better at Agile
A sister site to Agile Advice has been moved into "pre-official-launch" stage: Agile-Support.com. This is a site for individuals to discuss agile methods, for downloads of various resources, and, if you register, to host blogs and other content development by individuals wishing to do so in an online community setting. Think of this as the "beta" launch: there are probably still many kinks to be worked out.
Posted by Mishkin Berteig at 10:18 PM | |
October 16, 2007
Reminder: Agile/Scrum Training - Toronto, Ottawa, Beijing
The Toronto class coming up in one week still has spots, the Ottawa class in November is nearly full, and the Beijing course pre-registration discount is almost over! Please sign up for a course today!
Posted by Mishkin Berteig at 07:23 AM | |
October 14, 2007
Agile Learning and Education: The Agile Professor
Well, it's officially launched: The Agile Professor - Creating an Agile Learning Environment for Classrooms and Schools. This blog, authored primarily by my father, Garry Berteig, is an exploration of the use of agile methods to organize learning environments such as schools, classrooms, seminars, workshops, etc. The material in this blog will include Garry's experiences over the past two and a half years of experimenting with agile methods in an educational context as well as a record of his continuing exploration of this topic. I might chime in from time to time too :-)
Posted by Mishkin Berteig at 10:26 PM | |
October 12, 2007
Beijing Scrum Training
I'm organizing a 3-day ScrumMaster Certification course in Beijing to occur on the 19th-21st of December. I need several more people to express interest in the course before I can confirm it. For those who "Save a Spot" early, there is a 20% discount available. This discount is only available until Oct. 20th. At that time, I will see if the required number of people have signed up and then make the final decision if the course should go ahead. If you or someone you know is interested and would like to receive this training in Beijing, please "Save a Spot" right away so that I can count you towards ensuring that the course does go ahead! Please sign up here!
Posted by Mishkin Berteig at 09:10 PM | |
Agile Classroom Management
I'm fascinated by the idea of applying agile methods outside of software... be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years... agile classroom management. Here's how I do it in my Agile Project Management / ScrumMaster Certification courses:
My father, Garry Berteig, had been using agile methods in his classroom for over two years before I tried it myself. I had gone into one of his courses at Keyano College in Fort McMurray to give a presentation to his second-year media students on agile and Scrum. They used it for a video project (see "A Student Documentary Film Project" and "Scrum Saves the Day for Media Student". Out of that experience, and others, he developed the idea of the Learning Circle as the basic cycle in an agile learning environment.
In the meantime, I became a Certified Scrum Trainer. Back when I did it, this just meant co-teaching a Scrum class with Ken Schwaber. He had a standard slide deck which he presented as he masterfully guided a class through two days of Scrum training. I (as expected) took that deck and made it my own by reformatting, rewording, changing a few of the exercises, and changing the emphasis in a couple of spots. And then I used that deck with minor corrections and updates and some expansion over the course of the next 16 months.
In the meantime, I was also doing a fair amount of training for teams and organizations that didn't care particularly for Scrum, but just wanted to know more about this "agile" thing. Sometimes it would be a one-day course, sometimes as much as five days (that was exhausting!!!). I developed a substantial body of modules including exercises, case studies, and special topics. Eventually, I found that I was having a hard time fitting my fixed agenda materials into the time I had allocated. For example, I was commonly doing a three-day course and would find that by the end of the first day I was a little behind on my agenda and by the middle of the third day I would certainly be running out of time and miss possibly even two or three modules in the agenda.
Finally, last Sprint, I got a big client who asked for training for a large number of their staff. This gave me the opportunity to: a) work with the same materials and agenda at least three times, and b) involve an assistant in all three deliveries. The first time through, I had the typical problem where the third day was a terrible rush. The second time through, it happened again, but I had de-scoped and re-arranged some of the material so it didn't seem as bad. After that second time, my assistant, an excellent coach, David Chilcott, suggested that I try to apply a more flexible... agile... approach to handling the materials. We did a quick revision of the materials to support this idea and then the third class was run as an "agile training environment". What did this mean?
The main insight was that the time allocated to the class was timeboxed. This meant finding a way to prioritize the work of the class so that the majority of the participants would get the best value possible for their time in the class. We did this in two ways:
1) As questions came up, we found that some of them needed to be deferred because they would be answered in a later module or because there was background material that needed to be covered first. So, for every question that needed to be deferred, we wrote it up on a 3x5 note card and put it up on the wall. Now, in order to keep track of this, we also had all the course modules written up on 3x5 note cards and up on the wall too. Most of the question cards would immediately be put up with the associated module card.
2) We drastically cut back the core required modules for the three days and made everything else optional. We then decided on a simple in-class mechanism to choose from those optional modules. At the end of the first day, we had time for one optional module so the class voted and we chose the module based on that vote. Likewise at the end of the second day. By the third day, we had a substantial portion of the day un-allocated. As soon as we finished with the required materials, we got the class to choose the next module to cover. As soon as that module was covered, the class chose again from all those still remaining.
It was a bit of a mess and our mechanisms didn't work perfectly, but it got the job done. At the start of our second day, the cards we were using to track modules and questions looked like this:
After we finished the course, we did an in-depth reflection and decided on some changes to be made. One of the most important was actually very simple: make the module cards much larger so that it was possible to put many question cards right on the module card. Here is what this looked like in a recent class:
The left is the module card at the start of the course with questions that were generated by the course attendees when asked what they wanted to learn from the course. The right is the same module at the end of the course. You can see that one additional question card was added between the start of the course and the time when the module was actually covered. You can also see that I use big check marks to show to the class that the module is complete.
Another change to the method of doing this agile classroom management came in the further refinement of the module content and sizing to be more appropriate for doing the modules in unpredictable sequence. This included things like checking definitions, improving some of the introductory material (to make sure all the concepts were introduced, not just some of them), finding references to other modules and removing them, and in some cases moving material from one module to another. There are still improvements to be made in this area.
Thirdly, we now are better at explaining to the class how this will all work at the start. We are modeling an agile process in the way we run the course. This means that the attendees will have an opportunity to influence what material is covered and in what depth. It also means that if the class takes a lot of time with questions early on with the basic material, it leaves less time at the end for optional modules. The people in the class can now visibly see these tradeoffs.
Here are two photos from a recent class. The first was taken at the end of the first day (note that I forgot to use the check marks on these cards). The second was taken at the end of the third day. You can clearly see how the modules of the third day were chosen entirely by the participants from the available optional modules.
This mechanism of managing a classroom using an agile approach has had some very interesting results:
1) Every class is substantially different. Before, the differences were always in the details: timing, specific questions, etc. Now, the actual material covered is uncertain. I always make adjustments to the course materials after every course. Now, not only are those differences in play, but also the actual modules covered might be different. The fascinating thing is that now, by the time we get to the last module, most of the people in the class are giving off a palpable sense of satisfaction: their urgent questions have been answered. Sometimes, this is so strong that I do the graduation "ceremonies" right before covering the last module so that people not interested in that last module can leave a little early.
2) I get far fewer comments in my feedback forms that indicate a desire that the course was longer. Before I started using this agile learning environment, I would get a substantial number of comments to the effect that it was really too bad there was not another day. Now I rarely get those comments.
3) The attendees in the class see how an agile approach actually works in a real life situation. They see that allowing the requirements to change over time is actually a good thing. Every single time I do this, there is a pattern that shows up on the third day that relates to the way the class prioritizes the next module. I count up the votes and choose the next module to cover. All the other modules have their scores written on them as well. After a module is covered, instead of using those old scores, the class takes another vote. Every single class, the priority changes between votes. This clearly demonstrates the power of allowing stakeholders to change their minds after seeing real results.
4) Participants in the course are engaged at a deeper level. There are lots of "tricks" for keeping people engaged: discussions, exercises, simulations, questions, presentation eye candy, etc. All of those things have their place and are important. However, by having participants steer the course itself, the level of engagement suddenly becomes much more substantial. The participants are responsible for the results of the class in a way that is quite unusual in most educational environments. This responsibility is granted to them and they take it seriously. I rarely see anyone refuse to participate in this process, and I never see anyone attempt to subvert it.
If you are interested in learning this mechanism of classroom management, I strongly recommend:
1) Learn up on agile. The openagile.org web site is starting to define an agile method that is abstracted away from the software legacy that agile methods currently are shackled with. This site is still in its infancy so treat it gently :-)
2) Come try one of my courses! (Yes, that's a blatant shameless plug!) You will get to experience and learn the agile method in a focused setting. The courses are IT/software focused in some respects, but since they are non-technical courses, and really about agile project management and human interactions, almost anyone can attend (I've had dancers, administrative assistants, educators, artists, community workers, executives, and actors all attend).
3) Get in touch with me to find out more of the details that didn't make it into this blog entry. The best way to do this is (really) through my business web site: berteigconsulting.com where you can find both email and phone contact information.
Well, I finally got around to writing this up. This is part of a series of related articles "tagged" as USEFUL started by Scott who writes at Tyner Blain. His article, which started the game of tag, is called Software Product Success Stories. Scott... I'm sorry this article isn't about software!!!
I would like to now tag a few people who write useful blogs:
Mike Vizdos who writes the Implementing Scrum blog. This blog is best known for the fabulous cartoons of the Chicken and the Pig, but also has a lot of great and practical insight on the challenges of, you guessed it, implementing Scrum!
Tobias Mayer who writes at Agile Thinking. He doesn't write often, but his articles are always fantastic! I hope that Tobias will take the time to write something in this "useful" stream and pass along the tag.
Mark Levison writes Notes From a Tool User and discusses many things, not just agile. His writing is fun and he's in the trenches doing real serious work getting his company to use agile. He's got good insight.
Posted by Mishkin Berteig at 03:46 AM | |
October 01, 2007
New Agile Aggregator - Agile Daily
This looks interesting: Agile Daily. This is an aggregator site like technorati or Agile Planet (seemingly defunct now), but with some interesting twists described in more detail at SocialRank.com. Apparently, SocialRank.com is setting up aggregator sites that are meant to also be community sites... maybe a little like InfoQ? Interesting experiment: it's quite new so we'll see what happens.
Posted by Mishkin Berteig at 10:15 AM | |