Comments on: The Anatomy of an MMF http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/ Karl Scotland - Using Agile to Deliver Value Sat, 06 Mar 2010 13:47:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Ian Lynch http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/comment-page-1/#comment-8 Ian Lynch Thu, 08 Oct 2009 16:06:58 +0000 http://availagility.wordpress.com/?p=27#comment-8 Excellent post - this is the best description I have seen on this particular subject so far (and I've looked at a lot of definitions). I'm trying a KanBan approach with our IT service delivery team to smooth out the never-ending amount of BAU work they have to get through. At the same time they have to deliver new services to our development teams, which I'm using a Scrum approach for. At the moment I've got a multi-functional whitebaord with the Scrum bits in the top section and a KanBan channel underneath. Maybe I'll be brave enough to merge the two sometime ;-) Excellent post – this is the best description I have seen on this particular subject so far (and I’ve looked at a lot of definitions). I’m trying a KanBan approach with our IT service delivery team to smooth out the never-ending amount of BAU work they have to get through. At the same time they have to deliver new services to our development teams, which I’m using a Scrum approach for.
At the moment I’ve got a multi-functional whitebaord with the Scrum bits in the top section and a KanBan channel underneath. Maybe I’ll be brave enough to merge the two sometime ;-)

]]> By: Andrey http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/comment-page-1/#comment-7 Andrey Wed, 26 Aug 2009 07:55:32 +0000 http://availagility.wordpress.com/?p=27#comment-7 For my teams I split feature development to two parts: analisys and deesign goes to one sprint and the rest (build, test, release) goes into the following sprint. As a result - minimal upfront design, and maximal focus on development (in part 2 as all required details already discussed) For my teams I split feature development to two parts: analisys and deesign goes to one sprint and the rest (build, test, release) goes into the following sprint. As a result – minimal upfront design, and maximal focus on development (in part 2 as all required details already discussed)

]]> By: Kevin E. Schlabach http://availagility.co.uk/2008/07/07/the-anatomy-of-an-mmf/comment-page-1/#comment-6 Kevin E. Schlabach Mon, 07 Jul 2008 18:04:01 +0000 http://availagility.wordpress.com/?p=27#comment-6 Great article. This was a realization that we also had in my last group. Our scrum team was a cross-functional group that included the Business Analysts, UI/UX group, and QA. Immediately those matrixed resources complained of not being able to make decisions on the fly for the developers to keep coding. They wanted time to analyze, test, work. The developers wanted to ask a question and immediately have the answer. Our agile mentors taught us that in scrum there are three maturity levels... 1- hard sprint boundaries: Rest periods in between are required so that the business can digest, think, and set up the next sprint. 2- cascading sprint boundaries: The business helps the team get into a rhythm for the current sprint and then spends the last half of the sprint focusing on setting up future sprints. 3- sprint boundaries disappear, there is flow: The end of the sprint is a notification to show whatever is done and assess progress, but there is never a grand discussion about what the future holds. The business always has a detailed vision of the next 2 sprints, basic vision of the next 6, and a roadmap for the future. EVERY DAY, the team evolves this with the customer and moves forward. This is probably documented somewhere, but I can't find the source easily. It was conveyed to me from either ObjectMentor or J.B. Rainsberger in 2006 if you want to search for original source. Your images do a great job of conveying these ideas. Especially the line flow. This post should become a good resource for agile adopters seeing antipatterns. Great article. This was a realization that we also had in my last group. Our scrum team was a cross-functional group that included the Business Analysts, UI/UX group, and QA. Immediately those matrixed resources complained of not being able to make decisions on the fly for the developers to keep coding. They wanted time to analyze, test, work. The developers wanted to ask a question and immediately have the answer.

Our agile mentors taught us that in scrum there are three maturity levels…
1- hard sprint boundaries: Rest periods in between are required so that the business can digest, think, and set up the next sprint.
2- cascading sprint boundaries: The business helps the team get into a rhythm for the current sprint and then spends the last half of the sprint focusing on setting up future sprints.
3- sprint boundaries disappear, there is flow: The end of the sprint is a notification to show whatever is done and assess progress, but there is never a grand discussion about what the future holds. The business always has a detailed vision of the next 2 sprints, basic vision of the next 6, and a roadmap for the future. EVERY DAY, the team evolves this with the customer and moves forward.

This is probably documented somewhere, but I can’t find the source easily. It was conveyed to me from either ObjectMentor or J.B. Rainsberger in 2006 if you want to search for original source.

Your images do a great job of conveying these ideas. Especially the line flow. This post should become a good resource for agile adopters seeing antipatterns.

]]>