Design Thinking and Scrum

[Gercel Silva]

Hi,



Can you guys share your experiences implementing Design Thinking and Scrum
together?


Some colleagues have been asking me about this for a couple of weeks and
I'm researching to know what options we have. From what I've read so far DT
seems fairly aligned with agile principles at several points. However I
found a few things that got me puzzled.


As an activity focused on user experience and the user's real needs,
Design Thinking takes place somewhat prior to the creation of User
Stories/PBI's. Often user stories are created as a result of this activity.
This looks a lot like backlog refinement to me. Questioning if a feature is
really necessary and focusing on the value it offers to the end-user, two
things found in Design Thinking, can be directly mapped to lean principles
(which I understand a little better than DT).



But here is what I don't get. I don't think this is a rule of Design
Thinking, but I found some people suggesting that you have a *Design
Thinking Team that is separated from the Development Team*. Both 'teams'
would share the same Product Owner and Scrum Master. This doesn't seem to
be a good idea for me because the Development Team would not be fully
cross-functional (have all the competencies needed to create a potentially
shippable increment of the product). Also, making this separation could
have a negative impact on collaboration and shared commitment between both
teams. What do you guys think?



Do you have any other tips or research material I could look into?



Thanks!

Gercel Silva

[Andrew Burrows]

Hey Gercel, do you know what problem your colleagues are hoping Design
Thinking will solve?

Post by Gercel Silva
Hi,
Can you guys share your experiences implementing Design Thinking and Scrum
together?
Some colleagues have been asking me about this for a couple of weeks and
I'm researching to know what options we have. From what I've read so far DT
seems fairly aligned with agile principles at several points. However I
found a few things that got me puzzled.
As an activity focused on user experience and the user's real needs,
Design Thinking takes place somewhat prior to the creation of User
Stories/PBI's. Often user stories are created as a result of this activity.
This looks a lot like backlog refinement to me. Questioning if a feature is
really necessary and focusing on the value it offers to the end-user, two
things found in Design Thinking, can be directly mapped to lean principles
(which I understand a little better than DT).
But here is what I don't get. I don't think this is a rule of Design
Thinking, but I found some people suggesting that you have a *Design
Thinking Team that is separated from the Development Team*. Both 'teams'
would share the same Product Owner and Scrum Master. This doesn't seem to
be a good idea for me because the Development Team would not be fully
cross-functional (have all the competencies needed to create a potentially
shippable increment of the product). Also, making this separation could
have a negative impact on collaboration and shared commitment between both
teams. What do you guys think?
Do you have any other tips or research material I could look into?
Thanks!
Gercel Silva

[Gercel Silva]

Hey, Andrew!

Thanks for your response. I'm sorry for taking this long to reply (I was on
vacation and not able to get a good answer for your question).

My colleagues think that DT could solve the problem of addressing User
Experience concerns more properly than what we do right now.

We've tried running a few projects with no up-front thinking before
starting the first Sprint, leaving everything regarding UX to be decided by
the sprinting team. One problem we saw with this approach was that some
user stories that had been selected by the team during Sprint Planning
ended up either being cancelled or changed dramatically as a result of UX
work. Our UX specialists would think about the problem that needed solving
for a given story and come up with something a lot different from what was
originally intended.

I think maybe our real problem is related to how we create our user
stories. We do have backlog Refinement meetings that the whole DevTeam and
Product Owner attend to. But since refinement shouldn't take more than 10%
of the Sprint's timebox our UX specialists don't think there is enough time
to explore the problem and alternatives to user experience. Also, they feel
more confortable sharing this work with other UX'ers that are not members
of that particular DevTeam.

As a result, we are experimenting with a process that has an explicit
'thinking' phase which takes place before the project vision is fully
consolidated. Some call it 'ideation', others call it something else but
the naming doesn't concern me as much as what is (and should be) actually
happening. The goal of this phase is to come up with several possible
solutions (sketches, not prototypes) to ensure that we choose the
alternative that provides the best user experience. The DevTeam is involved
in this phase, but others are also invited to help.

I have advised everyone involved to be careful with 'early decisions' and
to delay important decisions until the last responsible moment.

Are there any experiences you could share?

Thanks,
Gercel

Post by Andrew Burrows
Hey Gercel, do you know what problem your colleagues are hoping Design
Thinking will solve?

Post by Gercel Silva
Hi,
Can you guys share your experiences implementing Design Thinking and
Scrum together?
Some colleagues have been asking me about this for a couple of weeks and
I'm researching to know what options we have. From what I've read so far DT
seems fairly aligned with agile principles at several points. However I
found a few things that got me puzzled.
As an activity focused on user experience and the user's real needs,
Design Thinking takes place somewhat prior to the creation of User
Stories/PBI's. Often user stories are created as a result of this activity.
This looks a lot like backlog refinement to me. Questioning if a feature is
really necessary and focusing on the value it offers to the end-user, two
things found in Design Thinking, can be directly mapped to lean principles
(which I understand a little better than DT).
But here is what I don't get. I don't think this is a rule of Design
Thinking, but I found some people suggesting that you have a *Design
Thinking Team that is separated from the Development Team*. Both
'teams' would share the same Product Owner and Scrum Master. This doesn't
seem to be a good idea for me because the Development Team would not be
fully cross-functional (have all the competencies needed to create a
potentially shippable increment of the product). Also, making this
separation could have a negative impact on collaboration and shared
commitment between both teams. What do you guys think?
Do you have any other tips or research material I could look into?
Thanks!
Gercel Silva

[Flavius Ștef]

Hi Gercel,

You might want to look into Lean UX -- it it based on agile, lean startup
and design thinking. One entry point might be this:
http://www.jeffgothelf.com/blog/. As I understand it, its proponents
advocate collaborative design (whole team) led by the UX experts, focus on
outcomes over deliverables and rapid prototyping. An interesting idea is to
run design studios as a team at the beginning of each sprint.

Hope it helps,
Flavius

