Why flashy xm fails - Revision history

Vannmi at 16:06, 31 July 2012

2012-07-31T16:06:42Z

← Older revision		Revision as of 16:06, 31 July 2012
Line 67:		Line 67:
	Instead of long term plans, state goals. That is: define what you want, not the how. Let Agile iterations determine the how and get you where you want to go. If you have a timeline, to make sure it's met, let your Scrum tool measure the velocity of your teams, and look at the burndown chart for a time estimate. If things are moving too slowly for the timeline, add more team members (or train them); that's the way to increase velocity. Let budgets evolve over time as teams learn what's involved.		Instead of long term plans, state goals. That is: define what you want, not the how. Let Agile iterations determine the how and get you where you want to go. If you have a timeline, to make sure it's met, let your Scrum tool measure the velocity of your teams, and look at the burndown chart for a time estimate. If things are moving too slowly for the timeline, add more team members (or train them); that's the way to increase velocity. Let budgets evolve over time as teams learn what's involved.

	But don't worry about the how. Eschew step-by-step procedures for "success criteria." I.e., "each GVCS should be cheaper to make, easier to repair, and en par with its proprietary industrial equivalent." This implies industry research will be done. It means that each task, of each iteration, is measured against these success criteria. Each step of the way it'll be tested to be cheap to make, easy to repair, and high performing. Separating the what you want, from the how, eliminates the need to demand adherence to step-by-step plans that no one here ever follows anyway. Trust your team to meet the success criteria, and then evaluate their results on a weekly basis (at the end of each iteration,) instead of falling into the trap of Waterfall ~~(step~~-~~by-step)~~ development.		But don't worry about the how. Eschew step-by-step procedures for "success criteria." I.e., "each GVCS should be cheaper to make, easier to repair, and en par with its proprietary industrial equivalent." This implies industry research will be done. It means that each task, of each iteration, is measured against these success criteria. Each step of the way it'll be tested to be cheap to make, easy to repair, and high performing. Separating the what you want, from the how, eliminates the need to demand adherence to step-by-step plans that no one here ever follows anyway. Trust your team to meet the success criteria, and then evaluate their results on a weekly basis (at the end of each iteration,) instead of falling into the trap of Waterfall plan-driven development.

	Let policies naturally evolve (using consensus, preferably). As a leader, as long as the key values of FeF/OSE are agreed upon by volunteers, trust the wisdom of the group to figure out how values manifest into policies over time. Don't issue royal decrees. Be Agile, and let manifestation of values evolve over time.		Let policies naturally evolve (using consensus, preferably). As a leader, as long as the key values of FeF/OSE are agreed upon by volunteers, trust the wisdom of the group to figure out how values manifest into policies over time. Don't issue royal decrees. Be Agile, and let manifestation of values evolve over time.

Vannmi at 16:04, 31 July 2012

2012-07-31T16:04:09Z

← Older revision		Revision as of 16:04, 31 July 2012
Line 58:		Line 58:
	For Marcin's meta project page (which can also be geared for the public, or we can have a separate one), we can give him whatever he wants. But I suggest automatically pulling blog entries from each wiki, and giving him a status log pulled from all Scrum projects, using the Scrumy API. It would be updated instantly whenever any task in any Scrum project is moved to Done (or we can configure it to be updated whenever a task changes its status at all).		For Marcin's meta project page (which can also be geared for the public, or we can have a separate one), we can give him whatever he wants. But I suggest automatically pulling blog entries from each wiki, and giving him a status log pulled from all Scrum projects, using the Scrumy API. It would be updated instantly whenever any task in any Scrum project is moved to Done (or we can configure it to be updated whenever a task changes its status at all).

	People starting new scrum projects can be referred to a template of user stories, success criteria, and team building tips from a newly reconstructed list built out of the one in the XP Control Panel. This will be 100% scalable, 100% Agile, and would make a heck of a lot more sense than the convoluted half Agile/half Waterfall, Scrum-~~butt~~ we have now.		People starting new scrum projects can be referred to a template of user stories, success criteria, and team building tips from a newly reconstructed list built out of the one in the XP Control Panel. This will be 100% scalable, 100% Agile, and would make a heck of a lot more sense than the convoluted half Agile/half Waterfall, "Scrum-but" we have now.

