Posts Tagged ‘Learning’

Agile Benefits: Five Essential Reasons to Try Agile

Monday, September 24th, 2007

Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:

Rapid Learning - disciplined application of the scientific method to explore the best ways to deliver valuable results.

Early Return on Investment - opportunity to use the results of work starting with the work delivered at the end of the first iteration.

Satisfied Stakeholders - engagement in the process in a way that allows meaningful contributions from all stakeholders.

Increased Control - mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.

Responsiveness to Change - processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.

These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.

What are some of the other benefits of agile?

Agile Retrospectives and the Plan of Action

Thursday, August 30th, 2007

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.

Strategic Plan

Thursday, February 22nd, 2007

Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.

Learning Vocabularies

Tuesday, February 20th, 2007

Last April I wrote a brief article showing the relationship between five different learning models. I’ve discovered two more for your edification:

The Shewhart (Deming) Cycle of Plan, Do, Check, Act

and the Six Sigma DMAIC cycle: Define, Measure, Analyze, Improve, Control

I find it so interesting that the same basic ideas have circulated (no pun intended) in so many different disciplines for so many years. Does anyone know if there is a good description of a universal / abstract cycle of which all the others could reasonably be considered instances?

Cancelled Iteration

Monday, January 22nd, 2007

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

(more…)

First Interation Ending

Monday, January 8th, 2007

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.

(more…)

Coaching and Agile Work

Thursday, January 4th, 2007

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.

(more…)

My First Challenge

Wednesday, January 3rd, 2007

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

How to Avoid Context Switching

Friday, November 24th, 2006

Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.

(more…)

The Case for Context Switching

Wednesday, November 15th, 2006

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

Process Facilitator “Smells”

Tuesday, November 14th, 2006

I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.

(more…)

Learning Circle - Interview with Garry Berteig (Updated)

Tuesday, September 19th, 2006

The Learning Circle is a graphical description of the cyclical stages of learning and the qualities that are necessaary to go from one stage to the next. This method has been developed by the artist and teacher Garry Berteig as part of the application of Agile Work to his instruction. What follows is a short iterview with Garry after he attended one of my Agile Project Management / ScrumMaster Certification courses.

The Learning Circle

(more…)

Agile Team Launch - a Howto Guide for Managers

Monday, September 11th, 2006

Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.

(more…)

The Seven Core Practices of Agile Work

Tuesday, September 5th, 2006

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

(more…)

Agile Project Engagement Roadmap

Friday, June 30th, 2006

(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)

We recently had the disconcerting experience of having a client cancel our engagement because they’d felt that we weren’t being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.

(more…)