Post by Gercel Silva
Hey, Andrew!
Thanks for your response. I'm sorry for taking this long to reply (I was
on vacation and not able to get a good answer for your question).
My colleagues think that DT could solve the problem of addressing User
Experience concerns more properly than what we do right now.
We've tried running a few projects with no up-front thinking before
starting the first Sprint, leaving everything regarding UX to be decided by
the sprinting team. One problem we saw with this approach was that some
user stories that had been selected by the team during Sprint Planning
ended up either being cancelled or changed dramatically as a result of UX
work. Our UX specialists would think about the problem that needed solving
for a given story and come up with something a lot different from what was
originally intended.
I think maybe our real problem is related to how we create our user
stories. We do have backlog Refinement meetings that the whole DevTeam and
Product Owner attend to. But since refinement shouldn't take more than 10%
of the Sprint's timebox our UX specialists don't think there is enough time
to explore the problem and alternatives to user experience. Also, they feel
more confortable sharing this work with other UX'ers that are not members
of that particular DevTeam.
As a result, we are experimenting with a process that has an explicit
'thinking' phase which takes place before the project vision is fully
consolidated. Some call it 'ideation', others call it something else but
the naming doesn't concern me as much as what is (and should be) actually
happening. The goal of this phase is to come up with several possible
solutions (sketches, not prototypes) to ensure that we choose the
alternative that provides the best user experience. The DevTeam is involved
in this phase, but others are also invited to help.
I have advised everyone involved to be careful with 'early decisions' and
to delay important decisions until the last responsible moment.
Are there any experiences you could share?
Thanks,
Gercel

Post by Andrew Burrows
Hey Gercel, do you know what problem your colleagues are hoping Design
Thinking will solve?

Post by Gercel Silva
Hi,
Can you guys share your experiences implementing Design Thinking and
Scrum together?
Some colleagues have been asking me about this for a couple of weeks and
I'm researching to know what options we have. From what I've read so far DT
seems fairly aligned with agile principles at several points. However I
found a few things that got me puzzled.
As an activity focused on user experience and the user's real needs,
Design Thinking takes place somewhat prior to the creation of User
Stories/PBI's. Often user stories are created as a result of this activity.
This looks a lot like backlog refinement to me. Questioning if a feature is
really necessary and focusing on the value it offers to the end-user, two
things found in Design Thinking, can be directly mapped to lean principles
(which I understand a little better than DT).
But here is what I don't get. I don't think this is a rule of Design
Thinking, but I found some people suggesting that you have a *Design
Thinking Team that is separated from the Development Team*. Both
'teams' would share the same Product Owner and Scrum Master. This doesn't
seem to be a good idea for me because the Development Team would not be
fully cross-functional (have all the competencies needed to create a
potentially shippable increment of the product). Also, making this
separation could have a negative impact on collaboration and shared
commitment between both teams. What do you guys think?
Do you have any other tips or research material I could look into?
Thanks!
Gercel Silva

[George Dinwiddie]

Gercel,

Post by Gercel Silva
Hey, Andrew!
Thanks for your response. I'm sorry for taking this long to reply (I was
on vacation and not able to get a good answer for your question).
My colleagues think that DT could solve the problem of addressing User
Experience concerns more properly than what we do right now.
We've tried running a few projects with no up-front thinking before
starting the first Sprint, leaving everything regarding UX to be decided
by the sprinting team. One problem we saw with this approach was that
some user stories that had been selected by the team during Sprint
Planning ended up either being cancelled or changed dramatically as a
result of UX work. Our UX specialists would think about the problem that
needed solving for a given story and come up with something a lot
different from what was originally intended.
I think maybe our real problem is related to how we create our user
stories. We do have backlog Refinement meetings that the whole DevTeam
and Product Owner attend to. But since refinement shouldn't take more
than 10% of the Sprint's timebox our UX specialists don't think there is
enough time to explore the problem and alternatives to user experience.
Also, they feel more confortable sharing this work with other UX'ers
that are not members of that particular DevTeam.
As a result, we are experimenting with a process that has an explicit
'thinking' phase which takes place before the project vision is fully
consolidated. Some call it 'ideation', others call it something else but
the naming doesn't concern me as much as what is (and should be)
actually happening. The goal of this phase is to come up with several
possible solutions (sketches, not prototypes) to ensure that we choose
the alternative that provides the best user experience. The DevTeam is
involved in this phase, but others are also invited to help.
I have advised everyone involved to be careful with 'early decisions'
and to delay important decisions until the last responsible moment.
Are there any experiences you could share?

