Agile Advice

« December 2006 | Main | February 2007 »

January 31, 2007

Intermittent Internet Service Outages

Sorry folks... over the past day and a half, and expected for the next day or so Agile Advice and other web sites hosted on the Berteig Consulting Inc. servers are experiencing intermittent and poor internet connectivity. If things are very slow or fail part way through a page load, this is why. Hopefully we'll be back up at full steam soon.

Posted by Mishkin Berteig at 12:27 AM | |

January 27, 2007

The Freedom of Limited Capacity

Something that I would have thought impossible has happened. By understanding how incredibly limited my capacity to do work is, I am getting a greater and greater sense of freedom and contentment.

My "experiement" to run my business using Agile Work practices is starting to bear some fruit. The trouble is, that so far, that fruit is simple better knowledge of my extremely limited capacity to get things done during a single week-long iteration. I can do 3 or 4 items from my Work Queue which works out to about 15 or 20 tasks. This seems ridiculous to me! Surely one hard-working guy can get more than that done!

But I can't. I'm getting to the end of my fourth iteration and it's the same thing again!

I know some of the reasons for this: interruptions, unexpected work, unremembered work, and my general nature of being easily distracted by shiny things!

In some ways this has been quite frustrating. I have a huge queue of work I want to get done for my business. But the other side of the coin, the one that looks different than I expected, is that knowing just how limited my capacity is... is liberating! I don't feel nearly as stressed as I did four weeks ago. I have the courage to commit at an appropriate level. I can start to believe my plans. I can see - realistically - just how much I need help to achieve my goals. I can see how soon I will be able to do cost/benefit analysis on hiring vs. doing the work myself (can't do that yet). I can even start to believe that I might be able to reach my original goal of reducing my working hours from 80+/week to 50 or less... as long as I make sure that my Work Queue is properly prioritized with that goal in mind.

---

I have worked with a number of teams that have gotten to this point of certainty about their capacity. I've seen this happen in others... and now I recognize it for what it is: relief. One team I worked with after only two iterations had a very clear idea of their capacity, and you could feel the comfort level of everyone with this new agile thing skyrocket. Another team I worked with got a clear sense of its capacity after only three iterations. This team settled in and then started to work to increase their capacity and did a fabulous job by using automation tools, eliminating various organizational bottlenecks, etc. They wow'ed the rest of the organization with their incredible, consistent delivery of value. One of my former students, Dmitri Zimine, gave a presentation at the XPToronto group where he talked about the incredible level of trust that developed between his team and the rest of the organization after consistently, iteration after iteration after iteration meeting their commitments.

All of this is only possible by a rigorous application of timeboxing, careful and consistent task breakdown, and good, honest tracking of results. I wrote a previous article called Seventeen Tips for Iteration Planning. Look it over and see what new ideas you can apply in your situation. If you are frustrated by a team continually over-committing, you will find a lot of valuable advice there.

---

As a parting shot: consider how you feel right now. Are you stressed out? Over committed? Failing to meet your commitments? Feeling guilty? Working insane hours? Not spending enough time with your family? Killing yourself!?

What about the team or organization you work in? Is it constantly being bombarded by problems it can't handle? Surviving on pure heroics?

I can't tell you that following a careful iterative planning approach will fix your problems... but I can tell you that it will reduce your stress levels, help you (or your organization) make appropriate commitments, and let you see the reality of your situation (good or bad).

Posted by Mishkin Berteig at 03:07 AM | |

January 24, 2007

Leadership for the Agile Organization

I found an interesting blog post on cio.com called Leadership for the Agile Organization. This is a neat little piece that covers some of the essential aspects of leadership for empowering teams... but I believe that there are some critical bits missing, and if leaders _only_ did what was in the article, they would have a chaotic mess on their hands. I've added a comment to the article so you can read more about my thoughts there :-)

Posted by Mishkin Berteig at 12:55 PM | |

January 23, 2007

The Agile Zealot's Handbook

