I recently had an eye-opening experience with one of my coaching clients. We were trying to find a way to reasonably have a single team work with several important stakeholders throughout an organization, each of whom had a different project for the team. Up to this point, the team has been time-slicing between these stakeholders. It is stressful work, constantly switching gears. The last time we were there, we started to look at the value the team was delivering to each group. This is where the surprise came.

Continue reading →

Early today, Pete Deemer (who presented at the May 2005 Scrum Gathering – notes from his presentation are about 3/4 of the way down the entry), posted his experiences of using the Scrum framework, with adaptations to manage his personal life. He has graciously consented to sharing his story here.

Continue reading →

Alistair Cockburn is the author of several important books in the agile software development literature including Agile Software Development and Crystal Clear : A Human-Powered Methodology for Small Teams (Agile Software Development Series). I had heard that he had a story to tell about using agile methods and principles on a house renovation project. I contacted him by email and he agreed to an email interview.

Continue reading →

Yesterday I co-facilitated a meeting with another Agile coach. Near the end of the meeting, one of the participants made a comment to the effect that I probably didn’t imagine when I was growing up that I would be a meeting facilitator. Strangely enough, in a way I did!

Continue reading →

Scrum is one of the Agile Methods that can be applied in many different fields of work. Last year, I was able to present the basic Scrum framework in a two hour session to a class of media students at Keyano College in northern Alberta. They used Scrum for their class project – a documentary video. One of the students really took to Scrum, and used it in his next class to save another group project… and get the best mark in the class! Full story follows…

Continue reading →

I posted an article on Slashdot about Microsoft, Yahoo!, and Google using agile methods for software last Sunday and it was accepted… my first one on Slashdot John Brothers did a nice summary of some of the comments.

I just found a very interesting presentation about using Agile Work to do planning for programs for people with disabilities. I didn’t understand everything in the presentation because the field is something that I am not familiar with, but it appears that someone has taken Agile from IT and applied it to social and economic development programs for disabled people.

I coached a long-running program with at times up to 8 teams, 6 of which were running as agile teams. We used a program-level status meeting daily to do “official” coordination among teams.

Early on in the program, one of the team members who was maintaining the backlog for the iteration came to me and told me that Team 4 was done their work ahead of the end of the iteration and Team 3 was struggling to get their work done in the iteration. As the Process Facilitator I got this person plus members of the two teams together to have a quick 2 minute disucussion about the problem (T4 running out of work). They quickly worked it out amongst themselves and then let the other team member know so that he could maintain the backlog by redistributing the work items and tasks. The two teams easily fixed the problem and the iteration ended successfully.

If you have worked in a highly bureaucratic environment you will know that it can be extremely difficult to adjust plans to allow this sort of on-the-fly rebalancing of work. In chaotic environments, on the other hand, it is just too difficult to see these sorts of opportunities for rebalancing in the face of constant crisis and “heroic” efforts by people on the teams. Agile Work and the process facilitator provide a balanced context in which this adaptability and self-organization can flourish.

Detailed report on applying agile practices to an architectural project: http://www.architecturalpractices.com/articles_report_001.html. An interesting excerpt:

One of the things I like about Extreme Programming (XP) is that its advocates gladly share their experiences using it. This sharing contributes in many ways to its increasing value as a project management process. We can all review, comment, and learn from each other.

With this end in mind, I offer the following report on an architectural project completed recently using XPM practices. XPM is an acronym for Extreme Project Management, my version of a set of practices based on Extreme Programming. It shows one way XP practices can be adapted to a non-software project. I hope others using or considering similar practices will find this report useful for their own endeavors.

I recently had the pleasure of coaching a team through the use of agile methods to run an IT infrastructure upgrade project. As a coach, I was there to observe and guide, to inspect and adapt. The goal of the project was to upgrade a critical piece of software that was at the end of its support life, and at the same time upgrade another piece of software to a more recent minor version. As well, new hardware would be used to run the updated software. All of this is in the context of a mission-critical system used by a major US financial services corporation. Let’s call this project the “System Renewal” project or SR.

Prior to deciding to use agile methods, the SR project was defined using two non-agile requirements documents which listed in detail what the results of the project shall and shall-not be. One was the “business” requirements and one was the “system” requirements. For example:

SR-BR 0030
Description: The SR upgrade shall maintain the same or better level of performance.
Requirement Priority: Essential
Source/References: Joe Somebody
Comments: The SR version x.01 shall be upgraded to the x.02 as a part of this project.