Rather than a phase, consider just making it an activity. Dual track
agile (http://comakewith.us/dual-track-scrum-brief/) does this to great
effect. This keeps both the product discovery and product delivery
processes in gear all the time, with each learning from the other, and
all on the same team. My current client is doing treat things with this.

- George

[Adrian Howard]

Hi George,

On 20 Jan 2014, at 03:02, George Dinwiddie <***@idiacomputing.com> wrote:
[snip]

Post by George Dinwiddie
Rather than a phase, consider just making it an activity. Dual track
agile (http://comakewith.us/dual-track-scrum-brief/) does this to great
effect. This keeps both the product discovery and product delivery
processes in gear all the time, with each learning from the other, and
all on the same team. My current client is doing treat things with this.

I’m all for having UX/research work be a continual activity - but I’ve seen some fairly common anti-patterns when people try and adopt duel track - so I think it’s something to be careful with. In particular:

* The cadence of the research processes don’t always match up with the cadences of the development sprints

* People often seem to misinterpret the stuff that Desirée et al talked about as having a separate team, rather than a separate stream of activity. Leading to some terrible siloing and subsequent annoyances…

* It can put a lot of pressure on limited design resources where the same group of folk are trying to help with the current development work, assess the previous sprint, and look ahead to the next - all at the same time.

Not saying it can’t be done - but it is tricky in many orgs. Especially without finding more UX/design-ish people than many organisations seem comfortable having on a product team.

Cheers,

Adrian

[George Dinwiddie]

Adrian,

Post by Adrian Howard
Hi George,
[snip]

Post by George Dinwiddie
Rather than a phase, consider just making it an activity. Dual track
agile (http://comakewith.us/dual-track-scrum-brief/) does this to great
effect. This keeps both the product discovery and product delivery
processes in gear all the time, with each learning from the other, and
all on the same team. My current client is doing treat things with this.

I’m all for having UX/research work be a continual activity - but
I’ve seen some fairly common anti-patterns when people try and adopt
duel track - so I think it’s something to be careful with. In
* The cadence of the research processes don’t always match up with
the cadences of the development sprints

These teams are doing the product discovery more in a kanban fashion
than a scrum fashion. There's no expectation to discover a specific
amount of product in a particular sprint.

Is that what you mean?

Post by Adrian Howard
* People often seem to misinterpret the stuff that Desirée et al
talked about as having a separate team, rather than a separate stream
of activity. Leading to some terrible siloing and subsequent
annoyances…

Here it's all in one team, though there are strong specialties. The
teams that work closest do the best.

Post by Adrian Howard
* It can put a lot of pressure on limited design resources where the
same group of folk are trying to help with the current development
work, assess the previous sprint, and look ahead to the next - all at
the same time.

Shouldn't everyone be doing that, not just "design resources?" Or are
you talking about people who aren't dedicated to the team's work?

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

Yes, if orgs don't practice it, it doesn't work very well.

- George

[Adrian Howard]

Hi George,

On 20 Jan 2014, at 17:06, George Dinwiddie <***@idiacomputing.com> wrote:

[snip]

Post by George Dinwiddie

Post by Adrian Howard
* The cadence of the research processes don’t always match up with
the cadences of the development sprints

These teams are doing the product discovery more in a kanban fashion
than a scrum fashion. There's no expectation to discover a specific
amount of product in a particular sprint.
Is that what you mean?

[snip]

Basically.

There are some activities that fit very well within a sprint-based structure. Doing usability tests of products under development, doing interaction design around new features, and so forth. These fit nicely into the kind of sprint-ahead / sprint-behind structure of dual track scrum.

Other activities fit less well. For example a diary study that happens over several months, or ongoing user interviewing activities, etc.

Does that make sense?

Post by George Dinwiddie

Post by Adrian Howard
* People often seem to misinterpret the stuff that Desirée et al
talked about as having a separate team, rather than a separate stream
of activity. Leading to some terrible siloing and subsequent
annoyances…

Here it's all in one team, though there are strong specialties. The
teams that work closest do the best.

Absolutely. It just one of the most common mis-implementations of this approach that I encounter. It’s a very easy one for groups that have separate UX groups to move to.

Post by George Dinwiddie

Post by Adrian Howard
* It can put a lot of pressure on limited design resources where the
same group of folk are trying to help with the current development
work, assess the previous sprint, and look ahead to the next - all at
the same time.

Shouldn't everyone be doing that, not just "design resources?" Or are
you talking about people who aren’t dedicated to the team's work?

Yes - everybody should be involved in it. But in most teams there will be some folk who are subject experts who will help lead and facilitate the work.

By having the evaluation of the UX of the previous sprint in the next sprint also extends the feedback loop. If a story doesn’t deliver a great experience you should find that out during that story’s sprint - not wait until the next one.

To draw an analogy: Imagine that folk suggested dual-track-testing was the best way to integrate testing practices and skills within a scrum team where during the sprint people would:

* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

This, to me, sounds like it would make put the team members who have more testing skills under considerable pressure and detract from the work done in the current sprint - and increases the length of the feedback loop.

Post by George Dinwiddie

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off well, and I think I’ve seen more folk fail than succeed at it. Mostly due to the issue of people trying to do three things at once.

I’ve personally had more success with sprint-based teams in extending the scope of the sprint to include more discover at the start, and more evaluation at the end rather than trying to overlap everything. It makes it much easier for the experts to spend more time facilitating the rest of the team in the areas they’re less familiar with.

Cheers,

Adrian

[George Dinwiddie]

Adrian,

Post by Adrian Howard
Hi George,
[snip]

Post by George Dinwiddie

Post by Adrian Howard
* The cadence of the research processes don’t always match up with
the cadences of the development sprints

These teams are doing the product discovery more in a kanban fashion
than a scrum fashion. There's no expectation to discover a specific
amount of product in a particular sprint.
Is that what you mean?

[snip]
Basically.
There are some activities that fit very well within a sprint-based
structure. Doing usability tests of products under development, doing
interaction design around new features, and so forth. These fit
nicely into the kind of sprint-ahead / sprint-behind structure of
dual track scrum.
Other activities fit less well. For example a diary study that
happens over several months, or ongoing user interviewing activities,
etc.

Yes, the teams I'm working with would divide those into discrete
activities. They would share their findings at the Sprint Review, and
might possibly change the direction or discontinue as they see fit.

Post by Adrian Howard
Does that make sense?

Post by George Dinwiddie

Post by Adrian Howard
* People often seem to misinterpret the stuff that Desirée et al
talked about as having a separate team, rather than a separate stream
of activity. Leading to some terrible siloing and subsequent
annoyances…

Here it's all in one team, though there are strong specialties. The
teams that work closest do the best.

Absolutely. It just one of the most common mis-implementations of
this approach that I encounter. It’s a very easy one for groups that
have separate UX groups to move to.

Post by George Dinwiddie

Post by Adrian Howard
* It can put a lot of pressure on limited design resources where the
same group of folk are trying to help with the current development
work, assess the previous sprint, and look ahead to the next - all at
the same time.

Shouldn't everyone be doing that, not just "design resources?" Or are
you talking about people who aren’t dedicated to the team's work?

Yes - everybody should be involved in it. But in most teams there
will be some folk who are subject experts who will help lead and
facilitate the work.
By having the evaluation of the UX of the previous sprint in the next
sprint also extends the feedback loop. If a story doesn’t deliver a
great experience you should find that out during that story’s sprint
- not wait until the next one.

If you're talking about evaluation by the UX experts, that happens as
things are being built. If you're talking about measuring use after
deployment, that would follow.

Post by Adrian Howard
To draw an analogy: Imagine that folk suggested dual-track-testing
was the best way to integrate testing practices and skills within a
* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

Testing code a sprint late is a horrible idea. I don't think it's
comparable to most UX work, either. That's inserting delay after
deciding what to build, and before delivering it. This is the innermost
loop. Delay there is a killer.

Delay in deciding what to build is less of a problem, and may be quite
appropriate. Delay in determining if what was built is accepted by the
users is also less of a problem, and must necessarily happen after
deployment.

Using feature switches is a great tool. There have been times where a
new feature has been turned off in short order. Some have even been
deployed "dark," though more due to internal politics than UX discoveries.

Post by Adrian Howard
This, to me, sounds like it would make put the team members who have
more testing skills under considerable pressure and detract from the
work done in the current sprint - and increases the length of the
feedback loop.

In my experience testers can
- test new functionality as it's built (same sprint)
- help plan the acceptance tests for the next sprint
without much problem if they're included in the process from the
beginning. Using the Three Amigos Process and Given-When-Then to express
the acceptance scenarios necessary to verify a story makes this pretty
simple. See http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_1111/#/19

Making sure the current sprint's code is testable is accomplished by
testing it. If it's not testable, it's not tested, and therefore not
done. Having determined the scenarios up front greatly helps this
process, also.

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

There are many things that orgs do poorly, but I don't think that means
they're tricky. And if an org scrimps on UX people, then they're going
to do less in terms of UX. That's OK. They don't have to succeed. :-)

Post by Adrian Howard

Post by George Dinwiddie
Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off
well, and I think I’ve seen more folk fail than succeed at it. Mostly
due to the issue of people trying to do three things at once.

OK, I haven't seen them fail because they're trying to do three things
at once. I've seen many fail in many ways, but it's not because the work
is too hard to do. I find there's always necessary overlap between
building the immediate need, and preparing for the future development.

Post by Adrian Howard
I’ve personally had more success with sprint-based teams in extending
the scope of the sprint to include more discover at the start, and
more evaluation at the end rather than trying to overlap everything.
It makes it much easier for the experts to spend more time
facilitating the rest of the team in the areas they’re less familiar
with.

So what do the developers do while the UX people are discovering at the
start of the sprint?

- George

[Michael Vizdos]

Question.

How is UX different or more special than any other speciality on a team?

I see this with (insert my speciality here) when teams start forming, get
into storiming (sometimes blame), and then as a team moves from individuals
to a norming and high performance team of people they figure out together
what is needed to #deliver.

I am happy to see UX getting involved in the discussions with teams. It
shows that scrum truly does bring up tough conversations that, in the past,
has just been accepted in a system environment.

I appreciate learning more in this thread.

Thank you.

Mike Vizdos
www.michaelvizdos.com/contact

Post by George Dinwiddie
Adrian,

Post by Adrian Howard
Hi George,
[snip]

Post by George Dinwiddie

* The cadence of the research processes don’t always match up with
the cadences of the development sprints

These teams are doing the product discovery more in a kanban fashion
than a scrum fashion. There's no expectation to discover a specific
amount of product in a particular sprint.
Is that what you mean?

[snip]
Basically.
There are some activities that fit very well within a sprint-based
structure. Doing usability tests of products under development, doing
interaction design around new features, and so forth. These fit
nicely into the kind of sprint-ahead / sprint-behind structure of
dual track scrum.
Other activities fit less well. For example a diary study that
happens over several months, or ongoing user interviewing activities,
etc.

Yes, the teams I'm working with would divide those into discrete
activities. They would share their findings at the Sprint Review, and
might possibly change the direction or discontinue as they see fit.

Post by Adrian Howard
Does that make sense?

Post by George Dinwiddie

* People often seem to misinterpret the stuff that Desirée et al
talked about as having a separate team, rather than a separate stream
of activity. Leading to some terrible siloing and subsequent
annoyances…

Here it's all in one team, though there are strong specialties. The
teams that work closest do the best.

Absolutely. It just one of the most common mis-implementations of
this approach that I encounter. It’s a very easy one for groups that
have separate UX groups to move to.

Post by George Dinwiddie

* It can put a lot of pressure on limited design resources where the
same group of folk are trying to help with the current development
work, assess the previous sprint, and look ahead to the next - all at
the same time.

Shouldn't everyone be doing that, not just "design resources?" Or are
you talking about people who aren’t dedicated to the team's work?

Yes - everybody should be involved in it. But in most teams there
will be some folk who are subject experts who will help lead and
facilitate the work.
By having the evaluation of the UX of the previous sprint in the next
sprint also extends the feedback loop. If a story doesn’t deliver a
great experience you should find that out during that story’s sprint
- not wait until the next one.

If you're talking about evaluation by the UX experts, that happens as
things are being built. If you're talking about measuring use after
deployment, that would follow.

Post by Adrian Howard
To draw an analogy: Imagine that folk suggested dual-track-testing
was the best way to integrate testing practices and skills within a
* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

Testing code a sprint late is a horrible idea. I don't think it's
comparable to most UX work, either. That's inserting delay after
deciding what to build, and before delivering it. This is the innermost
loop. Delay there is a killer.
Delay in deciding what to build is less of a problem, and may be quite
appropriate. Delay in determining if what was built is accepted by the
users is also less of a problem, and must necessarily happen after
deployment.
Using feature switches is a great tool. There have been times where a
new feature has been turned off in short order. Some have even been
deployed "dark," though more due to internal politics than UX discoveries.

Post by Adrian Howard
This, to me, sounds like it would make put the team members who have
more testing skills under considerable pressure and detract from the
work done in the current sprint - and increases the length of the
feedback loop.

In my experience testers can
- test new functionality as it's built (same sprint)
- help plan the acceptance tests for the next sprint
without much problem if they're included in the process from the
beginning. Using the Three Amigos Process and Given-When-Then to express
the acceptance scenarios necessary to verify a story makes this pretty
simple. See http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_1111/#/19
Making sure the current sprint's code is testable is accomplished by
testing it. If it's not testable, it's not tested, and therefore not
done. Having determined the scenarios up front greatly helps this
process, also.

Post by Adrian Howard

Post by George Dinwiddie

Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

There are many things that orgs do poorly, but I don't think that means
they're tricky. And if an org scrimps on UX people, then they're going
to do less in terms of UX. That's OK. They don't have to succeed. :-)

Post by Adrian Howard

Post by George Dinwiddie
Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off
well, and I think I’ve seen more folk fail than succeed at it. Mostly
due to the issue of people trying to do three things at once.

OK, I haven't seen them fail because they're trying to do three things
at once. I've seen many fail in many ways, but it's not because the work
is too hard to do. I find there's always necessary overlap between
building the immediate need, and preparing for the future development.

Post by Adrian Howard
I’ve personally had more success with sprint-based teams in extending
the scope of the sprint to include more discover at the start, and
more evaluation at the end rather than trying to overlap everything.
It makes it much easier for the experts to spend more time
facilitating the rest of the team in the areas they’re less familiar
with.

So what do the developers do while the UX people are discovering at the
start of the sprint?
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
------------------------------------

[George Dinwiddie]

Mike,

Post by Michael Vizdos
Question.
How is UX different or more special than any other speciality on a team?

A big difference that I see is that UX is more closely aligned with
deciding what to build than with building it. That makes it naturally
align with a feedback loop around the development loop.

We've been calling it "product discovery" vs "product delivery."

Post by Michael Vizdos
I see this with (insert my speciality here) when teams start forming,
get into storiming (sometimes blame), and then as a team moves from
individuals to a norming and high performance team of people they figure
out together what is needed to #deliver.

Yes, I've seen that often, too. As Adrian says, many places don't want
to invest enough to have a UX person on each team. In fact, in my
experience, many places don't have a UX person at all, particularly for
in-house systems. Even in these cases, I've generally seen someone,
often a tester, take an interest in how the system feels to the user.
When they can make this concern a part of the discussion throughout the
development process, from deciding what to build, detailing that
decision, building it, and testing it, then I've seen them reap the
rewards of better systems in less time.

- George

Post by Michael Vizdos
I am happy to see UX getting involved in the discussions with teams. It
shows that scrum truly does bring up tough conversations that, in the
past, has just been accepted in a system environment.
I appreciate learning more in this thread.
Thank you.
Mike Vizdos
www.michaelvizdos.com/contact <http://www.michaelvizdos.com/contact>
Adrian,

Post by Adrian Howard
Hi George,
On 20 Jan 2014, at 17:06, George Dinwiddie
[snip]

Post by George Dinwiddie

Post by Adrian Howard
* The cadence of the research processes don’t always match up with
the cadences of the development sprints

These teams are doing the product discovery more in a kanban fashion
than a scrum fashion. There's no expectation to discover a specific
amount of product in a particular sprint.
Is that what you mean?

[snip]
Basically.
There are some activities that fit very well within a sprint-based
structure. Doing usability tests of products under development, doing
interaction design around new features, and so forth. These fit
nicely into the kind of sprint-ahead / sprint-behind structure of
dual track scrum.
Other activities fit less well. For example a diary study that
happens over several months, or ongoing user interviewing activities,
etc.

Yes, the teams I'm working with would divide those into discrete
activities. They would share their findings at the Sprint Review, and
might possibly change the direction or discontinue as they see fit.

Post by Adrian Howard
Does that make sense?

Post by George Dinwiddie

Post by Adrian Howard
* People often seem to misinterpret the stuff that Desirée et al
talked about as having a separate team, rather than a separate

stream

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
of activity. Leading to some terrible siloing and subsequent
annoyances…

Here it's all in one team, though there are strong specialties. The
teams that work closest do the best.

Absolutely. It just one of the most common mis-implementations of
this approach that I encounter. It’s a very easy one for groups that
have separate UX groups to move to.

Post by George Dinwiddie

Post by Adrian Howard
* It can put a lot of pressure on limited design resources

where the

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
same group of folk are trying to help with the current development
work, assess the previous sprint, and look ahead to the next -

all at

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
the same time.

Shouldn't everyone be doing that, not just "design resources?"

Or are

Post by Adrian Howard

Post by George Dinwiddie
you talking about people who aren’t dedicated to the team's work?

Yes - everybody should be involved in it. But in most teams there
will be some folk who are subject experts who will help lead and
facilitate the work.
By having the evaluation of the UX of the previous sprint in the next
sprint also extends the feedback loop. If a story doesn’t deliver a
great experience you should find that out during that story’s sprint
- not wait until the next one.

If you're talking about evaluation by the UX experts, that happens as
things are being built. If you're talking about measuring use after
deployment, that would follow.

Post by Adrian Howard
To draw an analogy: Imagine that folk suggested dual-track-testing
was the best way to integrate testing practices and skills within a
* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

Testing code a sprint late is a horrible idea. I don't think it's
comparable to most UX work, either. That's inserting delay after
deciding what to build, and before delivering it. This is the innermost
loop. Delay there is a killer.
Delay in deciding what to build is less of a problem, and may be quite
appropriate. Delay in determining if what was built is accepted by the
users is also less of a problem, and must necessarily happen after
deployment.
Using feature switches is a great tool. There have been times where a
new feature has been turned off in short order. Some have even been
deployed "dark," though more due to internal politics than UX discoveries.

Post by Adrian Howard
This, to me, sounds like it would make put the team members who have
more testing skills under considerable pressure and detract from the
work done in the current sprint - and increases the length of the
feedback loop.

In my experience testers can
- test new functionality as it's built (same sprint)
- help plan the acceptance tests for the next sprint
without much problem if they're included in the process from the
beginning. Using the Three Amigos Process and Given-When-Then to express
the acceptance scenarios necessary to verify a story makes this pretty
simple. See http://www.nxtbook.com/nxtbooks/sqe/bettersoftware_1111/#/19
Making sure the current sprint's code is testable is accomplished by
testing it. If it's not testable, it's not tested, and therefore not
done. Having determined the scenarios up front greatly helps this
process, also.

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

There are many things that orgs do poorly, but I don't think that means
they're tricky. And if an org scrimps on UX people, then they're going
to do less in terms of UX. That's OK. They don't have to succeed. :-)

