Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

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?!

(more…)

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):

(more…)

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:

Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.

Okay… I’ll bite.

(more…)

Just a quick anecdote: one client I have has decided to use Agile Work to develop the user stories as part of a large project they are embarking upon.

(more…)

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.

(more…)

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.

(more…)

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.

(more…)

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!

(more…)

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…

(more…)

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.

I’ve worked as an agile coach on three infrastructure/maintenance projects in a row. One was a software/hardware upgrade, one was implementing agile for a defects/enhancements team, and my most recent was a data warehouse decommissioning project. In all cases, the interesting part for me was taking the basic principles of agile and applying them in a way that works when not doing new product development. Here are some lessons I’ve learned:

1. Figure out what is going to deliver value (usually cost savings). In the case of infrastructure projects, one is usually focused on cost savings. Find a way to tie your work items directly to cost savings. You need a good financial model to do this. Mary and Tom Poppendieck talk about this a little in their Lean Software Development book. In the decommissioning program, there was a very explicit dollar cost associated with disk space and cpu utilization. Every user/MB decommissioned saved a measurable amount of money. As well, it allowed us to easily prioritize our backlog.

2. Focus project/program organization more on Lean principles than agile. A good understanding of queuing theory will go a long way to helping with throughput. In a team doing defects/enhancements work, the small pieces lend themselves well to certain types of streaming through the team. Iterations are not necessary to chunck work. Instead, iterations become checkpoints solely for process reflection.

3. Technical infrastructure projects can benefit greatly from automation. Test automation including test generation can sometimes be possible. Automating parts of a regularly repeated process that is used for every work item can be extremely beneficial for increasing speed. In the case of the decommissioning effort where every database table needs to be considered separately and where they all go through the same process for decommisioning, there are many opportunities for automation. The project/program/team can invest in doing this automation to great benefit to NPV.

4. The basic axioms (We are Creators, Reality is Perceived, Change is Natural) and disciplines (Empower the Team, Amplify Learning, Eliminate Waste) still apply. Even though it is not “new” product development, the creativity of people is essential for problem solving, and finding ways to do the work faster. Stakeholders still need to have their perception of reality acknowledged, and the teams still has to do constant checking to make sure they are on track with that perception. And of course, things are always changing including priorities, our understanding of the work, resource availability etc. Having an empowered team makes short work of many obstacles, but that wouldn’t happen without an explicit acknowledgement that we have to constantly be learning and eliminating waste. Teams get better and better at these disciplines over time.

I would be very interested to hear other peoples experiences with infractructural/operational projects.

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’ve been working on developing a Agile Work Seminar to introduce teams to agile work. I’m using some Agile Work practices to develop it.

Iterative Delivery and Adaptive Planning

The seminar is going through drafts. Each draft will actually be delivered to a team. The first time through all the material was done at a small software consulting company five days ago. As a result of feedback from the people who participated, a revision will be made to the seminar… and then it will be delivered again (probably the next time will be in early September). This process allows me to refine the contents and presentation of the material.

Over time, I will be able to use Adaptive Planning to modify the contents and qualities of the seminar as circumstances change.

Test-Driven Work

I have set up criteria for the presentation in the form of an outline and learning objectives. The outline describes the major topics that must be directly covered such as the Agile Axioms or Corporate Culture. I have also set up “soft goals” such as that the seminar must include theory, history, practice and criticism of Agile Work. My first iteration met the outline tests, but did not meet the soft tests explicitly. The next version will.

Appropriate Metrics

This is an easy one: the success of this project will be its acceptance in the marketplace by having teams willing to pay the price for this seminar and then recommending it to others.

The Other Practices

Because this is essentially a one-man job, the other practices such as Self-Organizing Team and Maximize Communication are not as applicable.