Comments on: An Agile Workflow http://availagility.co.uk/2009/02/25/an-agile-workflow/?utm_source=rss&utm_medium=rss&utm_campaign=an-agile-workflow Karl Scotland - Using Agile to Deliver Value Mon, 14 May 2012 03:22:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Jonas http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-93383 Jonas Thu, 02 Feb 2012 22:42:13 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-93383 Everybody does exactly these steps for each story in SCRUM in the "In Progress" stage Analysis –> Build –> Test –> Release Everybody does exactly these steps for each story in SCRUM in the “In Progress” stage
Analysis –> Build –> Test –> Release

]]> By: lepine kong http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-2445 lepine kong Thu, 28 Jan 2010 00:52:13 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-2445 For me there is no problem at all with Analysis –> Build –> Test –> Release because the difference between Waterfall and Agile is a difference of SCALE in the sense of FRACTAL THEORY. Waterfall is a single linear scale, Agile is a NON-LINEAR Fractal Scale where the 4 steps above are repeated in an improvement spiral. In fact this 4 steps come from the PDCA of Deming, the founder of Quality who taught it to the Japenese, which comes itself comes Walter Shewhart which comes itself from the scientific principle of Aristotle circle :) For me there is no problem at all with
Analysis –> Build –> Test –> Release

because the difference between Waterfall and Agile is a difference of SCALE in the sense of FRACTAL THEORY.

Waterfall is a single linear scale, Agile is a NON-LINEAR Fractal Scale where the 4 steps above are repeated in an improvement spiral.

In fact this 4 steps come from the PDCA of Deming, the founder of Quality who taught it to the Japenese, which comes itself comes Walter Shewhart which comes itself from the scientific principle of Aristotle circle :)

]]> By: Dave Nicolette http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-87 Dave Nicolette Tue, 07 Apr 2009 23:19:56 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-87 I find the debate about this rather puzzling. Any process that supports the values and principles expressed in the Agile Manifesto can be deemed an "agile" process. What is there in the "kanban" model that conflicts with agile values and principles? I find the debate about this rather puzzling. Any process that supports the values and principles expressed in the Agile Manifesto can be deemed an “agile” process. What is there in the “kanban” model that conflicts with agile values and principles?

]]> By: Vasco Duarte http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-86 Vasco Duarte Sat, 07 Mar 2009 06:59:37 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-86 Karl, Why do you bother? ;) The fact is that a Kanban sequence (one feature from backlog to release) is about such a short time frame (a day, maybe 2/3?) that the sequence you use is going to be very similar to analysis, design, implement, test, implement. Of course it is not linear, why do we even discuss that? But because the feature is now assigned to a small group of people they will know what to do, even if that means "breaking the sequence". Much of this discussion is about people getting hung up on the "tool" (the steps on the board) and completely missing the point of the process itself (reduce inventory!). I would just start with the simple process description (to do -> in progress -> done) and forget about this discussion. When working with a team they can agree exactly what steps they need, without the whole blogosphere lecturing them! :) Karl,

Why do you bother? ;) The fact is that a Kanban sequence (one feature from backlog to release) is about such a short time frame (a day, maybe 2/3?) that the sequence you use is going to be very similar to analysis, design, implement, test, implement. Of course it is not linear, why do we even discuss that? But because the feature is now assigned to a small group of people they will know what to do, even if that means “breaking the sequence”.

Much of this discussion is about people getting hung up on the “tool” (the steps on the board) and completely missing the point of the process itself (reduce inventory!).

I would just start with the simple process description (to do -> in progress -> done) and forget about this discussion. When working with a team they can agree exactly what steps they need, without the whole blogosphere lecturing them! :)

]]> By: ddraperuk http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-85 ddraperuk Thu, 26 Feb 2009 18:10:32 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-85 Karl, As I understand it the states you have described relate to the states a feature goes through, not necessarily people who hand-off work. Kanban does not preclude swarming. I've added some detail on the workflow I am using with a SCRUM team here http://www.agiledesign.co.uk/scrum/agile-workflow/ Karl,
As I understand it the states you have described relate to the states a feature goes through, not necessarily people who hand-off work. Kanban does not preclude swarming.
I’ve added some detail on the workflow I am using with a SCRUM team here http://www.agiledesign.co.uk/scrum/agile-workflow/

]]> By: Agile workflow | Agile Design http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-84 Agile workflow | Agile Design Thu, 26 Feb 2009 18:05:25 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-84 [...] Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board. So for each feature, one by one, we end up with: [...] [...] Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board. So for each feature, one by one, we end up with: [...]

]]> By: Dew Drop - February 26, 2009 | Alvin Ashcraft's Morning Dew http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-83 Dew Drop - February 26, 2009 | Alvin Ashcraft's Morning Dew Thu, 26 Feb 2009 14:02:44 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-83 [...] An Agile Workflow (Karl Scotland) [...] [...] An Agile Workflow (Karl Scotland) [...]

]]> By: Keith Braitwaite http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-82 Keith Braitwaite Thu, 26 Feb 2009 07:24:36 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-82 "Does that still seem like a waterfall process?" Why, yes, it absolutely does. I suggest that for as long as Kanban-like processes are described in terms (and with pictures) that not only allow for but positively afford a linear, gates-and-handoffs, no planned re-work interpretation a great many people are going to be resistant to it. “Does that still seem like a waterfall process?”

Why, yes, it absolutely does.

I suggest that for as long as Kanban-like processes are described in terms (and with pictures) that not only allow for but positively afford a linear, gates-and-handoffs, no planned re-work interpretation a great many people are going to be resistant to it.

]]> By: Robin Dymond http://availagility.co.uk/2009/02/25/an-agile-workflow/comment-page-1/#comment-81 Robin Dymond Thu, 26 Feb 2009 01:37:49 +0000 http://availagility.wordpress.com/2009/02/25/an-agile-workflow/#comment-81 Hi Karl, So is this post about renaming steps in a process? Is this the root of the problem that we face? That the labels drive the wrong behaviors? I think the words you have chosen are interesting, I just don't think the debate is about words. David Anderson made very strong statements at Agile 2008 about his philosophy of supporting the traditional activity based model of managing and operating IT, and that hand offs between groups are both acceptable and inevitable. My concern is that the speed and quality of output of the process is controlled by lossy information handoffs between each step in the process. Various approaches are being tried (ie. pairing adjacent groups) to deal with this problem. The better approach is to simplify the process by using co-located cross functional teams, pull testing to the front of the process, and make everyone responsible for quality, including the customer. In this case I would use different words, because the steps of the process are far less important than how the team works together to deliver the features. Regards, Robin Dymond. Hi Karl,
So is this post about renaming steps in a process? Is this the root of the problem that we face? That the labels drive the wrong behaviors? I think the words you have chosen are interesting, I just don’t think the debate is about words.

David Anderson made very strong statements at Agile 2008 about his philosophy of supporting the traditional activity based model of managing and operating IT, and that hand offs between groups are both acceptable and inevitable. My concern is that the speed and quality of output of the process is controlled by lossy information handoffs between each step in the process. Various approaches are being tried (ie. pairing adjacent groups) to deal with this problem. The better approach is to simplify the process by using co-located cross functional teams, pull testing to the front of the process, and make everyone responsible for quality, including the customer. In this case I would use different words, because the steps of the process are far less important than how the team works together to deliver the features.

Regards,
Robin Dymond.

]]>