Date: 2008.05.31 | Category: Agile, Conferences | Response: 0
I got to Coach Camp last night and met a lot of new people. There are about 50 people here from all over the US, Canada, UK, Sweden, Ukraine and even India. Friday night was for meeting people, introductions and Lightning Talks. About 20 people talked for three minutes each and I described my Refactoring Challenge idea (more on that another day).
Here are the highlights I jotted down that spoke to me:
- NLP (nuerolinguistic programming) as a tool to understand other people’s frame of reference and overcoming resistence.
- Become a learner again so we (coaches) can learn and appreciate how it feels to be a beginners, struggle and be coached.
- Refactoring Challenge (me)
- We are here to create teams of problem solvers, not people who follow our directions.
- Discover the common thread (music, sports, etc.) among team members to unlock their potential.
- When was the last time we (the Agile community) learned a new trick? Too much effort is being spent “drawing lines” around the “process box” of what is Agile. We need to teach people how to fish.
- What makes the process of Agile agile?
- Agile INJFPA (Is Not Just For Programmers Anymore).
- Use affinity grouping to help people get over the initial struggle in Planning Poker over “what is a point?”
- What is the goal of agile? What is the objective? Agile is to create better business value in shorter time.
- Published books and case studies are the equivalents of “concrete code examples” for the Agile API. Cut-n-paste from the books or case studies and then evolve your own process.
- We need to coach managers on Agile as well as the teams. Help managers by creating a backlog of things managers can do to help the teams.
As for luminaries, Ron Jefferies, Chet Hendrickson, Bill Wake, William Petri, Brian Merrik, Henrick ??? and Deb Hartman (conference organizer) are here. Of course, the other people are just as interesting to speak with and have very interesting persepctives.
After the Lightning Talks, we went to get some food and beer in downtown Ann Arbor (a very pretty city center with the same brick architecture found in the San Diego Gaslamp). There were SO many interesting conversations, that I spent most of my time listening and there is no way I could capture all of them. The one thing I did learn is that Agile is really beginning to get traction in big corporations. At least half the people attending are from large institutions (banks, government, large health care companies, etc.) and they are carrying the Agile torch looking for ways to transform their departments.
Date: 2008.05.29 | Category: Agile, Scrum, Team, Tools | Response: 0
Just wanted to post some pictures (sorry, they didn’t make the move – 01/31/2009 CEN) of the Team’s task board as yet another example for people who are curious about how this looks and feels. It is a very, low tech Team tool for talking about the work they are doing. We have three states for work: Not Started, In Process and Done.
Each task is on a purple post-it note, has the person’s initials so we know who the owner is and has a size: S (0.5 days), M (1 day), L (2 days). The sizing idea came from the Team because there was resistance to estimating tasks in hours. So, now we estimate in task points and that information feeds the Burndown chart which you see in that section. We also have a section for Obstacles, which go on their own post-it notes and a section for items that get Deferred, or dropped, from the Sprint. It is all very elegant and easy to use.
I am really pleased with this experiment I am running for this Sprint. One of the Team members said (without prompting), “I really like the task board. It makes everything visible and real.” You simply cannot pay people to say that!
Date: 2008.05.22 | Category: Agile, Conferences | Response: 0
It’s kinda like going to Hollywood, but for the ubergeeks. When I mentioned this at home, not a single person cared (that much). All they wanted to know is what would they be doing while I was at the conference. It’s in Ann Arbor, MI – so not that much.
A few weeks back, I saw a throw away posting on one of the Agile usergroups and investigated it. Agile Coach Camp is being held on May 31st to June 1st and follows the mold of the various Code Camps, the attendees create and present the content (it will be run as an Open Space). At this point in my career, attending a conference about best practices, new technologies or general Agile development practices is not doing that much for me. I need to be talking with my peers who are doing this work each-and-everyday. I want to learn about what sorts of challenges they are facing and any special “tricks” they might have. Most of all I want to talk with people who really get this stuff and are excited by it.
I will do my best to blog about the different sessions I attend, so my readers (whoever you are) can learn a new thing or two. I will try to take some pictures of the people I meet as well. Also, if I have something to present, I will be try to preview the ideas here first and\or expand upon them more later.
Date: 2008.05.09 | Category: Communication, Scrum | Response: 0
One of the more important things I learned in graduate school that applies to my work in the software industry is precision. When I talk about precision, I mean being very clear about what you are claiming (or not claiming).
Earlier today, I read this question at the Scrum Development group which illustrates why it is important to be precise in your language:
“Can the product owner post tasks that are poorly defined and require the team to take the tasks?”
My first response was to answer the question, but then it really was not clear if the poster was asking if it was allowable for the Product Owner to put items into the Sprint Backlog or the Product Backlog. Where the imprecision started was on the terms “task” and “require”.
In Scrum, tasks are identified by the Team in the Sprint Backlog. In that context, Scrum is very clear; the Product Owner cannot post tasks into the Sprint Backlog and “require” the Team to do anything. The Sprint Backlog is owned completely by the Team (because they are self-managing) and they have the final say of what goes in and what goes out. The Product Owner might suggest tasks and may even have a list of things they think the Team might need to do, but in the end, it is the Team’s responsibility to fill the Sprint Backlog with tasks that complete the Product Owner’s goals for that Sprint.
What confused me next were the words “tasks that are poorly defined”. Could the poster be referring to the Product Backlog? In that context, the Product Owner does have the authority to have items “poorly defined” (it is their Backlog, so it can be in any form they want) and can ask the Team to accept these loosely defined items into the Sprint. However, like most everything I have studied about Agile software development, there is a balance here. In exchange for allowing the Product Owner to have things loosely defined, the Team must accept the responsibility to ask enough questions to understand the exit criteria, the requirements and gather enough information to make a commitment. If the Product Owner cannot provide enough detail at Sprint Planning to satisfy these three conditions, then the Team can turn back the request.
“Can the product owner post tasks that are poorly defined into the Sprint Backlog and require the team to take the tasks?”
If the original poster had written something more precise (with the correct application of Scrum vocabulary) we could have saved so much time in learning about the problem.
“Can the product owner post tasks that are poorly defined into the Product Backlog and require the team to take these as tasks into the Sprint Backlog?“
The extra precision describe different problems faced by this Team and the remedy (if one needs to be applied) may be quite different.
Date: 2008.05.02 | Category: Agile, Extreme Programming, Rugby, Tools | Response: 0
Just this week I participated in a WebExchange of yet another “enterprise Scum tool” with all the cool database, web access and reporting features you could dream of. Apart from some serious misunderstandings of just what Scrum is and how it can be made scalable, the tool was OK. It had some nice features, did some interesting things with traceability (oddly enough ignored tests), but it was not a tool I would recommend for any Scrum team.
Over the years I have worked with teams, I have tended to avoid these electronic tools since they do not support the dynamic I am trying to foster when I work with people. I want people to talk face-to-face with each other and I want them defer complexity and detail until the last responsible moment, i.e. the Lean concept “decide as late as possible”. I want to encourage the growth and development of collaborative, cross-functional, self-organizing teams. IMO, these tools hinder the creation of that dynamic more than help. [Please note, I am ONLY referring to Teams and Product Owners that are co-located in the same work location and same time zone. I am not so arrogant to say electronic tools are not applicable for geographically distributed teams across multiple time zones. Distributed teams need different tools.] For the longest time, I could not articulate why, well now I know.
These electronic tools are management tools for reporting up, they are not tools the team needs to create a collaborative, cross-functional, self-organizing team. There is no reason why a co-located Team of 8 to 10 people should be using something other than task board and Excel files to track their own progress, especially when they are starting out. The unfamiliarity of self-organization and collaboration requires simple of the tools that encourage communication. There is only so much you can write on a stickie note or in a field in Excel. To be successful, you have to get out of your seat and talk to someone.
With so many of these electronic tools, it is so tempting (and so easy) to fall back on “bad” habits of command-and-control. These enterprise tools with their workflows, forms to fill out, work groups, web services and clean looking graphs we can email with a click of a button, encourage us forget that we are trying to become more collaborative, cross-function and self-organizing. We sometimes get so wrapped up in giving the tool the data it wants and follow the process IT lays out for us, we forget the reasons why we wanted to be more Agile. IMO, the only things these tools buy us is the ability to cleanly report up to management. So why does the Team allow a management tool to govern their own Team interactions?
Before you shut off your brain and dismiss my criticism of these tools as “just another Agile zealot”, I want to be very clear I believe Teams MUST be visible and accountable to management. Teams MUST report their status to management with the metrics they expect in ways they can understand. Not to do this is not only is this disrespectful, but the Team is in for a surprise when management kills their Agile initiative because they are viewed as “rogue”. Providing visibility and accountability is where I can see how these enterprise tools can be valuable to the enterprise, but filling the tool with the information it demands is not the responsibility of the Team. In my ideal world, the Team should not even know the tool exists – you basically only need as many licenses as you have Teams and Product Owners. It is the ScrumMaster’s (or the XP Coach’s) responsibility to translate the Team’s metrics into the tools format since their role is to provide the “management deflection shield”. No one else should be entering information into the tool but the ScrumMasters (or Coaches) and the Product Owners (or Customers).