Post by Adrian Howard

Post by George Dinwiddie
Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off
well, and I think I’ve seen more folk fail than succeed at it. Mostly
due to the issue of people trying to do three things at once.

OK, I haven't seen them fail because they're trying to do three things
at once. I've seen many fail in many ways, but it's not because the work
is too hard to do. I find there's always necessary overlap between
building the immediate need, and preparing for the future development.

Post by Adrian Howard
I’ve personally had more success with sprint-based teams in extending
the scope of the sprint to include more discover at the start, and
more evaluation at the end rather than trying to overlap everything.
It makes it much easier for the experts to spend more time
facilitating the rest of the team in the areas they’re less familiar
with.

So what do the developers do while the UX people are discovering at the
start of the sprint?
- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
------------------------------------

[Adrian Howard]

Hi Mike,

On 24 Jan 2014, at 16:46, George Dinwiddie <***@idiacomputing.com> wrote:
[snip]

Post by George Dinwiddie

Post by Michael Vizdos
How is UX different or more special than any other speciality on a team?

A big difference that I see is that UX is more closely aligned with
deciding what to build than with building it. That makes it naturally
align with a feedback loop around the development loop.
We’ve been calling it "product discovery" vs "product delivery."

[snip]

Yup. What George said.

There’s a lot of different skills that fit in under the umbrella of the UX term.

