[SCRUMDEVELOPMENT] Yet Another New Product Development Game?

[Gercel Silva [e-mail] [SCRUMDEVELOPMENT]]

Hi, folks!




I’ve been trying for over a year to equate Agile and Lean Thinking with
other ideas and knowledge areas of product development. From my point of
view agile and lean are essentially about product development but it’s been
really hard to argue this to people from other areas, specially UX Design
and some Product Managers.




Designers (at least the ones I work with) seem to focus much more on the
differences between Agile and Design Thinking than on their similarities
(which I think are numerous). The aspects that I’m having more trouble with
designers relate to: a) being on the same team as developers; b) sharing
responsibility for the whole product/process; and c) specialty vs
multidisciplinarity




In *The New New Product Development Game (1986)
<https://hbr.org/1986/01/the-new-new-product-development-game>*, Takeuchi
and Nonaka talk about how product development was like at big successful
multinational companies. It is a great inspiration to me but I haven’t
found any recent examples that play the game like they said. I took a few
paragraphs from the article to illustrate my points. I would love to know
if there is a *Yet Another New Product Development Game* that I’m unaware
of.




a) Begin on the same team as developers




*‘Under the rugby approach, the product development process emerges from
the constant interaction of a hand-picked, multidisciplinary team whose
members work together from start to finish.’ (Takeuchi & Nonaka, 1986)*




I’ve heard time and again from designers and non-designers that ‘designers
want to work with designers’. At my company we have two design ‘teams’:
Web/Graphic Designers and UX Designers. Everyone in both of these ‘teams’
prefer working in a waterfall fashion where their specialized group
produces artifacts which are then consumed by a real multidisciplinary
Scrum development team responsible for everything from then on (get the
features to production).




So my questions to you guys are: have you ever worked with a real
multidisciplinary team including every specialty needed to deliver a
product on the same team (designers)? How did that work for you? What works
and what doesn’t? Is it something worth fighting for? How designers feel
about it? How can I get designers to believe in this model?







I won’t address aspects b) and c) for now so we can focus on aspect a)






Any help is very welcome!

[Kurt Häusler [e-mail] [SCRUMDEVELOPMENT]]

Hi,

I have worked on mostly true multi-disciplinary or cross functional teams
in small to medium sized product companies and service providers. These
teams usually included business people, developers and when applicable,
graphics designers. This usually worked fine. The designers did their bit
and the developers did theirs and everything worked fine. Actually going
back and remembering the best example, I remember one challenge with the
agile approach that was quickly resolved. The software developers were
happy with delivering a series of small features one after the other, but
the designer felt that he needed a lot of time to get the (single, non
feature specific) design right for the first feature, then every feature
after that would be relatively easy. If you remember though, agile is both
iterative and incremental, and this is a good example of the difference
between them. Designers don't develop one small design after another, they
should think incrementally and come up with an ugly but functional design
for the first features, and slowly improve the global design over time.

Actually at the moment for the first time I am working on a team that is
not cross functional. In this case we have lots of business people,
architects, mainframe developers, cms guys, etc outside the team, but at
least we have UI guys and developers on the same teams, and they do work in
a combination of "series of small features" as well as a "slowly improving
the global design" way.

Post by Gercel Silva ***@gmail.com [SCRUMDEVELOPMENT]
Hi, folks!
I’ve been trying for over a year to equate Agile and Lean Thinking with
other ideas and knowledge areas of product development. From my point of
view agile and lean are essentially about product development but it’s been
really hard to argue this to people from other areas, specially UX Design
and some Product Managers.
Designers (at least the ones I work with) seem to focus much more on the
differences between Agile and Design Thinking than on their similarities
(which I think are numerous). The aspects that I’m having more trouble with
designers relate to: a) being on the same team as developers; b) sharing
responsibility for the whole product/process; and c) specialty vs
multidisciplinarity
In *The New New Product Development Game (1986)
<https://hbr.org/1986/01/the-new-new-product-development-game>*, Takeuchi
and Nonaka talk about how product development was like at big successful
multinational companies. It is a great inspiration to me but I haven’t
found any recent examples that play the game like they said. I took a few
paragraphs from the article to illustrate my points. I would love to know
if there is a *Yet Another New Product Development Game* that I’m unaware
of.
a) Begin on the same team as developers
*‘Under the rugby approach, the product development process emerges from
the constant interaction of a hand-picked, multidisciplinary team whose
members work together from start to finish.’ (Takeuchi & Nonaka, 1986)*
I’ve heard time and again from designers and non-designers that
‘designers want to work with designers’. At my company we have two design
‘teams’: Web/Graphic Designers and UX Designers. Everyone in both of these
‘teams’ prefer working in a waterfall fashion where their specialized group
produces artifacts which are then consumed by a real multidisciplinary
Scrum development team responsible for everything from then on (get the
features to production).
So my questions to you guys are: have you ever worked with a real
multidisciplinary team including every specialty needed to deliver a
product on the same team (designers)? How did that work for you? What works
and what doesn’t? Is it something worth fighting for? How designers feel
about it? How can I get designers to believe in this model?
I won’t address aspects b) and c) for now so we can focus on aspect a)
Any help is very welcome!