Marcin at 15:56, 31 July 2012

2012-07-31T15:56:35Z

← Older revision		Revision as of 15:56, 31 July 2012
Line 1:		Line 1:
			See also [[Flashy XM Specification]]


	'''We're Not XM'''		'''We're Not XM'''

Vannmi at 15:56, 31 July 2012

2012-07-31T15:56:12Z

← Older revision		Revision as of 15:56, 31 July 2012
Line 23:		Line 23:
	What is gained in using a term that's so misleading? Why not use an accurate phase that actually indicates what we're doing: "crowdsourcing a solution"		What is gained in using a term that's so misleading? Why not use an accurate phase that actually indicates what we're doing: "crowdsourcing a solution"

	And, as with "XM", even ~~this~~ more accurate phrase need not be part of our name, given how rarely it's used.		And, as with "XM", even the more accurate phrase "crowdsource design" need not be part of our name, given how rarely it's used.

	'''Scrum'''		'''Scrum'''
Line 62:		Line 62:
	Whenever a longterm strategic plan is written, or a policy decreed, or a director appointed, Martin Fowler rolls his eyes, since Agile is being violated. Agile is 40% faster than Waterfall --without counting compound gains-- so why go waterfall? Wikispeed's 100mpg car was not built in 3 months using Waterfall development!		Whenever a longterm strategic plan is written, or a policy decreed, or a director appointed, Martin Fowler rolls his eyes, since Agile is being violated. Agile is 40% faster than Waterfall --without counting compound gains-- so why go waterfall? Wikispeed's 100mpg car was not built in 3 months using Waterfall development!

	Instead of long term plans, state goals. That is: define what you want, not the how. Let Agile iterations determine the how and get you where you want to go. If you have a timeline, to make sure it's ~~done~~, let your Scrum tool measure the velocity of your teams, and look ~~see~~ the burndown chart for a time estimate. If things are moving too slowly for the timeline, add more team members (or train them); that's the way to increase velocity. Let budgets evolve over time as teams learn what's involved.		Instead of long term plans, state goals. That is: define what you want, not the how. Let Agile iterations determine the how and get you where you want to go. If you have a timeline, to make sure it's met, let your Scrum tool measure the velocity of your teams, and look at the burndown chart for a time estimate. If things are moving too slowly for the timeline, add more team members (or train them); that's the way to increase velocity. Let budgets evolve over time as teams learn what's involved.

	But don't worry about the how. Eschew step-by-step procedures for "success criteria." I.e., "each GVCS should be cheaper to make, easier to repair, and en par with its proprietary industrial equivalent." This implies industry research will be done. It means that each task, of each iteration, is measured against these success criteria. Each step of the way it'll be tested to be cheap to make, easy to repair, and high performing. Separating the what you want, from the how, eliminates the need to demand adherence to step-by-step plans that no one here ever follows anyway. Trust your team to meet the success criteria, and then evaluate their results on a weekly basis (at the end of each iteration,) instead of falling into the trap of Waterfall (step-by-step) development.		But don't worry about the how. Eschew step-by-step procedures for "success criteria." I.e., "each GVCS should be cheaper to make, easier to repair, and en par with its proprietary industrial equivalent." This implies industry research will be done. It means that each task, of each iteration, is measured against these success criteria. Each step of the way it'll be tested to be cheap to make, easy to repair, and high performing. Separating the what you want, from the how, eliminates the need to demand adherence to step-by-step plans that no one here ever follows anyway. Trust your team to meet the success criteria, and then evaluate their results on a weekly basis (at the end of each iteration,) instead of falling into the trap of Waterfall (step-by-step) development.

Vannmi at 15:44, 31 July 2012