Some of them are more closely aligned with the development/deliver side. Others are more closely aligned with the product owner side of figuring out what to build - product & market discovery.

So if you have a Scrum team that’s used to defining product backlog items in terms of "build this thing" it can be hard to figure out where some UX folk, and the work they do, sits.

Cheers,

Adrian

[Adrian Howard]

Hey George,

On 24 Jan 2014, at 01:41, George Dinwiddie <***@idiacomputing.com> wrote:

[snip]

Post by George Dinwiddie

Post by Adrian Howard
Other activities fit less well. For example a diary study that
happens over several months, or ongoing user interviewing activities,
etc.

Yes, the teams I'm working with would divide those into discrete
activities. They would share their findings at the Sprint Review, and
might possibly change the direction or discontinue as they see fit.

Ditto. As more folk are having research-ish folk within the product development team you’re seeing interesting ways found to communicate and interweave UX research with ongoing development work.

But this ends up being fairly different in kind, I think, from idea of simply looking to the next sprint - which is how I often find people interpreting the dual track idea.

You have ongoing research, which also involves product developers in things like experiment and prototype design, that moves forward over several "sprints" worth of time moving from something that’s almost completely research / product discover towards something that’s almost completely implementation of something that we’re sure is going to work well.

[snip]

Post by George Dinwiddie