This is great! I often call myself an Agile Zealot to my clients. (Usually, they smile... and if they don't I tend to have a short relationship with them!) So here it is, the Agile Zealot's Handbook.

And, since I've got a dead horse lying around waiting to be beaten up some more, I've re-written it (the Agile Zealot's Handbook, not the dead horse) to be non-software oriented. Presenting... the new and improved... non-software oriented... readable by anyone... Agile Zealot's Creed:

VALUE
IF you don't repeatedly deliver results
that produce actual value
for a real customer
into your real world environment
frequently enough to respond to change...

TECHNIQUE
IF you're not paying constant attention to technical excellence
with simple, effective tools, processes and reuse
driven by uncompromising dedication to quality
and the discipline to test everything...

LEARN
IF you're not deliberately going
through stages of planning, acting
reflecting and learning
as frequently as you are delivering results
over and over and over...

TEAM
IF your team is not empowered to self-organise,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...

THEN YOU HAVE COMPROMISED YOUR AGILITY

(and good luck to you... you'll need it!)

Posted by Mishkin Berteig at 08:41 PM | |

Foundations of Agile

What are the foundational documents (online or otherwise) that constitute the basics of what it means to be agile? There is one obvious one: the Agile Manifesto. If you know of others, please let me know in the comments!

Posted by Mishkin Berteig at 03:41 PM | |

Iteration 4: Restart

My third iteration was a big bust. I have re-planned, but there is very little different from my iteration 3 plan. I have chosen the same 4 items from my Work Queue. I have updated the tasks slightly based on experience from the last iteration so that I have 22 tasks. Even with more tasks, I have actually reduced scope slightly so that the tasks are finer-grained.

It was difficult getting around to doing this. I "wanted" to slide back into old habits of just doing whatever I felt like. I found myself spending way too much time doing email stuff.

Re-committing to the same plan (with minor changes) as the last iteration is difficult because I'm feeling slightly demoralized. Still, I think that it has a good chance of succeeding because I actually don't have any major commitments this week other than work.

Wish me luck!

Posted by Mishkin Berteig at 03:33 PM | |

January 22, 2007

Cancelled Iteration

Last week went totally wonko for Berteig Consulting. My planning was bad, bad, bad!

For planning, I totally forgot about three very important scheduling things:

- a ScrumMaster certification course on Thursday and Friday which required not just time in class, but also three hours of commuting each day.

- my birthday for which I had planned a very informal party on Saturday (normally a very productive work day) which consumed the whole day from morning to late at night.

- the departure of my brother Alexei and his wife Ma Jin so that Sunday would be my last day of visiting, again, taking up my whole day from morning to late at night.

Suffice it to say, a 3-day work week was not what I was expecting when I did my planning. Sometime on Thursday I gave up.

I decided to delay starting a new iteration until I could recover a bit. Over the course of four days I get nearly 200 emails that I actually need to pay attention to at some level or another. So, today has been a recovery day and at the end of the day I will plan my next iteration. Since I did not have a delivery meeting (since I cancelled the iteration), I can only do an informal review of the accomplishments:

- some progress on development work for my client
- some progress on invoicing my client
- some progress on automation of my course listings (Selenium is great!)
- no progress on providing a statement to my other client

The causes of this massive failure are obvious. It should be noted that by doing the ScrumMaster training, I did actually deliver value to Berteig Consulting... it just wasn't the value that I had planned!

Posted by Mishkin Berteig at 05:58 PM | |

Never Spread Your Facilitator Butter too Thin

I like butter, and when I eat a piece of freshly baked bread, a good hunk of butter thickly spread is an essential ingredient. I don't skimp on the butter. Using the butter for one piece of bread and spreading it across two or three slices saves cost, but at what price!? Why, the price is my enjoyment.

So how does this relate to Process Facilitators?

Sometimes, organizations try to "optimize" their costs by spreading Process Facilitators thinly. This is a false economy. Having a Process Facilitator for multiple teams is probably better than having no Process Facilitator, but if the organization really believes in the value of the work the team is doing, and the value of the removal of obstacles, then there should be no problem having one Process Facilitator per team.

I strongly advise that there be only one Process Facilitator per team for the simple reason that the Process Facilitator is a member of the team. The Process Facilitator does not _individually_ commit to the team's goal for an iteration, but the Process Facilitator must feel a great deal of responsibility for that goal given that this person is responsible for tracking, facilitating and in some cases actually removing obstacles to the team's ability to meet its goal. As well, the Process Facilitator protects the team from new impediments.

I think that for rare individuals with relatively established teams, it would be possible to be the Process Facilitator for more than one team effectively. Remember that the ideal team size is 7+/-2. For much smaller teams, (4 or fewer people), you might find that having a single person dedicated to the role of Process Facilitator is too much overhead. But rather than sharing one Process Facilitator across multiple small teams, consider having one individual on each team who has some substantial portion of their time dedicated to those duties.

A Process Facilitator who is not part of the team cannot be properly informed of the needs, difficulties and successes of the team. This only leads to frustrated teams, frustrated Process Facilitators and organizations that improve much more slowly than they could.

Never spread your Process Facilitator too thin.

Posted by Mishkin Berteig at 12:24 PM | |

January 19, 2007

Aspiring Writer? Agile Guru Wanna-be?

Agile Advice gets about 600 hits per day. This number is growing. If you would like exposure and don't want to start your own blog from scratch, I am always looking for people to contribute. Topics of interest include teams, organizational development, agile outside software, metrics, appropriate tools, interesting challenges, good books, links, short articles or long, and anything else that you think might be interesting. You can email proposals to me: mishkin@berteigconsulting.com.

Posted by Mishkin Berteig at 07:34 PM | |

January 17, 2007

The Inner Ring

Here's a slightly off-topic, but nevertheless excellent read: "The Inner Ring" by C S Lewis. This is a talk given by C S Lewis to what seems to be a group of university students. In it, he describes the notion of the inner ring and the desire to be "in". It is amazing how much our culture in North America and our corporate culture is driven by this desire. I'll leave it to you to decide if this is good or bad.

Posted by Mishkin Berteig at 04:23 PM | |

Arg! Bitten!

Two things I realized that have almost certainly thrown off my ability to complete all the work I committed to for this iteration:

1. I'm doing a course on Thursday and Friday that I completely forgot about thus lowering my capacity by at least 28%!
2. I discovered that my "Save a Spot" feature on my agile course signup page was broken.

There are consequences to these things! Read on for a little treat...

First of all, I seriously doubt that I will complete everything I committed to in this iteration. That's not the end of the world, but it could be better. I have made some really good progress on lots of them so there is still a slim chance I will make it. One really good piece of news there is that I found out that Selenium can be used to automate remote web sites. This of course means that it should be a fairly simple matter for me to whip up a Java thick client app to submit new courses to my listing sites of interest. "Whip up" being the big spot with a question mark as to level of effort. I haven't done Java GUI development for quite a long time!

The second problem had dual consequences. First, it ate up a bunch of my time figuring out what was wrong and fixing it. PHP is okay, but combine it with AJAX stuff and debugging becomes a real pain in the arse. Let's just say I used a lot of JavaScript alert() boxes! I don't do enough of this type of development to bother figuring out how to do better debugging.... or (shudder) test-driven development. I know there are XUnit frameworks out there for JavaScript, HTML, HTTP and PHP, and the aforementioned Selenium is a great functional testing tool, but learning at least 3 or 4 XUnit frameworks for this really simple stuff I'm doing, just doesn't seem worth it. On the other hand, given that my "Save a Spot" feature has been unavailable for at least 3 weeks, it could have cost me literally many thousands of dollars !!!

Which leads nicely to my friendly offer to you, my loyal (and new) readers:

I was running a discount for readers of Agile Advice to sign up for my courses. Since my signup system wasn't working, I've decided to extend the discount until the end of January. The discount is 10%. Get it while it's hot! Even if you weren't aware of the previous discount or the fact that my signup system had failed, you can still take advantage of this great deal.

Here's the link again: Agile and Scrum Training and Certification - courses delivered by yours truly!

Posted by Mishkin Berteig at 05:47 AM | |

January 16, 2007

The Wisdom of Teams - Generalizing Specialists

I've almost finished reading The Wisdom of Teams: Creating the High-Performance Organization. I wanted to share a couple of paragraphs that give a great example of the idea of Generalizing Specialists that is such a key part of Agile Work. Here's the passage:

The [Connectors Team] made several decisions that solidified its common team approach and sense of mutual accountability. First, it set some rules. Everyone on the team had to identify two others who could serve as backups during vacation and sick days. To eradicate the attitude of "it's not my job" from the team, it was agreed that whenever anyone needed help, the person asked had to respond even if the activity was not in his or her area of expertise. And the team also agreed on a peer appraisal system that gave everyone the opportunity to evaluate everyone else and, through [their team leader], feed it back to the person being evaluated. Clear-cut rules of behavior like these are an important element of all successful teams.

Second, the team eliminated the two managerial positions that had retarded empowerment. This effectively modified the membership of the team because only one of the two managers whose jobs were eliminated chose to stay. The other believed he could not take a perceived demotion and left. By January 1991, however, the Connectors Team was a dramatically more effective group of people than it had been at its formation a year earlier.

Energy and enthusiasm reached higher levels as the team started pushing itself harder and in more innovative ways. One of the engineers, for example, decided to become completely qualified as a purchaser as well. Instead of being threatened, the purchasers on the team worked hard to teach her the basics of the job. The peer review approach worked so well that the team agreed on the additional - and, for many teams, difficult - step of directly providing each other feedback instead of relyinng on the team leader for this task.

There are several great points in the above story:

Backups: many agile methods do not explicity talk about this, but there is a need to make sure that the Truck Factor increases. A low truck factor can be a real problem and I strongly recommend that the Queue Master (Product Owner, Customer) in particular needs to have backup. As well, this hints at the idea that eventually the roles of Process Facilitator and Queue Master should eventually go away to be taken on by the team as a whole.

Skills: the example of the engineer learning to be a purchaser is a great example of a brave soul really taking to heart the idea of working for the good of the team by becoming a generalizing specialist. In my own coaching work, I have seen purely business-oriented Queue Masters become technical contributors to the team through a process of both deliberate and "accidental" learning. Every human being has an incredible capacity for learning. In a high-performance team, everyone takes that ability very seriously - to the point of it becoming a responsibility.

Rules: one of the simplest, yet most profound, ways that a group of people can start on the process to becoming a high-performance team is by working together to agree on some ground rules about team behavior. One team I worked with, among other rules, decided that no "stinky food" was allowed in the team room. The passage above notes the non-trivial rules. Both "trivial" and non-trivial rules are important to the team for two reasons:

1. Develop a set of expectations that individuals can hold each other to in order to avoid or deal with conflict.

2. Become aware of the team's power to set their own working conditions, independently of management or other "leadership".

Management: regrettably for most managers, in a high-performance team the value of formal, traditional management is much reduced. However, there is now an opportunity for two different types of work: the generalizing specialist work on the team, and the servant leader work of supporting the team. The servant leader is someone who is exceptionally good at problem solving, organizational change, and working through influence rather than authority.

---

This book is incredible. Every time I read a few pages I think "Oh! I've got to write about that on Agile Advice!" Unfortunately if I did that, I'd be in serious copyright violation. So all I can do is encourage you to read the book.

If you have already read the book, I would love to hear your impressions, particularly if there were things about it that you really didn't like. What didn't you like and why? What are the holes in it's argument?

Posted by Mishkin Berteig at 04:05 PM | |

January 15, 2007

Minor Update to Recommended Materials

I've added the Evolving Excellence blog to the Lean section of my recommended agile materials list. Again, if anyone has any suggestions for the list, please let me know in the comments here.

Posted by Mishkin Berteig at 06:07 PM | |

End of Iteration 2 ("Capacity") and Start of Iteration 3 ("Automation")

This second iteration when much better than the first. I committed to an amount of work that was much closer to my real capacity, and I stayed more focused on that work. Here are the results of my demo, retrospective and planning for Iteration 3 which I am calling "Automation" for reasons which will be described below.

Demo

I committed to the following items from my Work Queue:

I also added these in the middle of the iteration (which is really a "no-no", but I did it anyway to my regret).

What did I actually get done? Here are the stats:

For Iteration 002 - "Capacity":
# Work Queue Items At Start: 5
# Work Queue Items Completed: 3
# Tasks at Start: 32
# Tasks Remaining: 17

What is scary is that my velocity is exactly the same in terms of number of tasks: I really need to start my iterations with only 15 tasks.

Anyway, what I need to do for my next iteration is schedule my "demo" with my other stakeholder (my wife Melanie). Demo'ing to myself in the wee hours of the morning is not really practical in terms of my overall goal for this project (running my business at a sustainable pace).

Retrospective

Here are the things that went well:

- Came much closer to getting everything done that was in my iteration. This was great - I continued to use Tiddly Wiki to track my Work Queue and Tasks.
- Felt less stress. Although I still worked very hard, I was not worried nearly as much about the things still on my Work Queue that weren't in this iteration. I also decided on certain boundaries to work: generally work 4 to 6 hours during the day and another few hours after lights out (usually after 11pm).
- The prioritization worked well - didn't feel impelled to do too much that was _not_ in the iteration. Althought I did take a couple more items in, it was more because of opportunity than anything else. My brother Alexei wanted to help me with my book (for example). Next time around, perhaps I should be more explicit about negotiating with myself about taking something out of the iteration if I bring something in.

Here are the things that need improvment:

- Get even better at judging capacity and committing to an appropriate amount of work. The numbers speak loudly! This next iteration I have to limit myself to 3 items from the Work Queue and about 15 tasks. I have to remind myself that I can always bring more work in if I complete my work early and I still have time.
- Care with long term scheduling - made a mistake in my scheduling with a Client - hopefully it will be okay! This is a bit of a nit, but I need to keep my daybook up-to-date even with long-term stuff.
- Spending time with my family - e.g. playing with kids, helping around house, assisting with homeschooling. This was better than I was doing in Dec., but I need to continue to improve here. I would really like to work with Justice and Haifa on learning Chinese. We've got tons of materials to do it, just need the discipline to get through it together.

Planning

Okay, maybe I'm a glutton for punishment, but I've decided on four items from my Work Queue:

Client2 Invoice
Client2 Work
Automate Listing of Scheduled Courses on 3 Sites
Client3 Statement of Account

The key one is the automation since that will be an investment to save me time later on. In my task breakdown it looks like this (tasks with an "x" are already done from the previous iteration):

So, that's 4 items from the Work Queue and 17 tasks (the ones with "--" in front of them are sub-tasks... not sure how to handle those, but for now I'm not counting them separately.

I'm really excited about this. It sucks to see that I get so little done in a single week, but on the other hand, knowing my capacity allows me to understand just how much work I have on my plate and how badly I need two things: automation and assistance! I'm going to start with automation, but I'm also looking for assistance. The trouble is that I can't affort to hire someone on a salary... (if you know anyone who would be interested in working on commission/revenue-sharing basis, I would love to talk!).

---

One final note: I did manage to include my wife Melanie in my planning for this iteration. She seemed pleased :-)

Posted by Mishkin Berteig at 03:09 PM | |

January 12, 2007

Comparison of Project Manager and ScrumMaster

This is an interesting, short comparison of the role of the Project Manager in a traditional project setting and the ScrumMaster as a facilitator. The comparison is very light on details and so it does not present a clear picture of the motivations and advantages for choosing one scenario or the other. Rather, it compares only the surface features of the two systems.

Posted by Mishkin Berteig at 11:18 PM | |

January 09, 2007

Continuity of Teams on Agile Projects

Dave Nicolette posted a really interesting and insightful comment about the recent discussions on team commitment, flexibility and rigidity in agile methods. The focus of Dave's article is on the idea of having an established and continuously available team that grows in its abilities. The more you interrupt the team with individual or one-off tasks, the longer it takes to move through the stages of team development. Thanks Dave for the good post.

Posted by Mishkin Berteig at 06:14 PM | |

January 08, 2007

Planning Iteration 0002 "Capacity"

I've completed my iteration planning for my second iteration. As a reminder, I'm doing this because I want to be working only 50 hours per week by July 2007. My sole improvement item from last iteration was to use get better at committing to an amount of work within my capacity. Here's what I have planned:

I have included my complete list of work to be done broken down into tasks. It is anonymized:

Client1 Proposal Writing
- 1 day intermediate team course
- phone consult details
- QA/tools coaching
- email proposal
Client2 Invoice
- get template from them
- collect hours
- collect receipts
- image receipts
- currency convert receipts if needed
- type up hours
- type up receipts
- email/submit
Client2 work
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
- 4 hour task
India Training
- ping Contact1 "V"
- ping Contact2 "N"
- ping Contact3 "M"
- ping Contact4 "S"
- ping Contact5 "V"
- air reservations
- prepare visa application
- submit visa application
- hotel reservations
Client3 Statement of Account
- equipment
- invoice 1
- invoice 2

As you can see, I have committed to only five items off the Work Queue for this iteration and they add up to thirty-two tasks. This is more than I indicated last night in my retrospective results. I'm nervous about this in two ways. One, I think that I am under-committing and that I'll get into huge trouble if I don't do more than this. Two, I think that I'm over-committing and that with my brother visiting, even doing this much smaller amount of work will be challenging. Still, I have tried to make both the items from the Work Queue and the tasks smaller than in my previous iteration. I guess I'll see in a week!

Posted by Mishkin Berteig at 11:01 AM | |

First Interation Ending

My first iteration using Agile Work for my business development has come to a close. Here is what I did for a "demo" and retrospective.

Demo

This was simple. I looked at my selected Work Queue items and my tasks and check to see what I had accomplished (finished or partially finished). Here are the statistics (grim and discouraging as they are):

For Iteration 001 - "Beginnings":
# Work Queue Items At Start: 11
# Work Queue Items Completed: 2
# Tasks at Start: 43
# Tasks Remaining: 28

From these numbers, for my next iteration I should probably be hesitant about committing to any more than 2 items from the Work Queue and any more than 15 tasks.

Considering how many work hours I have in a week, 43 tasks is absolutely ridiculous... unless they are really small, which many of them weren't. For example, I had one task as "Integrate part one of Alexei's feedback into my eBook" which when I did it actually took about three hours. Its just one sample, but 3 x 43 is 129 hours and is just not possible for a single human being in 7 days.

Aside from the value-oriented items from the Work Queue, I also did the work to finish a more complete Work Queue. It now has 37 items including those which remain un-finished from this first iteration. It is poorly prioritized, but that will improve over time. As well, I suspect there are quite a few things missing that I forgetting. I should probably get my wife, Melanie, to look over it and make some suggestions. I also have some old "to do" lists for my business which might remind me of some things to add onto it near the bottom.

Retrospective

I did a little mini-retrospective to find the three things that went well this iteration, and the three things that need improvement. I also decided on a clear action item to take to try to improve my next iteration. (Another clear reason to use Card Meeting - worked great for my retrospective :-) .)

Three Things that Went Well:
- Referred to my iteration tasks frequently. I kept my TiddlyWiki up in my browser and checked it several times a day.
- Spent time with my family and friends despite huge workload. We had guests and family visiting and I got some good time in with them. I also spent a good amount of time with Melanie and my kids. I had to make a conscious effort to do this, but since this is the goal of my using Agile Work (to have a good life/work balance), I figured I might as well start making some progress on it right away!
- Had courage to do some development work which required changes to other developers' work. I ran into a problem with some of the work I am doing as a contract. I dug around and realized that any fix I made would be felt by other parts of the codebase as API's changed. I made the fix and then tracked down the dependencies and fixed everything up. Fun!

Three Things that Need Improvement:
- Pay more attention to my schedule / calendar so as to reduce problems with work/family boundaries. Still a loooooong way to go on this one!
- Spend more work time "on-task", rather than on things not on my list. I ended up doing a bunch of work stuff that wasn't in my iteration plan. Partly I did it because I got bored of what I had planned, and partly becuase I forgot to focus on my plans. It would probably help if I had a Process Facilitator breathing down my neck :-)
- Make realistic plans given my capacity for work. This is the biggie! It is going to be very hard for me to keep to a small commitment. But considering the my brother is visiting from Beijing with his wife this week and next, I really have to try to get this right.

It is that last point that I will use as the basis for my next improvement. For my next iteration planning meeting (to be held in the morning after a far-to-brief sleep), I will commit to a maximum of 3 items from the Work Queue. This may mean breaking the items down into smaller bits. I'll talk with the Queue Master (myself) tomorrow morning about it :-)

Posted by Mishkin Berteig at 04:37 AM | |

January 05, 2007

Scrum Experience Report

This is a great "how we did it" experience report about Scrum in a software environment (pdf).

Posted by Mishkin Berteig at 09:40 PM | |

January 04, 2007

Coaching and Agile Work

Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It's an interesting idea. I don't think I'm quite ready for it, but here are a few links to coaching, life improvement, and related things.

We'll start with the Wikipedia entry on Coaching. This article provides some good definitions and links to a number of articles about specific types of coaching.

Esther Derby is a person I have met a couple of times through the agile community. She has a wonderful approach to training and facilitation. This article about coaching is a simple introduction to the tools of a coach.

This is a brand new blog about lifestyles. There are only two entries so far, but both are interesting. I enjoy the style of writing which is quite personable. The author seems to be positioning the blog as a lifestyle coaching resource.

And the International Coach Federation which seems to be one of the most well-known bodies that promotes coaching as a profession.

Posted by Mishkin Berteig at 09:44 PM | |

January 03, 2007

My First Challenge

Wednesday is nearly done and I'm looking at my list of tasks and cringing! I've only done a few out of the forty for this week. What's going on?!

Well, for one thing, I'm over-committed, and I know it. This is why my goal is to eventually time-box my effort to 50 hours per week. As it is, I expect I'll have a few more short nights this week in order to get even a reasonable amount of my commitment done.

Also, I've been cherry-picking. I'm doing the easy/nice/comfortable tasks first. I'm avoiding the paperwork tasks. I'm avoiding the administrative tasks. These are the ones that I hate and I always procrastinate about. (Hmm... writing this is actually procrastination too... just a few more words and then I'll get back to work.)

Finally, I've got some obstacles which I'm not sure I will overcome this iteration. First of all, I'm spending less time on work than I anticipated. Secondly, I'm getting distracted by tasks that are not directly related to my work items, but which seem to be pre-conditions. For example, I need to do a bunch of administrative follow-up for recent courses I have delivered. Part of that is to send of images of the attendees license forms. I've got the images on the SD card in my digital camera. I've also got a lot of other images on there. So, instead of focusing purely on the task at hand, I am actually cleaning up the whole card. Which is getting rid of technical/administrative debt, but it is slowing me down. Hmm... "administrative debt"... that's gotta be a common theme for the procrastinator!

Anyone out there want to write an article for Agile Advice about administrative debt?

Posted by Mishkin Berteig at 05:16 PM | |

January 02, 2007

Top Ten Most Popular Entries from 2006

If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.

1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.

2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.

3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.

4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.

5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.

6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.

7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".

8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.

9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.

10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.

Posted by Mishkin Berteig at 06:32 PM | |

My First Iteration Planning

I've done my iteration planning for my first iteration called "Beginnings". The length of my iterations is one week (including weekends). Here is the list of backlog items that I have committed to (some detail removed):

Catch up on Scrum course follow-up work
Advertize future courses
Finish eBook 2nd Draft
- email request for feedback return
- go through feedback
- finish references
- finish diagrams
Invoice
Finalize India Trip
Interview (Tuesday)
Meet up with and co. (Sunday)
Continue development work for

I have broken all of these into tasks, but only put here the ones for finishing my eBook since the rest get into lots of private detail.

I'm currently using TiddlyWiki to track my Work Queue, my tasks and my recurring/scheduled duties. I create a new wikiword for each iteration and copy items from the Work Queue into that section. I also have a menu that has links to my daily, weekly and monthly tasks.

I'm not doing any estimation on either Work Queue items or tasks. This may become a problem, but for now I'm going to try doing the work without the estimation overhead.

I also spoke with my wife, Melanie who is my business partner about all this. She agrees that using Agile Work is a good step to take and looks forward to all the benefits of my being more organized :-)

Posted by Mishkin Berteig at 12:05 PM | |