[Adrian Howard [e-mail] [SCRUMDEVELOPMENT]]

Hi Gercel,

On 19 Jan 2015, at 19:32, Gercel Silva ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
[snip]

Designers (at least the ones I work with) seem to focus much more on the differences between Agile and Design Thinking than on their similarities (which I think are numerous). The aspects that I’m having more trouble with designers relate to: a) being on the same team as developers; b) sharing responsibility for the whole product/process; and c) specialty vs multidisciplinarity
In The New New Product Development Game (1986) <https://hbr.org/1986/01/the-new-new-product-development-game>, Takeuchi and Nonaka talk about how product development was like at big successful multinational companies. It is a great inspiration to me but I haven’t found any recent examples that play the game like they said. I took a few paragraphs from the article to illustrate my points. I would love to know if there is a Yet Another New Product Development Game that I’m unaware of.

[snip]

So my questions to you guys are: have you ever worked with a real multidisciplinary team including every specialty needed to deliver a product on the same team (designers)?

Yes. Several times.

How did that work for you?

Jolly well.

What works and what doesn’t? Is it something worth fighting for? How designers feel about it? How can I get designers to believe in this model?

You might want to poke a bit around the Lean UX community. They’ve been poking around mashing up Lean, UX, Agile, Lean Startup & Design Thinking for a few years now. And a bunch of folk have successfully been getting Agile & UX folk to play nice together for a while. You might find some of the pointers at the end of this deck of use:

http://www.slideshare.net/adrianh/fundamentals-of-lean-ux-agile-on-the-beach-2014/131 <http://www.slideshare.net/adrianh/fundamentals-of-lean-ux-agile-on-the-beach-2014/131>

The Balanced Team community especially has a bunch of folk playing in that space (balancedteam.org <http://balancedteam.org/>).

Cheers,

Adrian

[Mikael Brodd [e-mail] [SCRUMDEVELOPMENT]]

Hi,

I have worked in several teams where UX has been part of the team. And that
works great! I believe that really having all competences needed to deliver
in the team gives great benefits, especially in communication and
understanding.

If you develop something in your own corner of the company, and then dump
it on a couple of teams and say "implement this", it isn't certain that it
will be gladly accepted without fuss. It will definitely not foster
teamwork :) And it doesn't matter if the subject is software architecture,
a design or test specifications, or what not. And for instance, many
"programmers", especially front-end developers, have some knowledge about
UX and can actually add something useful to a conversation about UX.

Agile is much about maximizing brain power. Utilize all the knowledge from
those involved in the product, not only from some. And if we develop our
product empirically, why shouldn't we do the same with the look and feel of
it?

Another tool that I think is useful here is to make a value stream map of
the development of your products. Mapping out the different steps that a
product needs to go through before being able to be released shows the lead
time from idea to delivery. Having a step that says "Finish the ultimate
Look and Feel" much likely adds more lead time on top of your time to
market, than if you could add the UX-specialists to the team and
iteratively and incrementally develop this.

Having shown this value stream map, it is often quite easy to at least
convince of trying it out for a period of time.

Check out Lean UX and especially Agile UX. Agile UX focuses more on the
cooperation part.

Good Luck!

-Mikael Brodd

[Gercel Silva [e-mail] [SCRUMDEVELOPMENT]]

Thanks everyone for your replies!






@Adrian and @Mikael


I've been studying Lean UX for about six months now and I love it! I've
heard of Agile UX, but haven't studied that yet. Can you guys point me to
some good references on those topics?






The Balanced Team community seems to be exactly what I am looking for!
Thanks a lot for that reference!






I have also tried value-stream mapping, but I didn't know much about UX
disciplines and had little collaboration from them on this. Maybe it's time
to try again! :)






@Kurt



Yeah, here we had the same challenge with designers missing a Big Design Up
Front, for the whole product. We addressed this concern by having a longer
ideation/inception phase, prior to writing a backlog.










Now let’s get a little deeper!