Post by Adrian Howard
By having the evaluation of the UX of the previous sprint in the next
sprint also extends the feedback loop. If a story doesn’t deliver a
great experience you should find that out during that story’s sprint
- not wait until the next one.

If you're talking about evaluation by the UX experts, that happens as
things are being built. If you're talking about measuring use after
deployment, that would follow.

And it all gets more interesting when you’re dealing with continual deployment, and research that involves releasing product, ramping up a/b tests, etc. etc.

Again - making the idea of UX happening in a separate track seem very fuzzy.

Post by George Dinwiddie

Post by Adrian Howard
To draw an analogy: Imagine that folk suggested dual-track-testing
was the best way to integrate testing practices and skills within a
* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

Testing code a sprint late is a horrible idea. I don't think it's
comparable to most UX work, either. That's inserting delay after
deciding what to build, and before delivering it. This is the innermost
loop. Delay there is a killer.

It’s not so much the delay - but the fact that we’re spending (and possibly wasting) time planning what we do next before we’ve figured out whether what we’ve already done is acceptable. It’s the length of the feedback loop - not the delay in decision making.

Post by George Dinwiddie
Delay in deciding what to build is less of a problem, and may be quite
appropriate. Delay in determining if what was built is accepted by the
users is also less of a problem, and must necessarily happen after
deployment.

Hmmm… usability testing within sprints, and as part of a definition of done is perfectly doable…

Post by George Dinwiddie
Using feature switches is a great tool. There have been times where a
new feature has been turned off in short order. Some have even been
deployed "dark," though more due to internal politics than UX discoveries.

Agreed. It’s also the first step to being able to release some features for research and testing purposes.

[snip]

Post by George Dinwiddie

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

There are many things that orgs do poorly, but I don't think that means
they're tricky. And if an org scrimps on UX people, then they're going
to do less in terms of UX. That's OK. They don’t have to succeed. :-)

Indeed ;-)

One of the disadvantages-that-is-actually-an-advantage of folk integrating UX more within product development is that it surfaces the need for more UX people, which is sometimes hidden in more waterfall-ish approaches.

Post by George Dinwiddie

Post by Adrian Howard

Post by George Dinwiddie
Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off
well, and I think I’ve seen more folk fail than succeed at it. Mostly
due to the issue of people trying to do three things at once.

OK, I haven't seen them fail because they're trying to do three things
at once. I've seen many fail in many ways, but it's not because the work
is too hard to do.

Not that it’s too hard, but that there is too much of it.

Post by George Dinwiddie
I find there's always necessary overlap between
building the immediate need, and preparing for the future development.

Agreed. I just find that the dual track model seems to produce a model of that overlap that’s too simplistic to work well in many contexts.

Post by George Dinwiddie

Post by Adrian Howard
I’ve personally had more success with sprint-based teams in extending
the scope of the sprint to include more discover at the start, and
more evaluation at the end rather than trying to overlap everything.
It makes it much easier for the experts to spend more time
facilitating the rest of the team in the areas they’re less familiar
with.

So what do the developers do while the UX people are discovering at the start of the sprint?

Working with 'em of course! Separate group of UX folk off working by themselves = evil!

The rest of the team can be involved in lots of ways:
* Getting cross-trained by the UX folk so that can help with some of the research stuff
* Get involved with things like design studio
* Helping with the usability testing
* Working with the UX folk to get the framework in place so folk can ramp up split test
* etc.

One of the nice side effects of this approach is that it provides a good environment for finding and upskilling people interested in UX work in the product team. Helping solve those resource issues mentioned above.

This may be an artefact of the contexts that I’m spending a lot of time in (startup/new-product-ish) but I’m finding the hard line between "research" and "development" that some folk draw very annoying. I’m seeing more good things happen when you get a group with both sets of skills together swarming and working on things together.

Odd that ;-)

Cheers,

Adrian

[George Dinwiddie]

Adrian,

Post by Adrian Howard
Hey George,
[snip]

Post by George Dinwiddie

Post by Adrian Howard
Other activities fit less well. For example a diary study that
happens over several months, or ongoing user interviewing activities,
etc.

Yes, the teams I'm working with would divide those into discrete
activities. They would share their findings at the Sprint Review, and
might possibly change the direction or discontinue as they see fit.

Ditto. As more folk are having research-ish folk within the product
development team you’re seeing interesting ways found to communicate
and interweave UX research with ongoing development work.
But this ends up being fairly different in kind, I think, from idea
of simply looking to the next sprint - which is how I often find
people interpreting the dual track idea.

FWIW, too many scrum teams only look ahead to the next sprint, and don't
achieve much cohesiveness to the work, whether they're concerned with UX
or not.

Post by Adrian Howard
You have ongoing research, which also involves product developers in
things like experiment and prototype design, that moves forward over
several "sprints" worth of time moving from something that’s almost
completely research / product discover towards something that’s
almost completely implementation of something that we’re sure is
going to work well.
[snip]

Post by George Dinwiddie

