A little background: I've been tasked with the tall order of reigning
in the chaos that was my company's software development 'process' into
something more rational and repeatable. I've long been interested in
agile methods but have never had the opportunity to work with them
directly. At the advice of a respected project manager colleague, I'm
doing some serious investigations into Scrum and from what I've read
on agile-software-development.com, it looks like something I can
present to executives. There's just one nagging thing that I need
help figuring out... well, more than one, but this is the top of the
heap :) :
We're a small company (<20 employees). Currently, our product
consists of four distinct areas, each with 1-3 subject matter
experts. Any given release involves work in all areas, some features
overlap into multiple areas, but not always. Our developers are
pretty flexible, but we have everything from kernel developers to
Flash UI developers so individuals generally stick to their areas of
expertise. From what I've read here and in other places, Scrum
recommends that only one feature is developed at a time. So, my
question is: how do I reconcile having four development silos with
only developing one feature at a time? Do I manage four different
scrums? One scrum, but allow multiple features to be developed at the
same time (so long as they are in different silos)?
I'd start working hard to get the term "silos" out of the company. There may
be different specialist areas in your product, but only the combination of
the four make a product. I'd be release planning with all the 20 people,
plus the product folks, to lay out a good structure for a next release of
the overall product. In that session the team figures out when to pay
attention to what specialist area. Then the individual teams will run then
Sprints, and Sprint plan at the same time so they can figure out which
dependencies are appearing, and how to solve them. Keep builds running over
the product, not within a team. Keep tests running over the product, not the
team. Do your demos with the whole group, not per team.
On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com> wrote:
> Hi folks,
> A little background: I've been tasked with the tall order of reigning
> in the chaos that was my company's software development 'process' into
> something more rational and repeatable. I've long been interested in
> agile methods but have never had the opportunity to work with them
> directly. At the advice of a respected project manager colleague, I'm
> doing some serious investigations into Scrum and from what I've read
> on agile-software-development.com, it looks like something I can
> present to executives. There's just one nagging thing that I need
> help figuring out... well, more than one, but this is the top of the
> heap :) :
> We're a small company (<20 employees). Currently, our product
> consists of four distinct areas, each with 1-3 subject matter
> experts. Any given release involves work in all areas, some features
> overlap into multiple areas, but not always. Our developers are
> pretty flexible, but we have everything from kernel developers to
> Flash UI developers so individuals generally stick to their areas of
> expertise. From what I've read here and in other places, Scrum
> recommends that only one feature is developed at a time. So, my
> question is: how do I reconcile having four development silos with
> only developing one feature at a time? Do I manage four different
> scrums? One scrum, but allow multiple features to be developed at the
> same time (so long as they are in different silos)?
My Case is very Similar to what Mitch has, except that the Expertise Areas
are spread across the world and "NO WAY" under on roof is possible and also
All Four Groups Mastering other Expertise areas is a hughe Investment and
also burdens the individuals a lot.
> I'd start working hard to get the term "silos" out of the company. There
> may be different specialist areas in your product, but only the combination
> of the four make a product. I'd be release planning with all the 20 people,
> plus the product folks, to lay out a good structure for a next release of
> the overall product. In that session the team figures out when to pay
> attention to what specialist area. Then the individual teams will run then
> Sprints, and Sprint plan at the same time so they can figure out which
> dependencies are appearing, and how to solve them. Keep builds running over
> the product, not within a team. Keep tests running over the product, not the
> team. Do your demos with the whole group, not per team.
> On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com>wrote:
>> Hi folks,
>> A little background: I've been tasked with the tall order of reigning
>> in the chaos that was my company's software development 'process' into
>> something more rational and repeatable. I've long been interested in
>> agile methods but have never had the opportunity to work with them
>> directly. At the advice of a respected project manager colleague, I'm
>> doing some serious investigations into Scrum and from what I've read
>> on agile-software-development.com, it looks like something I can
>> present to executives. There's just one nagging thing that I need
>> help figuring out... well, more than one, but this is the top of the
>> heap :) :
>> We're a small company (<20 employees). Currently, our product
>> consists of four distinct areas, each with 1-3 subject matter
>> experts. Any given release involves work in all areas, some features
>> overlap into multiple areas, but not always. Our developers are
>> pretty flexible, but we have everything from kernel developers to
>> Flash UI developers so individuals generally stick to their areas of
>> expertise. From what I've read here and in other places, Scrum
>> recommends that only one feature is developed at a time. So, my
>> question is: how do I reconcile having four development silos with
>> only developing one feature at a time? Do I manage four different
>> scrums? One scrum, but allow multiple features to be developed at the
>> same time (so long as they are in different silos)?
The suggestion is the same, but you'll have to work a bit harder to align
the global teams. I wrote a paper on the planning process for agile projects
("Five Levels of Planning" - <
http://www.agilejournal.com/content/view/412/33/>) which explains the
background. In my experience it is important that the full team (or as close
as you can get to it) does the release planning. The specialist groups have
to figure out how to solve the tough problems (especially when distributed).
That implies that some will work at a crazy time, I've ran planning sessions
at midnight, at 4am, at 9pm - all to accommodate the other team members
somewhere around the globe. During release planning the team agrees which
story is built in which iteration (Sprint). There is no detail added, no
design done, just thinking about the best order. Ordering stories take
business priorities into consideration, risks, dependencies, and learning.
When scattered around the globe you will likely use tools, the simple ones
are Cardmeeting, more complete is a tool like Rally (yes I am biased here).
And I hear you about budget and cost of flying people in, still, if you can
make it happen then do it, it will work wonders for your team spirit.
> My Case is very Similar to what Mitch has, except that the Expertise Areas
> are spread across the world and "NO WAY" under on roof is possible and also
> All Four Groups Mastering other Expertise areas is a hughe Investment and
> also burdens the individuals a lot.
>> I'd start working hard to get the term "silos" out of the company. There
>> may be different specialist areas in your product, but only the combination
>> of the four make a product. I'd be release planning with all the 20 people,
>> plus the product folks, to lay out a good structure for a next release of
>> the overall product. In that session the team figures out when to pay
>> attention to what specialist area. Then the individual teams will run then
>> Sprints, and Sprint plan at the same time so they can figure out which
>> dependencies are appearing, and how to solve them. Keep builds running over
>> the product, not within a team. Keep tests running over the product, not the
>> team. Do your demos with the whole group, not per team.
>> On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com>wrote:
>>> Hi folks,
>>> A little background: I've been tasked with the tall order of reigning
>>> in the chaos that was my company's software development 'process' into
>>> something more rational and repeatable. I've long been interested in
>>> agile methods but have never had the opportunity to work with them
>>> directly. At the advice of a respected project manager colleague, I'm
>>> doing some serious investigations into Scrum and from what I've read
>>> on agile-software-development.com, it looks like something I can
>>> present to executives. There's just one nagging thing that I need
>>> help figuring out... well, more than one, but this is the top of the
>>> heap :) :
>>> We're a small company (<20 employees). Currently, our product
>>> consists of four distinct areas, each with 1-3 subject matter
>>> experts. Any given release involves work in all areas, some features
>>> overlap into multiple areas, but not always. Our developers are
>>> pretty flexible, but we have everything from kernel developers to
>>> Flash UI developers so individuals generally stick to their areas of
>>> expertise. From what I've read here and in other places, Scrum
>>> recommends that only one feature is developed at a time. So, my
>>> question is: how do I reconcile having four development silos with
>>> only developing one feature at a time? Do I manage four different
>>> scrums? One scrum, but allow multiple features to be developed at the
>>> same time (so long as they are in different silos)?
I'd say that it is all about communication. If two people's work overlap
then they should be part of the same team to encourage communication between
them. If the work of two people never overlaps then it is inefficient for
them to attend the same meetings and discussions.
I'd suggest splitting the teams according to the functionality they are
working on regardless of their knowledge area, with only occasional get
togethers based on their knowledge area.
On Thu, Oct 8, 2009 at 8:20 AM, Sudeep Pondala <sudeep.pond...@gmail.com>wrote:
> My Case is very Similar to what Mitch has, except that the Expertise Areas
> are spread across the world and "NO WAY" under on roof is possible and also
> All Four Groups Mastering other Expertise areas is a hughe Investment and
> also burdens the individuals a lot.
>> I'd start working hard to get the term "silos" out of the company. There
>> may be different specialist areas in your product, but only the combination
>> of the four make a product. I'd be release planning with all the 20 people,
>> plus the product folks, to lay out a good structure for a next release of
>> the overall product. In that session the team figures out when to pay
>> attention to what specialist area. Then the individual teams will run then
>> Sprints, and Sprint plan at the same time so they can figure out which
>> dependencies are appearing, and how to solve them. Keep builds running over
>> the product, not within a team. Keep tests running over the product, not the
>> team. Do your demos with the whole group, not per team.
>> On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com>wrote:
>>> Hi folks,
>>> A little background: I've been tasked with the tall order of reigning
>>> in the chaos that was my company's software development 'process' into
>>> something more rational and repeatable. I've long been interested in
>>> agile methods but have never had the opportunity to work with them
>>> directly. At the advice of a respected project manager colleague, I'm
>>> doing some serious investigations into Scrum and from what I've read
>>> on agile-software-development.com, it looks like something I can
>>> present to executives. There's just one nagging thing that I need
>>> help figuring out... well, more than one, but this is the top of the
>>> heap :) :
>>> We're a small company (<20 employees). Currently, our product
>>> consists of four distinct areas, each with 1-3 subject matter
>>> experts. Any given release involves work in all areas, some features
>>> overlap into multiple areas, but not always. Our developers are
>>> pretty flexible, but we have everything from kernel developers to
>>> Flash UI developers so individuals generally stick to their areas of
>>> expertise. From what I've read here and in other places, Scrum
>>> recommends that only one feature is developed at a time. So, my
>>> question is: how do I reconcile having four development silos with
>>> only developing one feature at a time? Do I manage four different
>>> scrums? One scrum, but allow multiple features to be developed at the
>>> same time (so long as they are in different silos)?
You still need to do the planning with all of them. My experience
shows that if you do not properly sync all these groups then you can
produce total c**p:). In my particular case the teams (4) were not
properly synced. They also worked on backend only, UI only, etc. At
the end it turned out that the Backend had a whole bunch of stuff that
the UI team did not even know about so there was no freakin UI for
it!!! :) And vice versa.
You just can't go without a good and synced release planning (as
Hubert says). And you do not have to fly everybody - just the experts
(i fly at least 3 times a year to the main company headquarters in
US). A good start is to focus on vertical slices - get rid of UI team,
Backend Team, etc. A single team should be able to do the Flash UI and
the underlying business logic (maybe not the kernel part:) ). Exchange
the experts for a month or two for training. It does not cost _that_
much. But the benefit is enormous.
Also the "product level demo" mentioned above is a very good idea. We
do it too. The whole team (all 4 individual teams spread across the
globe) get together (via e-conferencing - not physically together:) )
and each of the individual teams does a demo of what they did. This
helps in keeping everybody in sync.
On Oct 8, 10:20 am, Sudeep Pondala <sudeep.pond...@gmail.com> wrote:
> My Case is very Similar to what Mitch has, except that the Expertise Areas
> are spread across the world and "NO WAY" under on roof is possible and also
> All Four Groups Mastering other Expertise areas is a hughe Investment and
> also burdens the individuals a lot.
> > I'd start working hard to get the term "silos" out of the company. There
> > may be different specialist areas in your product, but only the combination
> > of the four make a product. I'd be release planning with all the 20 people,
> > plus the product folks, to lay out a good structure for a next release of
> > the overall product. In that session the team figures out when to pay
> > attention to what specialist area. Then the individual teams will run then
> > Sprints, and Sprint plan at the same time so they can figure out which
> > dependencies are appearing, and how to solve them. Keep builds running over
> > the product, not within a team. Keep tests running over the product, not the
> > team. Do your demos with the whole group, not per team.
> > On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com>wrote:
> >> Hi folks,
> >> A little background: I've been tasked with the tall order of reigning
> >> in the chaos that was my company's software development 'process' into
> >> something more rational and repeatable. I've long been interested in
> >> agile methods but have never had the opportunity to work with them
> >> directly. At the advice of a respected project manager colleague, I'm
> >> doing some serious investigations into Scrum and from what I've read
> >> on agile-software-development.com, it looks like something I can
> >> present to executives. There's just one nagging thing that I need
> >> help figuring out... well, more than one, but this is the top of the
> >> heap :) :
> >> We're a small company (<20 employees). Currently, our product
> >> consists of four distinct areas, each with 1-3 subject matter
> >> experts. Any given release involves work in all areas, some features
> >> overlap into multiple areas, but not always. Our developers are
> >> pretty flexible, but we have everything from kernel developers to
> >> Flash UI developers so individuals generally stick to their areas of
> >> expertise. From what I've read here and in other places, Scrum
> >> recommends that only one feature is developed at a time. So, my
> >> question is: how do I reconcile having four development silos with
> >> only developing one feature at a time? Do I manage four different
> >> scrums? One scrum, but allow multiple features to be developed at the
> >> same time (so long as they are in different silos)?
Thankfully, we are a small, co-located team - I can throw something at
the Flash team, back-end, and kernels team from where I sit . :) . And
despite the division of labour and the chaotic 'process' we have
today, the team does work very well together towards a common goal.
(I used the term "silos" only because the type of development each sub-
team does is so different)
I will definitely keep the team together for planning, but for the
moment, I will keep them on separate but synchronized sprints (except
where there are dependencies, of course). I do like the idea of the
cross-functional team, but that will be a longer term goal.
Thanks again!
Mitch.
On Oct 8, 4:34 am, Pavel Georgiev <pavel.vasilev.georg...@gmail.com>
wrote:
> You still need to do the planning with all of them. My experience
> shows that if you do not properly sync all these groups then you can
> produce total c**p:). In my particular case the teams (4) were not
> properly synced. They also worked on backend only, UI only, etc. At
> the end it turned out that the Backend had a whole bunch of stuff that
> the UI team did not even know about so there was no freakin UI for
> it!!! :) And vice versa.
> You just can't go without a good and synced release planning (as
> Hubert says). And you do not have to fly everybody - just the experts
> (i fly at least 3 times a year to the main company headquarters in
> US). A good start is to focus on vertical slices - get rid of UI team,
> Backend Team, etc. A single team should be able to do the Flash UI and
> the underlying business logic (maybe not the kernel part:) ). Exchange
> the experts for a month or two for training. It does not cost _that_
> much. But the benefit is enormous.
> Also the "product level demo" mentioned above is a very good idea. We
> do it too. The whole team (all 4 individual teams spread across the
> globe) get together (via e-conferencing - not physically together:) )
> and each of the individual teams does a demo of what they did. This
> helps in keeping everybody in sync.
> On Oct 8, 10:20 am, Sudeep Pondala <sudeep.pond...@gmail.com> wrote:
> > Hi Hubert,
> > I dint understand your Suggestion.
> > My Case is very Similar to what Mitch has, except that the Expertise Areas
> > are spread across the world and "NO WAY" under on roof is possible and also
> > All Four Groups Mastering other Expertise areas is a hughe Investment and
> > also burdens the individuals a lot.
> > > I'd start working hard to get the term "silos" out of the company. There
> > > may be different specialist areas in your product, but only the combination
> > > of the four make a product. I'd be release planning with all the 20 people,
> > > plus the product folks, to lay out a good structure for a next release of
> > > the overall product. In that session the team figures out when to pay
> > > attention to what specialist area. Then the individual teams will run then
> > > Sprints, and Sprint plan at the same time so they can figure out which
> > > dependencies are appearing, and how to solve them. Keep builds running over
> > > the product, not within a team. Keep tests running over the product, not the
> > > team. Do your demos with the whole group, not per team.
> > > On Wed, Oct 7, 2009 at 5:47 PM, Mitch O'Brien <michob2...@gmail.com>wrote:
> > >> Hi folks,
> > >> A little background: I've been tasked with the tall order of reigning
> > >> in the chaos that was my company's software development 'process' into
> > >> something more rational and repeatable. I've long been interested in
> > >> agile methods but have never had the opportunity to work with them
> > >> directly. At the advice of a respected project manager colleague, I'm
> > >> doing some serious investigations into Scrum and from what I've read
> > >> on agile-software-development.com, it looks like something I can
> > >> present to executives. There's just one nagging thing that I need
> > >> help figuring out... well, more than one, but this is the top of the
> > >> heap :) :
> > >> We're a small company (<20 employees). Currently, our product
> > >> consists of four distinct areas, each with 1-3 subject matter
> > >> experts. Any given release involves work in all areas, some features
> > >> overlap into multiple areas, but not always. Our developers are
> > >> pretty flexible, but we have everything from kernel developers to
> > >> Flash UI developers so individuals generally stick to their areas of
> > >> expertise. From what I've read here and in other places, Scrum
> > >> recommends that only one feature is developed at a time. So, my
> > >> question is: how do I reconcile having four development silos with
> > >> only developing one feature at a time? Do I manage four different
> > >> scrums? One scrum, but allow multiple features to be developed at the
> > >> same time (so long as they are in different silos)?
|