2012-07-31T15:44:32Z

← Older revision		Revision as of 15:44, 31 July 2012
Line 1:		Line 1:
	~~Flashy XM: Critique~~		'''We're Not XM'''

	We're Not XM

	First of all, we're not practicing Extreme Manufacturing.		First of all, we're not practicing Extreme Manufacturing.
Line 15:		Line 13:
	But regardless, even if we were swarming and pairing, why elevate these two comparatively minor practices by including "XM" in our name?		But regardless, even if we were swarming and pairing, why elevate these two comparatively minor practices by including "XM" in our name?

	We're Not Doing Flash Mobs Either		'''We're Not Doing Flash Mobs Either'''

	Secondly, we're not organizing flash mobs, but crowdsourcing to unblock on tasks.		Secondly, we're not organizing flash mobs, but crowdsourcing to unblock on tasks.
Line 27:		Line 25:
	And, as with "XM", even this more accurate phrase need not be part of our name, given how rarely it's used.		And, as with "XM", even this more accurate phrase need not be part of our name, given how rarely it's used.

	Scrum		'''Scrum'''

	Until recently, we've been using Scrum entirely incorrectly: we haven't been holding (time boxed) sprints, much less holding the Sprint Planning Meetings, Scrum Review Meetings, or doing Stakeholder demonstrations. About the only thing we have been doing is calling what we do Scrum! I've elaborated on Scrum on my blog and given a few presentations to the volunteers at FeF, so won't go into more detail here.		Until recently, we've been using Scrum entirely incorrectly: we haven't been holding (time boxed) sprints, much less holding the Sprint Planning Meetings, Scrum Review Meetings, or doing Stakeholder demonstrations. About the only thing we have been doing is calling what we do Scrum! I've elaborated on Scrum on my blog and given a few presentations to the volunteers at FeF, so won't go into more detail here.