Post by Adrian Howard
By having the evaluation of the UX of the previous sprint in the next
sprint also extends the feedback loop. If a story doesn’t deliver a
great experience you should find that out during that story’s sprint
- not wait until the next one.

If you're talking about evaluation by the UX experts, that happens as
things are being built. If you're talking about measuring use after
deployment, that would follow.

And it all gets more interesting when you’re dealing with continual
deployment, and research that involves releasing product, ramping up
a/b tests, etc. etc.

Yes, the org I'm working with does A/B testing prior to building (using
javascript manipulation of the page), but does little after the release.
I'm raising the awareness of that, now. The first step will be building
cheaply and A/B testing before turning the feature on for all users.

Post by Adrian Howard
Again - making the idea of UX happening in a separate track seem very fuzzy.

Post by George Dinwiddie

Post by Adrian Howard
To draw an analogy: Imagine that folk suggested dual-track-testing
was the best way to integrate testing practices and skills within a
* Test the functionality delivered in the previous sprint
* Help make sure the current sprint’s code is easily testable
* Help plan the acceptance tests for the next sprint

Testing code a sprint late is a horrible idea. I don't think it's
comparable to most UX work, either. That's inserting delay after
deciding what to build, and before delivering it. This is the innermost
loop. Delay there is a killer.

It’s not so much the delay - but the fact that we’re spending (and
possibly wasting) time planning what we do next before we’ve figured
out whether what we’ve already done is acceptable. It’s the length of
the feedback loop - not the delay in decision making.

Post by George Dinwiddie
Delay in deciding what to build is less of a problem, and may be quite
appropriate. Delay in determining if what was built is accepted by the
users is also less of a problem, and must necessarily happen after
deployment.

Hmmm… usability testing within sprints, and as part of a definition
of done is perfectly doable…

That makes good sense.

Post by Adrian Howard

Post by George Dinwiddie
Using feature switches is a great tool. There have been times where a
new feature has been turned off in short order. Some have even been
deployed "dark," though more due to internal politics than UX discoveries.

Agreed. It’s also the first step to being able to release some
features for research and testing purposes.
[snip]

Post by George Dinwiddie

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
Not saying it can’t be done - but it is tricky in many orgs.
Especially without finding more UX/design-ish people than many
organisations seem comfortable having on a product team.

There are many things that orgs do poorly, but I don't think that means
they're tricky. And if an org scrimps on UX people, then they're going
to do less in terms of UX. That's OK. They don’t have to succeed. :-)

Indeed ;-)
One of the disadvantages-that-is-actually-an-advantage of folk
integrating UX more within product development is that it surfaces
the need for more UX people, which is sometimes hidden in more
waterfall-ish approaches.

Post by George Dinwiddie

Post by Adrian Howard

Post by George Dinwiddie
Yes, if orgs don’t practice it, it doesn't work very well.

Yes of course. But I do think it is a difficult thing to pull off
well, and I think I’ve seen more folk fail than succeed at it. Mostly
due to the issue of people trying to do three things at once.

OK, I haven't seen them fail because they're trying to do three things
at once. I've seen many fail in many ways, but it's not because the work
is too hard to do.

Not that it’s too hard, but that there is too much of it.

Post by George Dinwiddie
I find there's always necessary overlap between
building the immediate need, and preparing for the future development.

Agreed. I just find that the dual track model seems to produce a
model of that overlap that’s too simplistic to work well in many
contexts.

I see it vary between teams in the same org. It seems to depend on how
tightly the team works together.

Post by Adrian Howard

Post by George Dinwiddie

Post by Adrian Howard
I’ve personally had more success with sprint-based teams in extending
the scope of the sprint to include more discover at the start, and
more evaluation at the end rather than trying to overlap everything.
It makes it much easier for the experts to spend more time
facilitating the rest of the team in the areas they’re less familiar
with.

So what do the developers do while the UX people are discovering at
the start of the sprint?

Working with 'em of course! Separate group of UX folk off working by themselves = evil!

:-) Yes, evil. I hate to see sequential phases of working, though. I'd
rather see work products go through sequential phases.

Post by Adrian Howard
* Getting cross-trained by the UX folk so that can help with some of the research stuff
* Get involved with things like design studio
* Helping with the usability testing
* Working with the UX folk to get the framework in place so folk can ramp up split test
* etc.

Perhaps you're in a different situation. These teams still have plenty
to build. If the UX folk can't keep the pipeline full, executives will
step in with their pet ideas.

Post by Adrian Howard
One of the nice side effects of this approach is that it provides a
good environment for finding and upskilling people interested in UX
work in the product team. Helping solve those resource issues
mentioned above.
This may be an artefact of the contexts that I’m spending a lot of
time in (startup/new-product-ish) but I’m finding the hard line
between "research" and "development" that some folk draw very
annoying. I’m seeing more good things happen when you get a group
with both sets of skills together swarming and working on things
together.
Odd that ;-)

;-)

- George

[Adrian Howard]

On 26 Jan 2014, at 01:23, George Dinwiddie <***@idiacomputing.com> wrote:
[snip]

Post by George Dinwiddie
Perhaps you're in a different situation. These teams still have plenty
to build. If the UX folk can't keep the pipeline full, executives will
step in with their pet ideas.

[snip]

Yup - and that’s often at the heart of the problem. The idea that building *something* is always better. The goal shouldn’t be to keep the pipeline full. It should be to make what comes out of the pipeline valuable.

Adrian

[Andrew Burrows]

Hi Gercel,

I can offer a few pieces of feedback. If nothing else, it may get more
conversation started around your topic.

I think you need to identify the obstacles that prevent your UX specialists
from participating in the creation of potentially-shippable software at the
end of each sprint. My assumption is that there is some fundamental reason
or issue for this situation, and that changing the Scrum framework to
compensate or adding an additional Design Thinking team is only going to
paper over the issue. It will resurface down the road, meaner and leaner. :)

It's great that your team is spending all 10% of their time each sprint
grooming the backlog - I have found most teams to have the opposite
problem! So I think your team is strengthened by this desire to look ahead
and understand how their current actions could affect their future.

The ideation phase you describe is a great idea. What is the scope of those
meetings? Have you tried running timeboxing this phase and only focusing on
the top story in the backlog, in preparation for next sprint? Do you have a
"just enough" philosophy when starting these meetings? It is great that
your team is focusing on excellent design, which enhances agility, but are
they also focusing on maximizing the amount of work not done?