I worked with some key people to review the project requirements before beginning. We decided that we would hold a workshop with the team to accomplish three things: introduce the team to agile methods, provide some initial team-building opportunities, and to introduce and launch the project with the team. The team decided to use two week iterations and to shoot for a single release after four iterations. Since this was much faster than the time estimated using the old waterfall methodology, there was a large margin of safety in case a second release was necessary.

During this workshop, the team re-organized the requirements into larger “user stories” and smaller tasks. This process of re-organization allowed the team members to collaborate and to get to know the nature of the project in more depth. There was a challenge here: the work to be done had nothing to do with end users. The team along with some guidance from myself and some other coaches, decided that the “user stories” would be very similar to the top level of a traditional work breakdown structure (WBS) and the tasks would be the second level. As much as possible, dependencies among the user stories were avoided so that they could be re-organized from iteration to iteration as circumstances required.

Once the project launch workshop was complete, the team immediately moved into the first iteration planning meeting. In this meeting, the team estimated the size of the tasks and selected the user stories to be completed in the first iteration. The basic idea was to accomplish one main goal: to upgrade the software on a small number of systems (the total number of systems to be upgraded was about 15). A secondary goal was to make some progress on automating a set of system tests to include in a regression suite. Prior to this project, all the tests were done manually. No new tests would be created as the functionality of the system would not be changed.

The first iteration went fairly well: from our burndown, it appeared that not much was accomplished in the first six or seven days of the ten day iteration. The last few days were extremely productive and the main goal of the iteration was accomplished. Some progress was made on automating tests, but that was not actually finished so manual tests were used to confirm the operation of the upgraded systems. During this first iteration I acted as the team’s coach by facilitating the daily status meetings, maintaining the burndown charts, and trying to resolve impediments to the team’s progress. At this point, impediments were mostly related to the physical and techinical environment: lack of phones, whiteboards, system access, etc.

The team had a half-day iteration reflection meeting that focused on questions about estimation and tracking of task status. The customer representative accepted the work that had been completed although an actual demonstration was not performed.

The second iteration was planned as the first. A few days in, the second challenge was encountered: the existing manual testing revealed that the new version of the software had modified some interfaces with other systems. As a result, the software did not work. The team temporarily halted its work in order to examine the problem and try to determine a solution. The team quickly got in touch with the vendor of the software and a simple fix was planned that would be deployed near the end of the second iteration. Some re-organization of the iteration’s user stories and tasks was done in order to accomodate this problem. This was done in collaboration with the customer representative.

At this point it should be noted that this was a first for the organization: testing early revealed a problem that normally would be discovered right at the very end of the project rather than right at the beginning. This allowed the team to re-organize their work to remain productive and so there was no change to the schedule. This is one of the main benefits of the combination of iterative delivery and test-driven work: the early discovery of problems and the ability to work around them without substantial schedule or scope impact.

The second iteration concluded successfully. The third and fourth iterations were relatively uneventful. And the team deployed the upgraded systems more than two months early. No new software was created. The key practices used either fully or partially included: self-steering team, iterative delivery, adaptive planning, test-driven work, and maximize communication (use of both co-located team and information radiators). The question of appropriate metrics did not come up except insofar as the team was substantially exempted from the corporate procedural compliance measurements, and was operating in an environment where time-to-market was considered the most important factor.

The Roots of Lean [PDF] is a fabulous history of how lean principles and practices originated in WWI shipyards in the United States, grew through WWII, were transferred to the Japanese and then lost in the United States.

So it turns out, in our house, our planning horizon is about one day. Therefore, our one-week iterations were consistently having problems: lots of dropped tasks, but still very busy. As well, the effort of trying to maintain a huge backlog revealed some environmental constraints: we spend a lot of time on yard work, for example.

As a result of these two discoveries, we have moved firmly to day-long iterations. Each day at the beginning of the day we take between 5 and 15 minutes to plan out our days TODO list. Melanie and I each have separate lists. We coordinate our lists throught the master household backlog. Melanie does very well in choosing a TODO list that she can accomplish in a single day, partly because she uses her daily planner to schedule things (estimation). I tend to have a lot of small things fall off the end of my list at the end of the day, mostly because I do not do any sort of estimation or scheduling. I may start.

In my previous entry about Agile Household Management, I mentioned the use of a corkboard. That is no longer being used for tasks. It is now being used for general notices and lists relating to larger tasks. For example, a list of items we need to purchase from Ikea, and a list of repairs we need to hire a plumber to do. My iteration (daily) TODO list is now a piece of paper at the side of my desk.