Line 35:		Line 33:
	Referring now to our use of Scrumy --the online tool we use for tracking our sprints-- we've been misusing that, too. User stories for a project should be listed vertically, not team member names. Therefore, we'd need a unique Scrumy project for each real world project. Fortunately, several people here have begun to do this for the projects they're leading.		Referring now to our use of Scrumy --the online tool we use for tracking our sprints-- we've been misusing that, too. User stories for a project should be listed vertically, not team member names. Therefore, we'd need a unique Scrumy project for each real world project. Fortunately, several people here have begun to do this for the projects they're leading.

	Contract First Design		'''Contract First Design'''

	~~We want our~~ tool designs to be modular and have interchangeable parts. This allows us to use Contract First Design. CFD works by working to define the interfaces between components, to let engineers run wild with ideas for each component, as long as they work with the constraints of the interface requirements. For example, for the Microtrac, Graham could choose mount points for the tracks on the frame, define how much a load the tracks can support, how fast, where the hydraulic hoses will attach, and the bounding box of the tracks… for example. This would allow separate teams to develop the frame and the microtrac, and so on by defining interfaces between the other components. It allows the project to scale out easily (wikispeed did this).		Our tool designs to be modular and have interchangeable parts. This allows us to use Contract First Design. CFD works by working to define the interfaces between components, to let engineers run wild with ideas for each component, as long as they work with the constraints of the interface requirements. For example, for the Microtrac, Graham could choose mount points for the tracks on the frame, define how much a load the tracks can support, how fast, where the hydraulic hoses will attach, and the bounding box of the tracks… for example. This would allow separate teams to develop the frame and the microtrac, and so on by defining interfaces between the other components. It allows the project to scale out easily (wikispeed did this).

	Status Log		'''Status Log'''

	When a task is moved to the "Done" column, it shouldn't be an entirely separate step to update that same task in the Status Log. That's redundant effort. This can be done automatically (and aggregated across all projects, if desired) by using Scrumy's API. I can do this once we start using Scrumy Pro.		When a task is moved to the "Done" column, it shouldn't be an entirely separate step to update that same task in the Status Log. That's redundant effort. This can be done automatically (and aggregated across all projects, if desired) by using Scrumy's API. I can do this once we start using Scrumy Pro.

	XP Control Panel		'''XP Control Panel'''

	This long list of items is intimidating and seems to stem from a traditional, waterfall project management mindset. What we really have here is a mixed up list of user stories and success criteria (along with ideas on team forming). These can be organized as such into separate lists, from an Agile mindset, and these lists, in turn, can be conveniently referred to when forming a new Scrum project. This would bring a great deal of cohesion to our project management strategy!		This long list of items is intimidating and seems to stem from a traditional, waterfall project management mindset. What we really have here is a mixed up list of user stories and success criteria (along with ideas on team forming). These can be organized as such into separate lists, from an Agile mindset, and these lists, in turn, can be conveniently referred to when forming a new Scrum project. This would bring a great deal of cohesion to our project management strategy!

	Least Important Data on Top?		'''Least Important Data on Top?'''

	The least important information on the Flashy XM page is at the top of the page: a tutorial, a currently un-updated SEBD, a flash mob map (which is eye candy, at best), and a video log. When I see people visit the page, without fail they scroll right past all this junk at the top to the status log (or task board).		The least important information on the Flashy XM page is at the top of the page: a tutorial, a currently un-updated SEBD, a flash mob map (which is eye candy, at best), and a video log. When I see people visit the page, without fail they scroll right past all this junk at the top to the status log (or task board).

	Fix it		'''Fix it'''

	There's a need to be transparent, but also not to overwhelm the casual visitor with day to day tasks of a sprint. Instead, give visitors project page with what they want: updates from the project's blog (which includes video posts from Youtube), links to the project's main wiki page (with the SEBD and so forth, and github repository if they're so deeply interested), and also a link to the Scrumy page, if they really want to see the tasks of the current sprint. That's more than sufficient.		There's a need to be transparent, but also not to overwhelm the casual visitor with day to day tasks of a sprint. Instead, give visitors project page with what they want: updates from the project's blog (which includes video posts from Youtube), links to the project's main wiki page (with the SEBD and so forth, and github repository if they're so deeply interested), and also a link to the Scrumy page, if they really want to see the tasks of the current sprint. That's more than sufficient.
Line 60:		Line 58:


	More Over		'''More Over'''

	Whenever a longterm strategic plan is written, or a policy decreed, or a director appointed, Martin Fowler rolls his eyes, since Agile is being violated. Agile is 40% faster than Waterfall --without counting compound gains-- so why go waterfall? Wikispeed's 100mpg car was not built in 3 months using Waterfall development!		Whenever a longterm strategic plan is written, or a policy decreed, or a director appointed, Martin Fowler rolls his eyes, since Agile is being violated. Agile is 40% faster than Waterfall --without counting compound gains-- so why go waterfall? Wikispeed's 100mpg car was not built in 3 months using Waterfall development!
Line 77:		Line 75:


	~~What~~'s in a Name		''W'hat's in a Name'''

	Wikispeed says they use Agile, Lean And Scrum. While I haven't talked about Lean here, I say our technique could just be called OSE Wikispeed.		Wikispeed says they use Agile, Lean And Scrum. While I haven't talked about Lean here, I say our technique could just be called OSE Wikispeed.

Vannmi: Created page with "Flashy XM: Critique We're Not XM First of all, we're not practicing Extreme Manufacturing. Two major components of XM are pairing and swarming. Though we could do both, in pr..."

2012-07-31T15:42:47Z

Created page with "Flashy XM: Critique We're Not XM First of all, we're not practicing Extreme Manufacturing. Two major components of XM are pairing and swarming. Though we could do both, in pr..."

New page

Flashy XM: Critique

We're Not XM

First of all, we're not practicing Extreme Manufacturing.

Two major components of XM are pairing and swarming. Though we could do both, in practice we've been doing neither, and they both play relatively minor roles.

Regarding pairing: We could be using pairing, to a limited extent, to train newcomers. But this practice hasn't really taken off yet, fora few reasons. One, most people here are overtaxed and don't have time to train. But mainly, many skills take a long time to attain; for example, most people have insufficient background to pick up software engineering or Finite Element Analysis by following someone else around. However, training by pairing has worked for relatively lower skill jobs, like fabrication and CADing in Sketchup.

Note that in the software world, "pairing" presumes that you already have two highly skilled engineers working side by side, not to learn, but to collaborate. This ensures good design and engineering practices, allows each to catch the other's errors, and so forth. Some learning invariably goes on, of course, but the paired members share a high level of technical expertise in their field.

Regarding swarming: this involves all team members working together to perform one task for the day. That's much different than crowd sourcing a solution (currently called Flash Mobs, but see below). Note Joe Justice of Team Wikispeed's opinion of swarming: it can be a good educational experience, but it's often not the most effective use of everyone's time. (Also, be sure to distinguish swarming from unblocking during a daily standup.) That said, swarming has its place, but we rarely do it.

But regardless, even if we were swarming and pairing, why elevate these two comparatively minor practices by including "XM" in our name?

We're Not Doing Flash Mobs Either

Secondly, we're not organizing flash mobs, but crowdsourcing to unblock on tasks.

The term "flash mob" is a misleading choice of words. Flash mobs involve laypeople, unknown to one another, who gather at a specific time and place to perform a public stunt or protest. Flash mobs therefore imply minimal planning ("let's meet at Macy's and dance while holding popsicles!"), zero vetting of anonymous participants, who then gather at a specific place and time to perform one giant, often nonsensical stunt, which need not be evaluated against any standard.

Crowdsourcing stands in stark contrast to flashing. It involves stating a well-defined problem, and soliciting solutions from subject matter experts, with the work to be performed over a relatively longer period of time and at no particular place. It can involve significant time in defining the problem well enough in order to sufficiently orient the experts, significant time to perform the task, and then again to evaluate any proposed solutions. All this work and time may be easily overlooked if using the totally misappropriated term "flash mob."

What is gained in using a term that's so misleading? Why not use an accurate phase that actually indicates what we're doing: "crowdsourcing a solution"

And, as with "XM", even this more accurate phrase need not be part of our name, given how rarely it's used.

Scrum

Until recently, we've been using Scrum entirely incorrectly: we haven't been holding (time boxed) sprints, much less holding the Sprint Planning Meetings, Scrum Review Meetings, or doing Stakeholder demonstrations. About the only thing we have been doing is calling what we do Scrum! I've elaborated on Scrum on my blog and given a few presentations to the volunteers at FeF, so won't go into more detail here.

Scrumy

Referring now to our use of Scrumy --the online tool we use for tracking our sprints-- we've been misusing that, too. User stories for a project should be listed vertically, not team member names. Therefore, we'd need a unique Scrumy project for each real world project. Fortunately, several people here have begun to do this for the projects they're leading.

Contract First Design

We want our tool designs to be modular and have interchangeable parts. This allows us to use Contract First Design. CFD works by working to define the interfaces between components, to let engineers run wild with ideas for each component, as long as they work with the constraints of the interface requirements. For example, for the Microtrac, Graham could choose mount points for the tracks on the frame, define how much a load the tracks can support, how fast, where the hydraulic hoses will attach, and the bounding box of the tracks… for example. This would allow separate teams to develop the frame and the microtrac, and so on by defining interfaces between the other components. It allows the project to scale out easily (wikispeed did this).

Status Log

When a task is moved to the "Done" column, it shouldn't be an entirely separate step to update that same task in the Status Log. That's redundant effort. This can be done automatically (and aggregated across all projects, if desired) by using Scrumy's API. I can do this once we start using Scrumy Pro.

XP Control Panel

This long list of items is intimidating and seems to stem from a traditional, waterfall project management mindset. What we really have here is a mixed up list of user stories and success criteria (along with ideas on team forming). These can be organized as such into separate lists, from an Agile mindset, and these lists, in turn, can be conveniently referred to when forming a new Scrum project. This would bring a great deal of cohesion to our project management strategy!

Least Important Data on Top?

The least important information on the Flashy XM page is at the top of the page: a tutorial, a currently un-updated SEBD, a flash mob map (which is eye candy, at best), and a video log. When I see people visit the page, without fail they scroll right past all this junk at the top to the status log (or task board).

Fix it

There's a need to be transparent, but also not to overwhelm the casual visitor with day to day tasks of a sprint. Instead, give visitors project page with what they want: updates from the project's blog (which includes video posts from Youtube), links to the project's main wiki page (with the SEBD and so forth, and github repository if they're so deeply interested), and also a link to the Scrumy page, if they really want to see the tasks of the current sprint. That's more than sufficient.