The idea of everyone in the same team seems a little easier to implement at
smaller companies. But when you look at bigger companies that have worked
with specialty silos for years it gets trickier! I think that
transformation is the biggest challenge.






At my present company we had a "Usability Team" that for years provided
specs and wireframes to every development team. They recently rebranded
themselves to "UX Design Team" and started focusing more on 'ideation'
(brainstorms, design studios). They recognize that it is very important
that developers participate in ideation, but not the other way around
(designers participating in development).






A couple of years ago we had a mission so challenging that we were forced
to change things a bit. The waterfall approach to designing and developing
caused too many delays, so we changed it. The designers were introduced to
the development teams and started participating in Scrum Events such as the
daily meetings, plannings, reviews and retrospectives. However, the "UX
Design Team" was always a bigger priority for them. Here are some examples:






1) They rejected the idea of being dedicated to a single team. They prefer
that every designer be involved in every product being developed.
Ultimately they chose two teams for each designer, but soon they started
'sharing' those teams with at least one other designer.






2) They strongly opposed sitting with the development teams they were
supposed to be part of. Sitting with the "UX Design Team" is much more
important for them.






3) They neglected any meeting that took place at the same time of a "UX
Design Team" meeting, or any other activity not related to the teams they
should be working with. This included not showing up at retrospectives
where the main theme was UX.






What is worse, these problems come in double! Most of what I said (except
for behavior 3) happened the same way with the "Graphics Design Team". They
also reject being dedicated and sitting together, but at least they commit
to the team's meetings. They come, create design and leave, saying that 'my
part is over'. Shouldn't everyone's part be delivering working products?






Our "Graphics Design Team" produces landing pages that often require
back-end and front-end programming. I tried showing them that their team
isn't fully capable of delivering but they don't mind. Actually, when
offered the possibility of having a programmer as part of the team they
refused it. They think their team should be made of designers only, and
that management should interrupt the Scrum teams to allocate a programmer
when they need it (the same way they are 'allocated' to the teams when
design is needed).






It is really hard trying to get a multidisciplinary team to self-organize
around work, not around their specialties. But we got our Scrum teams to do
that. How can I get designers to the same level of collaboration and
commitment?






Has anybody had similar problems? What can be done in those situations?




Thank you very much for helping me! :)

Post by Mikael Brodd ***@gmail.com [SCRUMDEVELOPMENT]
Hi,
I have worked in several teams where UX has been part of the team. And
that works great! I believe that really having all competences needed to
deliver in the team gives great benefits, especially in communication and
understanding.
If you develop something in your own corner of the company, and then dump
it on a couple of teams and say "implement this", it isn't certain that it
will be gladly accepted without fuss. It will definitely not foster
teamwork :) And it doesn't matter if the subject is software architecture,
a design or test specifications, or what not. And for instance, many
"programmers", especially front-end developers, have some knowledge about
UX and can actually add something useful to a conversation about UX.
Agile is much about maximizing brain power. Utilize all the knowledge from
those involved in the product, not only from some. And if we develop our
product empirically, why shouldn't we do the same with the look and feel of
it?
Another tool that I think is useful here is to make a value stream map of
the development of your products. Mapping out the different steps that a
product needs to go through before being able to be released shows the lead
time from idea to delivery. Having a step that says "Finish the ultimate
Look and Feel" much likely adds more lead time on top of your time to
market, than if you could add the UX-specialists to the team and
iteratively and incrementally develop this.
Having shown this value stream map, it is often quite easy to at least
convince of trying it out for a period of time.
Check out Lean UX and especially Agile UX. Agile UX focuses more on the
cooperation part.
Good Luck!
-Mikael Brodd

[Adrian Howard [e-mail] [SCRUMDEVELOPMENT]]

On 26 Jan 2015, at 19:28, Gercel Silva ***@gmail.com [SCRUMDEVELOPMENT] <***@yahoogroups.com> wrote:
[snip]

I've been studying Lean UX for about six months now and I love it! I've heard of Agile UX, but haven't studied that yet. Can you guys point me to some good references on those topics?

[snip]

I’m not as anal at keeping it up to date any more, so this misses a bunch of more recent stuff, but some of the links under

https://pinboard.in/u:adrianh/t:agile+ux

will probably be of interest.

The books with "Agile" and "UX" in the title listed on http://www.slideshare.net/adrianh/fundamentals-of-lean-ux-agile-on-the-beach-2014/135 would be another place to look.

There’s been an UX track at the Agile 20XX conference since 2008. Looking at the decks from previous years will give you some pointers. Digging into the archives of https://groups.yahoo.com/neo/groups/agile-usability/info will probably get you some useful discussion too.

Cheers,

Adrian