What: New England Agile Bazaar December meeting
Topic: Five Pillars of Agile Coaching, with Mike Hill
When: Thursday Dec 3, 6 - 9pm
Where: Constant Contact offices, Waltham just off 128
Cost: Free including food, courtesy of our sponsors:
Avid, http://www.avid.com/
Big Visible Solutions, http://www.bigvisible.com/
Constant Contact, http://www.constantcontact.com/
Details and RSVP at http://www.agilebazaar.org
Topic Abstract:
In this session, Mike "GeePaw" Hill presents and describes his Pillars
Of Coaching, the basic sources of all successful coaching efforts:
Situating, Modeling, Laughing, Sorting, and Empowering. These are the
wellsprings from which an experienced coach draws ideas, insights, and
inspiration. The GeePawHill style, funny and pointed and spot-on
accurate, should make this session informative and pleasurable.
More Detail:
All software development teams have problems - even agile teams. But
having the *right* problems is a sign that the team is on their way to
succeeding. Mike "GeePaw" Hill watches for the "right problems" in teams
he coaches. The next thing he looks for is that the solutions come "from
inside the group mind". You can learn and use these techniques no matter
what role or level you are in. Mike has even seen administrative
staffers become good coaches.
Coaching an agile team well means identifying and choosing the 'right
action' every day, for the whole range of situations a team encounters.
Many people struggle to create or identify good acts of coaching. The
results of 'running out of ideas' can be profoundly negative to the
team. Worse still, choosing the wrong acts can even undo the precious
progress a team has achieved.
Sound familiar? Don't miss this Thursday's Agile Bazaar meeting,
where Mike Hill -- a successful coach for over ten years -- explains the
pillars of his coaching practice. Situating, Inviting, Releasing,
Modeling, and Sorting, each one of which is a creative source for
everyday coaching. Learn how to get past the challenge of forming good
ideas for action, and into the direct actions that will help your team
move forward.
Your RSVP allows us to plan the right amount of food and drinks.
Don't wait - there is limited seating!
Our Speaker:
Mike "GeePaw" Hill has been a professional programmer for twenty-eight
years. For the last ten years he has focused his efforts as a trainer,
coach, and team lead on XP software projects and transitions. Mike is a
well-known leader in the Agile community and is a regular speaker at
related industry events. His chief interest over the last few years has
been on the perils and rewards of coaching agile development teams.
-------------------
Coming Dec 11: "Slicing Requirements for Agile Success" - A one-day
course with Ellen Gottesdiener and Mary Gorman
-------------------
Our January 7 meeting will feature Mary & Tom Poppendieck
Save the date! More details at http://www.agilebazaar.org
--
............................................
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.
781 301 1822 US mobile
nancyv@...http://www.leanagilepartners.com
Specialties: Agile coaching for Embedded Systems, for Data Migrations,
and for leadership of Lean-Agile change organization wide
............................................
Dear Mary:
Any hint here?
Cheers
Agustin
On Mon, Oct 19, 2009 at 23:53, Agustin Villena
<agustin.villena@...> wrote:
> Hi!
> In "Implementing Lean Software Development" (pages 230-233), Mary & Tom
> analyze Theroy of Constraints.
> ToC proposes that the critical constraint in an innovation project is
> "estimates as commitments", and proposes
> the Critical Chain tool, that defines an aditional time buffer to adjust
> uncertainty in a software project.
> Mary & Tom critics Critical Chain, calling this tool an "accomodation" to
> the critical constraint, and says that the real
> solution es to work hard to break depedencies and deliver small and
> incremental releases.
> This solution is intuitively acceptable to me, but I would welcome a more
> detailed logical explanation
> about how the key constraint "estimates as commitments" is mitigated with
> these actions.
>
> At my work some people are proposing to add buffers for uncertainty to our
> projects,
> and I need good arguments to point out that this is not the root solution.
>
> Thanks!
> Agustin
Hi Siva,
I made a mistake in calling this a Checklist, and you and Andre rightly pointed
out that it is a bit intimidating.
However, as Dave said, if i use this as an 'assessment template' , we get to
know why they made some decisions and whether they still apply in current
conditions, why some issues are not adressed yet, and so on. It then becomes
easier to take things forward. Besides, if they document most of their standard
work steps, then it can help a new team to take over.
The questions are open ended since it may otherwise focus towards predefined
solutions.
That was the idea.
Thanks to everyone for their feedback.
Regards,
Chak.
--- In leandevelopment@yahoogroups.com, "sub_mails" <sub_mails@...> wrote:
>
> Hi Chak
>
> That is a good list. My suggestion is to organize them to logical groups, some
on design, some on risk management, some on architecture and so on. Then the
list will not look intimidating.
>
> Also, what is the purpose of the checklist,do we want to prove something is
fine or something is not fine ? or is the checklist a generic memory jogger ?
>
> Can the checklist be brought to a state that it could be either a Yes or a No
to it ? Some of the questions can run into lenghty descriptive response.
>
> Some thoughts that came to my mind.....
>
> PS:Thanks for hilighting the presence of this group in lean.org forum :)
>
> Rgds
> Siva
>
>
>
> --- In leandevelopment@yahoogroups.com, "r_chakra" <chakravarthy.rajagopalan@>
wrote:
> >
> > Thanks Dave. Yes, i could call it an assessment list or template. It is
just to know the current state so that the team can then plan their future
processes based on their level of interest and needs.
> >
> > Your checklist example is good.
> >
> > Regards,
> > Chak.
> >
> > --- In leandevelopment@yahoogroups.com, David Laribee <david@> wrote:
> > >
> > > Hi Chak -
> > >
> > > Your example seems like more of a template for overall assessment than a
> > > checklist in the Toyota Product Development System sense.
> > >
> > > I think of a checklist as something we apply to an task we regularly
perform
> > > in the course of delivering software. A checklist, when completed, let's
us
> > > know when we can place an order in the next pull buffer. A couple
examples:
> > >
> > > - Acceptance Tests on a story.
> > > - A deployment procedure.
> > > - A series of common steps we use to invest in defining an MMF (story map,
> > > conceptual map, ubiquitous language, story breakdown)
> > >
> > > / Dave
> > >
> > > David Laribee
> > > http://thebeelog.com
> > > 1 (646) 462-4096
> > >
> > >
> > > On Mon, Nov 16, 2009 at 2:00 AM, Chakravarthy R <
> > > chakravarthy.rajagopalan@> wrote:
> > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Let me introduce myself as a Software consultant , mainly in
Microsoft.NET
> > > > platform, in Bangalore, India. I was recently asked to guide the
software
> > > > team of 10 people in a startup company in their processes. Since they
are
> > > > mostly junior people and do not have the time to spend time discussing
or
> > > > implementing heavy processes, i decided to put together a checklist for
> > > > them. This checklist has become much bigger than i thought (almost 300
> > > > items) and seems a bit paranoid :) I do not like ISO like
documentation
> > > > myself, but it has crept in a lot in the list since i thought this
company
> > > > needed a way to retain it's ideas. I hope this list is influenced by a
> > > > light weight approach like Agile, XP and others.
> > > >
> > > > In any case, i hope some of you can take a look at it and tell me if
there
> > > > is some method to the madness. How can it be improved ?
> > > >
> > > > Thanks,
> > > > Chak.
> > > >
> > > >
http://moko59.wordpress.com/2009/11/15/self-check-list-for-a-software-team/
> > > >
> > > >
> > > >
> > >
> >
>
Hi Chak
That is a good list. My suggestion is to organize them to logical groups, some
on design, some on risk management, some on architecture and so on. Then the
list will not look intimidating.
Also, what is the purpose of the checklist,do we want to prove something is fine
or something is not fine ? or is the checklist a generic memory jogger ?
Can the checklist be brought to a state that it could be either a Yes or a No to
it ? Some of the questions can run into lenghty descriptive response.
Some thoughts that came to my mind.....
PS:Thanks for hilighting the presence of this group in lean.org forum :)
Rgds
Siva
--- In leandevelopment@yahoogroups.com, "r_chakra"
<chakravarthy.rajagopalan@...> wrote:
>
> Thanks Dave. Yes, i could call it an assessment list or template. It is just
to know the current state so that the team can then plan their future processes
based on their level of interest and needs.
>
> Your checklist example is good.
>
> Regards,
> Chak.
>
> --- In leandevelopment@yahoogroups.com, David Laribee <david@> wrote:
> >
> > Hi Chak -
> >
> > Your example seems like more of a template for overall assessment than a
> > checklist in the Toyota Product Development System sense.
> >
> > I think of a checklist as something we apply to an task we regularly perform
> > in the course of delivering software. A checklist, when completed, let's us
> > know when we can place an order in the next pull buffer. A couple examples:
> >
> > - Acceptance Tests on a story.
> > - A deployment procedure.
> > - A series of common steps we use to invest in defining an MMF (story map,
> > conceptual map, ubiquitous language, story breakdown)
> >
> > / Dave
> >
> > David Laribee
> > http://thebeelog.com
> > 1 (646) 462-4096
> >
> >
> > On Mon, Nov 16, 2009 at 2:00 AM, Chakravarthy R <
> > chakravarthy.rajagopalan@> wrote:
> >
> > >
> > >
> > > Hi,
> > >
> > > Let me introduce myself as a Software consultant , mainly in Microsoft.NET
> > > platform, in Bangalore, India. I was recently asked to guide the software
> > > team of 10 people in a startup company in their processes. Since they are
> > > mostly junior people and do not have the time to spend time discussing or
> > > implementing heavy processes, i decided to put together a checklist for
> > > them. This checklist has become much bigger than i thought (almost 300
> > > items) and seems a bit paranoid :) I do not like ISO like documentation
> > > myself, but it has crept in a lot in the list since i thought this company
> > > needed a way to retain it's ideas. I hope this list is influenced by a
> > > light weight approach like Agile, XP and others.
> > >
> > > In any case, i hope some of you can take a look at it and tell me if there
> > > is some method to the madness. How can it be improved ?
> > >
> > > Thanks,
> > > Chak.
> > >
> > >
http://moko59.wordpress.com/2009/11/15/self-check-list-for-a-software-team/
> > >
> > >
> > >
> >
>
In sunny Chicago, we will hold the next Leading Lean Software Development
course.
This is a new 2-day course / workshop led by Mary & Tom Poppendieck based on
their new book (Nov 2009).
See http://bit.ly/bjuFD for more details. Or contact me with any questions.
Regards,
Julia Hill
Thanks Dave. Yes, i could call it an assessment list or template. It is just to
know the current state so that the team can then plan their future processes
based on their level of interest and needs.
Your checklist example is good.
Regards,
Chak.
--- In leandevelopment@yahoogroups.com, David Laribee <david@...> wrote:
>
> Hi Chak -
>
> Your example seems like more of a template for overall assessment than a
> checklist in the Toyota Product Development System sense.
>
> I think of a checklist as something we apply to an task we regularly perform
> in the course of delivering software. A checklist, when completed, let's us
> know when we can place an order in the next pull buffer. A couple examples:
>
> - Acceptance Tests on a story.
> - A deployment procedure.
> - A series of common steps we use to invest in defining an MMF (story map,
> conceptual map, ubiquitous language, story breakdown)
>
> / Dave
>
> David Laribee
> http://thebeelog.com
> 1 (646) 462-4096
>
>
> On Mon, Nov 16, 2009 at 2:00 AM, Chakravarthy R <
> chakravarthy.rajagopalan@...> wrote:
>
> >
> >
> > Hi,
> >
> > Let me introduce myself as a Software consultant , mainly in Microsoft.NET
> > platform, in Bangalore, India. I was recently asked to guide the software
> > team of 10 people in a startup company in their processes. Since they are
> > mostly junior people and do not have the time to spend time discussing or
> > implementing heavy processes, i decided to put together a checklist for
> > them. This checklist has become much bigger than i thought (almost 300
> > items) and seems a bit paranoid :) I do not like ISO like documentation
> > myself, but it has crept in a lot in the list since i thought this company
> > needed a way to retain it's ideas. I hope this list is influenced by a
> > light weight approach like Agile, XP and others.
> >
> > In any case, i hope some of you can take a look at it and tell me if there
> > is some method to the madness. How can it be improved ?
> >
> > Thanks,
> > Chak.
> >
> > http://moko59.wordpress.com/2009/11/15/self-check-list-for-a-software-team/
> >
> >
> >
>
Your example seems like more of a template for overall assessment than a checklist in the Toyota Product Development System sense.
I think of a checklist as something we apply to an task we regularly perform in the course of delivering software. A checklist, when completed, let's us know when we can place an order in the next pull buffer. A couple examples:
- Acceptance Tests on a story. - A deployment procedure. - A series of common steps we use to invest in defining an MMF (story map, conceptual map, ubiquitous language, story breakdown)
Let me introduce myself as a Software consultant , mainly in Microsoft.NET platform, in Bangalore, India. I was recently asked to guide the software team of 10 people in a startup company in their processes. Since they are mostly junior people and do not have the time to spend time discussing or implementing heavy processes, i decided to put together a checklist for them. This checklist has become much bigger than i thought (almost 300 items) and seems a bit paranoid :) I do not like ISO like documentation myself, but it has crept in a lot in the list since i thought this company needed a way to retain it's ideas. I hope this list is influenced by a light weight approach like Agile, XP and others.
In any case, i hope some of you can take a look at it and tell me if there is some method to the madness. How can it be improved ?
If the team, which has already completed one SDLC life cycle of their product
for a local customer, shows more interest in 'process', i wanted them to fill in
their answers to each of these questions. This would have been the baseline of
the current process.
--- In leandevelopment@yahoogroups.com, Ilja Preuß <iljapreuss@...> wrote:
>
> How do you intend the list to be used?
>
> Curious, Ilja
>
> 2009/11/16 Chakravarthy R <chakravarthy.rajagopalan@...>
>
> >
> >
> > Hi,
> >
> > Let me introduce myself as a Software consultant , mainly in Microsoft.NET
> > platform, in Bangalore, India. I was recently asked to guide the software
> > team of 10 people in a startup company in their processes. Since they are
> > mostly junior people and do not have the time to spend time discussing or
> > implementing heavy processes, i decided to put together a checklist for
> > them. This checklist has become much bigger than i thought (almost 300
> > items) and seems a bit paranoid :) I do not like ISO like documentation
> > myself, but it has crept in a lot in the list since i thought this company
> > needed a way to retain it's ideas. I hope this list is influenced by a
> > light weight approach like Agile, XP and others.
> >
> > In any case, i hope some of you can take a look at it and tell me if there
> > is some method to the madness. How can it be improved ?
> >
> > Thanks,
> > Chak.
> >
> > http://moko59.wordpress.com/2009/11/15/self-check-list-for-a-software-team/
> >
> >
> >
>
Let me introduce myself as a Software consultant , mainly in Microsoft.NET platform, in Bangalore, India. I was recently asked to guide the software team of 10 people in a startup company in their processes. Since they are mostly junior people and do not have the time to spend time discussing or implementing heavy processes, i decided to put together a checklist for them. This checklist has become much bigger than i thought (almost 300 items) and seems a bit paranoid :) I do not like ISO like documentation myself, but it has crept in a lot in the list since i thought this company needed a way to retain it's ideas. I hope this list is influenced by a light weight approach like Agile, XP and others.
In any case, i hope some of you can take a look at it and tell me if there is some method to the madness. How can it be improved ?
It's actually a check list of 30 items (not 300), but it's still pretty intimidating. I'd be afraid it could paralyze development, or scare people into adding much more complexity than they need right now. Is this a new code base? I think that if you set up the basics of version control, good TDD practices, weekly releases+retrospectives, you can let the team make their own processes, especially if you get them all reading something together like the Art of Agile Development or XP explained or Agile Principles, Patterns, and Practices...
Let me introduce myself as a Software consultant , mainly in Microsoft.NET platform, in Bangalore, India. I was recently asked to guide the software team of 10 people in a startup company in their processes. Since they are mostly junior people and do not have the time to spend time discussing or implementing heavy processes, i decided to put together a checklist for them. This checklist has become much bigger than i thought (almost 300 items) and seems a bit paranoid :) I do not like ISO like documentation myself, but it has crept in a lot in the list since i thought this company needed a way to retain it's ideas. I hope this list is influenced by a light weight approach like Agile, XP and others.
In any case, i hope some of you can take a look at it and tell me if there is some method to the madness. How can it be improved ?
Ricardo semler talks about unions in his book Maverick which is well worth reading.
Sent from my iPhone
On Nov 15, 2009, at 20:44, Robin Dymond <robin.dymond@...> wrote:
Given that Lean has been applied in the most unionized business of
all, automobile manufacturing, I think it is possible. In Ohno's book
on TPS he mentions the labor strife they had at Toyota in the 50's and
eventually the unions capitulated and allowed their members to do more
than one job.
What specifically is the problem with the union in your case? Job
descriptions? Have you talked with any of the staff or union reps? If
the govt is mandating Agile, why would the unions be an issue?
Regards,
Robin Dymond.
On 11/15/09, Louis-Philippe Carignan <lpcarignan@yahoo.com> wrote:
> Hi all,
>
> I was wondering if any of you guys had any insightful readings in regards to
> implementing Lean/Agile in an unionized environement. I am based in the
> province of Quebec and we are seeing government RFPs who are asking for
> Agile/Lean content in IT.
>
> I know Lean has gotten a lot of traction in healthcare, another sector
> packed with unions. In my opinion, it is mainly due to the fact that
> doctors, who are central characters in this field, are the ones pushing for
> Lean in healthcare.
>
> But in IT, how would one help an organization who has union workers? I do
> agree when authors like Demings or Seddon say that we should change the
> system. But with a union to work with, it doesn't really work that way.
> Things are more crystallized. Any thoughs on change management toward
> Agile/Lean in this particular environment?
>
> Thanks,
>
> Louis-Philippe Carignan
>
>
>
Let me introduce myself as a Software consultant , mainly in Microsoft.NET platform, in Bangalore, India. I was recently asked to guide the software team of 10 people in a startup company in their processes. Since they are mostly junior people and do not have the time to spend time discussing or implementing heavy processes, i decided to put together a checklist for them. This checklist has become much bigger than i thought (almost 300 items) and seems a bit paranoid :) I do not like ISO like documentation myself, but it has crept in a lot in the list since i thought this company needed a way to retain it's ideas. I hope this list is influenced by a light weight approach like Agile, XP and others.
In any case, i hope some of you can take a look at it and tell me if there is some method to the madness. How can it be improved ?
Louis-Philippe Carignan wrote:
> Hi Robin,
>
> One of my worries was about a collocated team. As stupid as it may sounds,
some people can have a cubicle next to a window because they have been there
for 10 years. They deserve a window spot, even if they aren't close to the rest
of the team. Another issue is how code is build. Believe or not but not install
an application in a QA environment, one person will compile the code and another
person will install it. I'm wondering how will I present them with ideas like
continuous integration where this could all be done automatically.
>
I've "done agile" in the public sector, and have yet to come across a
scenario where people had such narrow job descriptions. I have seen
situations where a specific group had to install applications on servers
in the QA/Integration (with other apps) environment, but that was only
mildly annoying and the group that performed the work did their best to
keep up with the demand for installations.
I guess what I would question is who is pushing the use of an agile
process for this client? Is their management doing it? If so, why,
i.e. what benefits are they trying to achieve? What pain are they
feeling now? If they can state that, then you have the leverage you
need to introduce the practices that will help them. If they don't
think they need help, you will only be hurting yourself.
As for co-location, I've coached in France before. The labour laws
there, I was told, stipulate that contractors/consultants must have
their desks in a physically separate work area than the full-time
employees. The group did plan together and quite often paired in the
same location, but there was no way to avoid that regulation 100% of the
time.
> Interesting to hear that unions capitualed at Toyota in the 50s. Problem is,
my project will be for a public sector agency. There jobs aren't on the line.
>
I hear this a lot about the public sector. Fear of losing a job is no
way to motivate people. When people actually enjoy their work, they
will be motivated. I've watched teams in both sectors transition to
Agile and actually start having fun again.
--
Dave Rooney
Co-founder and Consultant, The Agile Consortium
"Maximizing the value of your IT investments!"
E-mail: dave@...
Twitter: daverooneyca
http://www.theagileconsortium.comhttp://practicalagility.blogspot.com
Hi Robin,
One of my worries was about a collocated team. As stupid as it may sounds, some
people can have a cubicle next to a window because they have been there for 10
years. They deserve a window spot, even if they aren't close to the rest of the
team. Another issue is how code is build. Believe or not but not install an
application in a QA environment, one person will compile the code and another
person will install it. I'm wondering how will I present them with ideas like
continuous integration where this could all be done automatically.
My best selling point is scarce ressource. As baby boomers are retiring, there's
less people
to replace the current people.
Interesting to hear that unions capitualed at Toyota in the 50s. Problem is, my
project will be for a public sector agency. There jobs aren't on the line.
One of my approach was to use the fun theory
(http://analytical-mind.com/2009/11/09/have-you-heard-of-the-fun-theory/). By
making Agile a better alternative than there current way of working, I should be
able to bring them on board. I was planning on identify the leader(s) and make
them early adopters so the rest of the gang can jump in.
I was just wondering if anybody out here had such an experience. I've found this
group very helpful in the past so I was wondering if anybody had pointers to
give me.
Louis-Philippe
--- In leandevelopment@yahoogroups.com, Robin Dymond <robin.dymond@...> wrote:
>
> Given that Lean has been applied in the most unionized business of
> all, automobile manufacturing, I think it is possible. In Ohno's book
> on TPS he mentions the labor strife they had at Toyota in the 50's and
> eventually the unions capitulated and allowed their members to do more
> than one job.
>
> What specifically is the problem with the union in your case? Job
> descriptions? Have you talked with any of the staff or union reps? If
> the govt is mandating Agile, why would the unions be an issue?
>
> Regards,
> Robin Dymond.
>
>
>
>
> On 11/15/09, Louis-Philippe Carignan <lpcarignan@...> wrote:
> > Hi all,
> >
> > I was wondering if any of you guys had any insightful readings in regards to
> > implementing Lean/Agile in an unionized environement. I am based in the
> > province of Quebec and we are seeing government RFPs who are asking for
> > Agile/Lean content in IT.
> >
> > I know Lean has gotten a lot of traction in healthcare, another sector
> > packed with unions. In my opinion, it is mainly due to the fact that
> > doctors, who are central characters in this field, are the ones pushing for
> > Lean in healthcare.
> >
> > But in IT, how would one help an organization who has union workers? I do
> > agree when authors like Demings or Seddon say that we should change the
> > system. But with a union to work with, it doesn't really work that way.
> > Things are more crystallized. Any thoughs on change management toward
> > Agile/Lean in this particular environment?
> >
> > Thanks,
> >
> > Louis-Philippe Carignan
> >
> >
> >
>
>
> --
> Robin Dymond, CST
> Managing Partner, Innovel, LLC.
> www.innovel.net
> www.scrumtraining.com
> Americas: (804) 239-4329
> Europe: +32 489 674 366
>
Hi,
A medical unionized environment. Doctors are sensitive to cutbacks in
their pockets
so they will lead/push for overall trimming.
Doctors are also going strong in 'crew resource management' (CRM)
following air crew ideas.
Going from you having a 1 in 7 chance of getting the wrong medicine while
in a North American hospital now, to anything less will often be linked
to CRM.
A key is reducing the number of job classifications and improving the
adaptability/flexibility.
In Western Canada and other industries contractors become more common,
and more
activities are contracted outside the centralized union facilities
(hospitals) into private settings
(which is what has happened all along for politicians and police and
other special people).
Louis-Philippe Carignan wrote:
> . . .
> I know Lean has gotten a lot of traction in healthcare, another sector packed
with unions. In my opinion, it is mainly due to the fact that doctors, who are
central characters in this field, are the ones pushing for Lean in healthcare.
>
> But in IT, how would one help an organization who has union workers? I do
agree when authors like Demings or Seddon say that we should change the system.
But with a union to work with, it doesn't really work that way. Things are more
crystallized. Any thoughs on change management toward Agile/Lean in this
particular environment?
>
>
>
bye,
vic
--
"Conventional MBA programs train the wrong people in the
wrong ways with the wrong consequences."
-- Henry Mintzberg, McGill University
"It's not my problem. The hole is in their side of the boat."
- John Brewer - Vic Williams 13066824980
Given that Lean has been applied in the most unionized business of
all, automobile manufacturing, I think it is possible. In Ohno's book
on TPS he mentions the labor strife they had at Toyota in the 50's and
eventually the unions capitulated and allowed their members to do more
than one job.
What specifically is the problem with the union in your case? Job
descriptions? Have you talked with any of the staff or union reps? If
the govt is mandating Agile, why would the unions be an issue?
Regards,
Robin Dymond.
On 11/15/09, Louis-Philippe Carignan <lpcarignan@...> wrote:
> Hi all,
>
> I was wondering if any of you guys had any insightful readings in regards to
> implementing Lean/Agile in an unionized environement. I am based in the
> province of Quebec and we are seeing government RFPs who are asking for
> Agile/Lean content in IT.
>
> I know Lean has gotten a lot of traction in healthcare, another sector
> packed with unions. In my opinion, it is mainly due to the fact that
> doctors, who are central characters in this field, are the ones pushing for
> Lean in healthcare.
>
> But in IT, how would one help an organization who has union workers? I do
> agree when authors like Demings or Seddon say that we should change the
> system. But with a union to work with, it doesn't really work that way.
> Things are more crystallized. Any thoughs on change management toward
> Agile/Lean in this particular environment?
>
> Thanks,
>
> Louis-Philippe Carignan
>
>
>
--
Robin Dymond, CST
Managing Partner, Innovel, LLC.
www.innovel.net
www.scrumtraining.com
Americas: (804) 239-4329
Europe: +32 489 674 366
Hi all,
I was wondering if any of you guys had any insightful readings in regards to
implementing Lean/Agile in an unionized environement. I am based in the province
of Quebec and we are seeing government RFPs who are asking for Agile/Lean
content in IT.
I know Lean has gotten a lot of traction in healthcare, another sector packed
with unions. In my opinion, it is mainly due to the fact that doctors, who are
central characters in this field, are the ones pushing for Lean in healthcare.
But in IT, how would one help an organization who has union workers? I do agree
when authors like Demings or Seddon say that we should change the system. But
with a union to work with, it doesn't really work that way. Things are more
crystallized. Any thoughs on change management toward Agile/Lean in this
particular environment?
Thanks,
Louis-Philippe Carignan
The inaugural Lean Software & Systems Conference is now open for registration
and paper submissions.
Register or submit now at http://atlanta2010.leanssc.org/
Conference Chair: David Anderson
Track Chairs: Alan Shalloway, Joshua Kerievsky, James Sutton, Richard Turner,
Eric Willeke, Chris Shinkle and David Anderson
Event Planner: Kelly Wilson (SEP)
Event Team: Janice Linden-Reed, Dennis Stevens, Aaron Sanders, Eric Landes
Registration
------------
Registration is limited by venue capacity to 250 in addition to our 40 speakers
and event planning team.
The first 50 registrants receive a special discount price of $800, plus an
exclusive invite to the speaker luncheon on Thursday April 22nd and a special
Ltd WIP Society t-shirt designed by David Anderson and exclusive to the event.
Regular registration will cost $995.
Late comer registration after March 31st 2010 will cost $1250.
There are currently no plans to offer single day registration.
Venue
-----
JW Marriott, Buckhead, Atlanta. A special room block of 180 rooms has been
reserved. Please use the link on the conference site to make your reservation.
Dates
-----
Wednesday April 21 to Friday April 23, 2010
Call For Papers
---------------
This year's conference features 2 key note speakers, 21 invited speakers and 17
presentations selected from the call for papers. Details of all invited speakers
are already on the web site.
The 2010 event features 3 tracks per day and either 1 hour or 45 minute time
slots depending on track and day.
Sponsorship
-----------
Software Engineering Professionals (SEP) is the organizing sponsor. We are
seeking other sponsors for the event and the sponsorship proposal package will
be available in December. If you wish to receive a copy please email
info@...
Register or submit now at http://atlanta2010.leanssc.org/
I would agree to not creating branches as much as possible. In my
experience usually leads to non value added activities.
I think one factor to consider would be dependencies (functional or
otherwise) between stories that are being worked on. If 10 people are
working on 10 stories and all are independent then each story could be
released one at a time, without too much overhead. However if there are
functional dependencies then there is an added cost of the exploratory
testing being done on a code base comprising of incomplete (not fully
done done stories) stories. There may be additional costs due to
repetition of the exploratory testing per story released. Typically a
time boxed iteration where a certain set of stories are ascertained for
regression together seems to add value. This is particularly true,
where part of the regression testing is manual.
Another factor to consider would be to look at people assigned/story as
a factor. IMHO, more people per story seems to induce more need for
planning and hence potential waste due to wait time, unplanned
dependencies etc.,
The release per story approach might be more valid in cases, where the
cost of additional/missed exploratory testing is compensated by the
business risk of the story ( i.e. I expect to find lots of issues after
usage) and/or value due to early delivery. If the business risk is the
primary reason, then alternative approaches could be used to reduce
that risk - demo environment, end user hands down usage on test
environments etc., could be options.
Hope it helps.
Arun
D. André Dhondt wrote:
We're an XP team (of 10 people) trying to go a bit more lean, and
I don't know what to do with multiple work items in progress. With XP,
the end of the iteration was the time to make sure everything was
done-done, to cut a release, and deploy (I do oversimplify, I have
worked on teams where we deployed daily, but not my current team). Yet
with a kanban system, I get the impression I should be ready to deploy
as each card is finished... but there are other story cards underway,
that may be half finished--so I don't think I'm in a spot I can really
release after every card... and since we're talking about eliminating
iterations altogether, I don't know when we'll get to a fully-tested
done-done code base. What is your lean team doing to be confident the
code is ready to release? I don't like using branching, or flags in
the code, because it adds overhead. I can't see how limiting the
work-in-progress slots to 1 would be effective on a team of 10. Still,
maybe that's what you're doing--tell me what advantages/disadvantages
you see...