For Marcin's meta project page (which can also be geared for the public, or we can have a separate one), we can give him whatever he wants. But I suggest automatically pulling blog entries from each wiki, and giving him a status log pulled from all Scrum projects, using the Scrumy API. It would be updated instantly whenever any task in any Scrum project is moved to Done (or we can configure it to be updated whenever a task changes its status at all).

People starting new scrum projects can be referred to a template of user stories, success criteria, and team building tips from a newly reconstructed list built out of the one in the XP Control Panel. This will be 100% scalable, 100% Agile, and would make a heck of a lot more sense than the convoluted half Agile/half Waterfall, Scrum-butt we have now.

More Over

Whenever a longterm strategic plan is written, or a policy decreed, or a director appointed, Martin Fowler rolls his eyes, since Agile is being violated. Agile is 40% faster than Waterfall --without counting compound gains-- so why go waterfall? Wikispeed's 100mpg car was not built in 3 months using Waterfall development!

Instead of long term plans, state goals. That is: define what you want, not the how. Let Agile iterations determine the how and get you where you want to go. If you have a timeline, to make sure it's done, let your Scrum tool measure the velocity of your teams, and look see the burndown chart for a time estimate. If things are moving too slowly for the timeline, add more team members (or train them); that's the way to increase velocity. Let budgets evolve over time as teams learn what's involved.