Have you clarified a definition of ready for your stories, and teams are
not required to commit to stories unless them meet this definition? At what
level of clarity would your UX specialists feel comfortable committing to a
story? And how does this compare to the idea of "just enough" to get
started?

For me, the most interesting point you mentioned was, "Our UX specialists
would think about the problem that needed solving for a given story and
come up with something a lot different from what was originally intended.".
This leads me to assume that the user stories are requesting specific work
from the team rather than presenting the team with a problem to be solved.
It is only when the UX team break the stories down that they uncover the
root problem that caused the story to be required from the beginning. Then
they design to solve that problem.

Perhaps your UX specialists need to feel like they are solving the root
issues, and that your stories don't give them the flexibility to do this?
Maybe they're rebelling against feeling constrained? This is pure
speculation on my part. But do your stories solve problems or do they
demand specific work items? And have you considered a story as only being
"ready" for the team once the team and the PO can fully articulate the
fundamental problem that you're trying to solve? Does the team have the
autonomy to come back to the PO and say, "Hey, here's the problem you were
describing. I know you had <solution A> in mind, but this is how we should
really do it."?

I hope this helps. Thanks for sharing, Gercel.

Andrew

Post by Gercel Silva
Hey, Andrew!
Thanks for your response. I'm sorry for taking this long to reply (I was
on vacation and not able to get a good answer for your question).
My colleagues think that DT could solve the problem of addressing User
Experience concerns more properly than what we do right now.
We've tried running a few projects with no up-front thinking before
starting the first Sprint, leaving everything regarding UX to be decided by
the sprinting team. One problem we saw with this approach was that some
user stories that had been selected by the team during Sprint Planning
ended up either being cancelled or changed dramatically as a result of UX
work. Our UX specialists would think about the problem that needed solving
for a given story and come up with something a lot different from what was
originally intended.
I think maybe our real problem is related to how we create our user
stories. We do have backlog Refinement meetings that the whole DevTeam and
Product Owner attend to. But since refinement shouldn't take more than 10%
of the Sprint's timebox our UX specialists don't think there is enough time
to explore the problem and alternatives to user experience. Also, they feel
more confortable sharing this work with other UX'ers that are not members
of that particular DevTeam.
As a result, we are experimenting with a process that has an explicit
'thinking' phase which takes place before the project vision is fully
consolidated. Some call it 'ideation', others call it something else but
the naming doesn't concern me as much as what is (and should be) actually
happening. The goal of this phase is to come up with several possible
solutions (sketches, not prototypes) to ensure that we choose the
alternative that provides the best user experience. The DevTeam is involved
in this phase, but others are also invited to help.
I have advised everyone involved to be careful with 'early decisions' and
to delay important decisions until the last responsible moment.
Are there any experiences you could share?
Thanks,
Gercel

Post by Andrew Burrows
Hey Gercel, do you know what problem your colleagues are hoping Design
Thinking will solve?

Post by Gercel Silva
Hi,
Can you guys share your experiences implementing Design Thinking and
Scrum together?
Some colleagues have been asking me about this for a couple of weeks and
I'm researching to know what options we have. From what I've read so far DT
seems fairly aligned with agile principles at several points. However I
found a few things that got me puzzled.
As an activity focused on user experience and the user's real needs,
Design Thinking takes place somewhat prior to the creation of User
Stories/PBI's. Often user stories are created as a result of this activity.
This looks a lot like backlog refinement to me. Questioning if a feature is
really necessary and focusing on the value it offers to the end-user, two
things found in Design Thinking, can be directly mapped to lean principles
(which I understand a little better than DT).
But here is what I don't get. I don't think this is a rule of Design
Thinking, but I found some people suggesting that you have a *Design
Thinking Team that is separated from the Development Team*. Both
'teams' would share the same Product Owner and Scrum Master. This doesn't
seem to be a good idea for me because the Development Team would not be
fully cross-functional (have all the competencies needed to create a
potentially shippable increment of the product). Also, making this
separation could have a negative impact on collaboration and shared
commitment between both teams. What do you guys think?
Do you have any other tips or research material I could look into?
Thanks!
Gercel Silva

[Yahoo]

In context with this discussion. I have a question to the group.

We have two stories which are ready for UAT and it is part of the definition of done. The person who does UAT is our product owner. In her absence how can we get the credit for these stories?

Any thoughts?

Thank you,
Phani.

Sent from my iPhone

[Markus Gärtner]

Hi Phani,

I recommend to find a substitute for your ProductOwner when she is on vacation.

I also recommend to grow your team's ability to grasp the ideas behind the stories, and upskill with regards to requirements engineering, for example. If your ProductOwner is rarely available during the Sprints, you as a team need to compensate for that.

Best Markus

--
Dipl.-Inform. Markus GÀrtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development

http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de

Post by Yahoo
In context with this discussion. I have a question to the group.
We have two stories which are ready for UAT and it is part of the definition of done. The person who does UAT is our product owner. In her absence how can we get the credit for these stories?
Any thoughts?
Thank you,
Phani.
Sent from my iPhone
------------------------------------

[Michael Vizdos]

And. In addition to the replies so far...

Do not worry about taking credit for the stories. This is a false metric.

#deliver to your end users and customers. If it helps them alleviate some
pain, you win along with your customers.

Thank you.

Mike Vizdos
www.michaelvizdos.com/contact

Post by Markus Gärtner
Hi Phani,
I recommend to find a substitute for your ProductOwner when she is on vacation.
I also recommend to grow your team's ability to grasp the ideas behind the
stories, and upskill with regards to requirements engineering, for example.
If your ProductOwner is rarely available during the Sprints, you as a team
need to compensate for that.
Best Markus
--
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
In context with this discussion. I have a question to the group.
We have two stories which are ready for UAT and it is part of the
definition of done. The person who does UAT is our product owner. In her
absence how can we get the credit for these stories?
Any thoughts?
Thank you,
Phani.
Sent from my iPhone
------------------------------------

[Adrian Howard]

Post by Yahoo
We have two stories which are ready for UAT and it is part of the definition of done. The person who does UAT is our product owner. In her absence how can we get the credit for these stories?

If by "credit" you mean mark the stories as complete / done-done then you can’t. UAT isn’t done.

Should be an interesting topic for the sprint retrospective ;-)

Adrian