Last week, my wife and I put down new mulch in the natural areas of our yard. As I was loading cart after cart of mulch to lug across the yard, I started thinking we might not be able to get all 8 yards of mulch spread that day. I really wanted to get this done so I didn't have to worry about it over the weekend. Looking at the pile, it did not seem to be getting any smaller and it was approaching lunch time. A thought came to mind: how can I make this into a smaller task that I could accomplish in a few hours instead of looking at the entire pile over the period of a day? What if I worked to split the mulch in the middle into two separate piles (dividing and conquering)? That could make the task interesting (kids might like it) and give me a smaller goal to attempt to reach.

How many times do I find myself asking that question? How can I break task X down into something smaller so I can feel like I am accomplishing something? My understanding of goal setting comes from studying of GTD, Agile development processes and a history of playing basketball. GTD and Agile development have taught this as some of their core concepts (if I understand them correctly). The further along I got playing basketball, I found we were always breaking down plays or watching videos in smaller chunks to analyze how we could get better. The task of breaking down issues into smaller tasks seems to be fairly important and a skill that I frequently find myself using (as long as I don't over plan).

Back to my pile of mulch. I was able to get it divided into two halves.

From there, I proceeded to break it into smaller tasks. I focused on the smaller half first and then started breaking off the corners of the larger half that was left. It sure did help and we were able to get all of the mulch spread by the end of the day (YAY!). Once again, setting smaller goals, although they may not have made a difference in the speed that I got my part done, they did help me focus on small units of work that I needed to get done.

While playing sports (namely basketball) for a number of years, I played on a number of different teams and had a number of different coaches (2 main coaches in high school and college). Looking back, it was very interesting to see the different styles in coaches and players. I was pretty lucky for the most part, the majority of my experiences were on teams that understood the concept of "team play".

One thing I didn't completely realize was how important the coach's leadership was and the values they instilled. When a player first joined the team, they wouldn't completely fit in or at the very least they would struggle a litte. Having these core values, provided by the coach originally and promoted by upperclassmen, the freshmen (or new transfer) has a base to build from. As they grow as a player and person (going from freshman to sophomore and so on), their playing skills would develop, but they would also continue to 'buy-in' (or gel) to the team values. Of course, this happened at a different pace for everyone depending on the player.

I am starting to see that again in the agile software development. As teams shift and grow, you go through this process over and over. I think it is important to have those underlying values, but the overall appearance of the team will reflect the current players. I am learning there is a delicate balance between emphasizing values, letting the team gel and using the strengths of the new players. If too much emphasis is placed on values, it suppresses the strengths of new players. If the values are shifted too much, you lose the history that has brought you success in the past. I feel like it is somewhere in the middle that allows your team to gel the quickest depending on the number of returning starters you have from the previous season (or project).

Last night, Esther Derby came and talked to the local Agile RTP group. Her talk was called "What's a Manager To Do?". With agile teams being self-organizing, what is the manager's role in this situation? An agile team can start to take on some of the items that a manager used to do. Task assignment and tracking are two items that seemed like good candidates for the team to take over. There are some things that require a manager that aren't going away. HR related issues and budgeting are two examples.
There are several grey areas that could go either way depending on the maturity and organization of the agile team. For instance, conflict/friction issues might need to be handled by a manager, but for the health of the team, might be best addressed at the team or individual level. If someone reports to their manager that someone on the team isn't performing and the manager goes to this individual and says 'I heard you weren't performing (doing or not doing X)', this isn't going to be good for the team. Who can they trust on the team? If the team has been letting an issue fester for a long time (not addressing the issue with the other team member), this can cause even more issues. From Esther's experience, it sounded like 1) openness between the team members is critical and 2) the manager should really fine tune their observation skills so they can catch issues as they come up.

Another grey area is the decision making process. If the team assumes they have the right to make decision X and the manager vetoes this right, that can really discourage the team. It can also work the other way where the team is assuming the manager is going to make a decision, but the manager is expecting that from the team. Esther's suggestion was to layout a decision matrix that helps clarify who is responsible for making decisions. Although it wasn't directly said (or I didn't hear), I suppose this helps with the transparency of the team which is a common theme in the agile space.

An underlying theme, from my perspective, was the reference to teams, in particular team sports, where it truly is a group of players working together (her example was basketball). Many of the agile concepts that appeal to me came from my experiences playing basketball. I am frequently reminded of how my experiences playing on a team were so similar to being on a team at work. Everything from how to interact with others to keeping a goal in mind and staying on target.

Overall, the talk was good and reaffirmed some of the ideas we were already using. Clarifying decision making, dealing with friction and the "team" concept were some of the key points I am taking away from last night.

Do you remember in school when you used to have the word problems in math? You had to read a paragraph and then pick it apart for certain key words. You might look for "of*" or "times" to indicate multiplication or "more than" for addition. I remembering doing fairly well at these *word problems (not that I enjoyed them), but I didn't really understand how much these were going to apply to me in the future.

It turns out that in the technical field (and probably others) I am constantly dealing with word problems. There are 2 ways that I see them represented:

1. in general email sent each day (applies to non-technical as well)
2. in specification, requirement or similar documents