But don't worry about the how. Eschew step-by-step procedures for "success criteria." I.e., "each GVCS should be cheaper to make, easier to repair, and en par with its proprietary industrial equivalent." This implies industry research will be done. It means that each task, of each iteration, is measured against these success criteria. Each step of the way it'll be tested to be cheap to make, easy to repair, and high performing. Separating the what you want, from the how, eliminates the need to demand adherence to step-by-step plans that no one here ever follows anyway. Trust your team to meet the success criteria, and then evaluate their results on a weekly basis (at the end of each iteration,) instead of falling into the trap of Waterfall (step-by-step) development.

Let policies naturally evolve (using consensus, preferably). As a leader, as long as the key values of FeF/OSE are agreed upon by volunteers, trust the wisdom of the group to figure out how values manifest into policies over time. Don't issue royal decrees. Be Agile, and let manifestation of values evolve over time.

Instead of appointing Directors, let people self assign themselves to cross-functional Scrum teams. This also echoes principles of Industrial Democracy (see SEMCO, Ricardo Semler).

Let Scrum work: let team members self-assign tasks they think they can complete for an iteration: don't ask people to finish something by such-and-such a date -- that's both a recipe for burnout and violates Scrum. If you're going to appoint anyone, just pick someone familiar with Scrum to be a ScrumMaster (and that's a position of no authority anyway).

Lastly, recognize that just because Wikispeed's product isn't documentation, ours can be. We prototype to validate and inform our product: our documentation. The result of each iteration is documentation. But this documentation is separate from requiring Waterfall plans (what will you do and how) and over-documenting every task within a given Sprint.

What's in a Name

Wikispeed says they use Agile, Lean And Scrum. While I haven't talked about Lean here, I say our technique could just be called OSE Wikispeed.