[Sigia-l] Agile, Scrum and UX Wrap-up

[Tom Donehower]

I received so many invaluable responses to my question about Agile and
where UX and visual design fit in that I wanted to consolidate and share
with the group. Thanks to all who shared. It it greatly appreciated.

Looong but valuable list of replies follows:

==================================

Adrian Howard wrote:

<aside> It’s not an acronym so "Scrum" not "SCRUM". It’s a bit of a
shibboleth in the agile community ;-) </aside>

> I’m trying to understand where these other roles and their deliverables
fit in relation to a sprint from others past experiences.
>
> Shared experiences, war stories, and insight greatly appreciated.

This is a few years old but still a relevant read

http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

Unfortunately it’s really one of those it-depends questions I’m afraid. My
advice would change quite a bit depending on the UX folk involved, the
team, how good they are at actually doing Scrum, etc.

For example at the more generative end (user research, interviewing, etc.)
there is a strong overlap between UX and the Product Owner role in Scrum.
So I’ve seen some teams work very effectively by having a UX person
basically fill that role, or be a heavy support role for the actual PO.

On the other hand many of the most effective agile teams I’ve worked with
tend to embed UX in the team. The embedded role tends towards doing a lot
more facilitating of UX work by the whole team, as well as doing hands-on
work.

If you can talk a bit more about any particular issues you’re having I
might be able to give some more specific advice.

For further reading have a Google around "Agile UX" & "Lean UX". The Lean
UX stuff grew out of folk applying UXish things in Lean Startup context —
but it’s bigger than that now, being used in lots of non-startup contexts,
and is a good fit for agile.

Book wise I’d at least glance at these:

* Agile User Experience Design, Diana Brown - This is great for UX folk
wanting to grok agile more, and has several case studies on agile/ux teams.
However, it doesn’t really dive deep into specific Agile UX practices. Good
overview book. Especially for non-agile UX folk.

* Agile Experience Design, Lindsay Ratcliffe & Marc McNeill - Much more of
a toolbox of techniques/approaches book. The last third-ish of the book is
basically a list of techniques. There’s some stuff I’d niggle with in here.
Especially on some of the ways they talk about Agile - but it’s kinda
hair-splitting stuff if you’re just getting started ;-)

* User-Centered Agile Methods, Hugh Beyer — This is more of a UX-person
coming to Agile book, than an Agile folk adopting UX book (if you see what
I mean). My personal approach is a little bit different from Hugh’s - but
there’s definitely stuff worth thinking about here. If you’re dealing with
a more traditional UCD group then this would be very approachable for them.

* Lean UX, Jeff Gothelf & Josh Seiden - "The" book on Lean UX. Good
introductory read on Lean UX, but can only do so much for the size of book.
It’s also a bit light on some of the more generative user research
approaches from my personal perspective. Still a useful read though.

* UX for Lean Startups, Laura Klein - I think this fills some gaps in Jeff
& Josh’s Lean UX book. Especially on the user research side. I also think
it’s a *much* more approachable read to non-UX folk. Something that you can
give to the rest of the team.

* Lean Customer Development, Cindy Alvarez - Again, something very
approachable to non-UX folk in language and tone. Like Jeff, Josh’s &
Laura’s books it doesn’t spend a lot of time talking about integration with
agile teams specifically, but the techniques fit in with agile approaches
very well (indeed, agile approaches are required for this sort of UX
approach to work well.). This is more relevant to PO folk.

Just on the topic of usability testing, the stuff in Steve Krug’s "Rocket
Surgery Made Easy" fits in really nicely with agile - and very approachable
for non-UX folk.

I’d also keep an eye on Tomer Sharon’s upcoming Lean User Research book
from Rosenfeld
http://rosenfeldmedia.com/books/lean-user-research-product-development/

Outside of books I’d also take a poke at these two online communities.

* Balanced Team (balancedteam.org) - This community grew out of some UX and
Agile folk trying to play nice together, but has a bit of a broader scope
now. They do online/offline meetups, conferences, and the mailing list is
as useful as respectful as this one is IMHO. I first heard about the stuff
Janice Fraser et al were doing around Lean UX here, long before it was cool
and sexy ;-)

* https://groups.yahoo.com/groups/agile-usability/info - This is AFAIK the
oldest community of folk that have been poking at Agile & UX. Almost no
traffic now, but has a bunch of smart folk subscribed and some gold in the
archives.

To be honest I think plugging into the online communities around agile ux &
lean ux will be more helpful to you than the books. Despite folk having
been poking around this for more than ten years now, not enough of it has
been written down.

Also, while I don’t really actively curate these anymore you may find some
of the links on

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

of interest (although the relevance to the topic may, on occasion, need
filtering through my brain first ;-)

<biased>
Oh yes. I may put out a newsletter on the topic occasionally that might be
useful. Previous issues / subscription at http://is.gd/HNz5TN
</biased>

> Would also be curious if you've used a scrum tool you would recommend like
> Pivotal Tracker or Axosoft OnTime.

Have happily used Pivotal, Jira & Trello on projects. Have also worked on
projects where they’ve been a terrible hinderance. They’re just tools. I
tend towards starting with post-it notes or index cards, and move to
digital tools if/when necessary.

============
Also a bit dated being from 2010, but here's my experience from the UX
end of things:

http://webtorque.org/scrum-didnt-work-for-us/

I have no doubt that Scrum works. It’s just that it works for other people.
Dave Epstein wonderpup at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 20 (10 days ago)
to SIG
I find that it can and does work (we use it at my job) but it requires the
entire organization to buy in - from how projects are defined and how they
are rolled out. That's the hard part.
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 20 (10 days ago)
to SIG
My experience would indicate that you're correct. In larger
organisations, I think scrum is probably doomed to fail because
technical departments usually don't have the influence needed to push
the agenda needed for scrum to work. For example, scrum is basically
about increasing quality, and isn't necessarily about increasing speed
(in fact projects often start slower while risks are flushed out at
the start). However, we found we had to present scum as a way of
accelerating development in order to get the CEO to agree to try it.
My unease about that deception turned out to be justified.
Thomas Donehower <tdonehower at gmail.com>
Mar 20 (10 days ago)
to SIG
Fantastic feedback! Thank you. Could I ask for each of you who have
responded where did UX and visual design fit in with your scrum experience?
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 20 (10 days ago)
to SIG
We started by having UX and VD outside scrum in a "resource pool"
because the devs went into scrum first. UX then allocated people to be
part of each scrum team in "orthodox" scrum style. They all then
worked in 2 or 3-week sprints, depending on which team they were in.
Sometimes the devs did some UX work, but mostly didn't have the time
as they were too busy working on stories the UX guys had worked up in
previous sprints. The product owners (together with UX) had the
capacity to generate complex stories that maxed out their developers
very easily. Our UX guys were also not qualified to write production
code of any kind, so there was no question of roles blurring there
either.

BTW we also ditched most of the exploratory customer research we used
to do, and just went for gut feeling in the hope we could "tack" later
on once things shipped and we could put working systems in front of
users. I'd say that while that might have worked in theory, in
practice we found it was scuppered by the extreme reluctance of the
devs to throw away production code early on in the name of agility.
I've also subsequently encountered this in other places (I currently
work in "programmer anarchy" - Google will explain). While devs are
fine with refactoring code on their own terms, it's much harder to
convince them to refactor the UX because it might well involved very
large technical changes. This may be a fundamental difference between
the UX and development mindsets though. Not sure.

While I'm on the subject of UX and VD in scrum, there is also an issue
around the interpretation of "minimum viable product" when sizing
stories. Very often, I've seen MVP being used as a cover for crappy
UX. When this goes into production, it is quite rightly seen as such
by stakeholders and becomes something that de-motivates, angers and
frustrates many people. Perhaps that frustration is in fact necessary
in the name of agility. If done well it means you won't waste time on
the wrong things. But we just couldn't stomach the emotional reality
of it.

I should also point out that our "post-scrum" experience was rather
better. The devs went into a form of scrumban, while UX and VD went
into full kanban, albeit "throwing it over the wall" to the devs at
the end. Kanban was much, much better for us. No sprints, estimation
or ceremonies, we just concentrated on "waste". It was simple, and we
could keep to the quality we wanted without slowing down. But I guess
that's a story for another time.
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 20 (10 days ago)
to SIG, ia-55
I used to be a UX practitioner, then I started using agile methods to
deliver products (about 10 years ago). Now I'm an Agile Coach (for the last
6 years. Scrum, Lean and Kanban are my fav methods)

*Where does UX / Visual Design fit into Scrum?*

If you look at companies like eBay, Yahoo, Atlassian or even Spofity, the
agile team does all the design (including user-experience and visual
design) as well as development and testing. They plan together, they create
an Increment together that is production ready each Sprint. Typically, as a
result, there is some sort of UX skilled person as an integrated part of
the team. This is also my preference for teaching teams to work in agile
ways.

I find this highly collaborative approach empowers the whole team to take
control of the design themselves. That's not to say that they don't design
within a set of standards or guidelines, though. E.g. within WCAG 2.0 AA,
or a visual branding style guide. These standards form part of their
Definition of Done. When scaling across large numbers of team, this
'guidance' becomes very handy. I find that the guidance that the SAFe guys
are producing in the area of UX and scale quite useful.
http://www.scaledagileframework.com/ux/

With one team that I'm coaching now, their UX person is using Axure to
communicate interaction designs that are being implemented in the same
Sprint. He just finds this is the best way to communicate the intention of
the design to the rest of the team. If I'm doing UX work as a team member,
I don't tend to use this approach, I tend to do a lot of whiteboard
sessions with the rest of the team.

This is a team separated across 3 cities and two timezones. The physical
separation just makes things harder. We use the Quantum Entanglement
pattern to compensate (
https://sites.google.com/a/scrumplop.org/published-patterns/distributed-scrum-pattern-language/quantum-entanglement
).

*Deliverables?*

We do story mapping to help rapidly create the Product Backlog and produce
user stories rather than do extensive Spikes or Sprint 0 (
http://www.uie.com/brainsparks/2011/10/07/jeff-patton-story-mapping-for-ux-practitioners-tying-agile-and-ux-together/
)

We don't do wireframes as deliverables, but use them to communicate and
clarify design within the team. It also helps keep us focussed in terms of
what was suggested.

We do Pragmatic Personas (
http://www.stickyminds.com/article/pragmatic-personas) to help our user
stories and the Increment be user-focussed.

We do user journeys to help communicate where Epics, Features and User
Stories fit into the user experience.

We tend to update our documentation as we go as part of the Definition of
Done. This means all systems, data architecture and UX doco get updated in
an iterative fashion each Sprint as part of the Increment (production
ready, working software).

*Roles*

In terms of roles, I find that a Senior UX person can be an excellent Scrum
Product Owner as can a Senior BA. A person with good UX experience can also
be a greate Scrum Master because it can help the team focus on slicing user
stories to best represent a minimal viable (lovable) product (MVP) (not
that MVP is not supposed to be just minimal but importantly viable ... to
whom is often the issue. It's not minimal and viable for the team, it is
for the end-user). Apart from Scrum's 3 roles (Scrum Master, Product Owner
and Team), we don't have other formal roles. We don't even have a dev or
test "lead" role let alone a "ux designer" role.

*War Stories*

I used to employ the parallel pattern from Lynn Miller (
http://www.agileproductdesign.com/blog/emerging_best_agile_ux_practice.html
).
The UX people always seem to get ahead of their teams, waste always results
(Lean would classify it as "over production"), and while there was
coordination there was little deep discussion and collaboration. The former
is important to note because you could interpret as an anti-pattern. The
Sprint 0 required to get work going is also considered an anti-pattern by
most scrum coaches and trainers.

*Tools*

I seem to end up using with Jira Agile or LeanKit. I don't find them useful
or as adaptable as a physical Kanban board though.
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
"... they create an Increment together that is production ready each
Sprint."

I assume this only really works when the team members can all (or
mostly) do the UX and VD work as well their other roles. By "UX work",
I mean things like user research, prototyping, visual and interaction
design, etc. This would mean that during such sprints, developers
wouldn't be coding (other than perhaps looking at technical debt or
bug fixes from the last sprint). The companies you mention also have
mature products (or at least brands) already, which makes it less
likely that the visual design, if not the interaction design, would go
off the rails. If you're a startup, things would be rather different I
would suppose.

One of the major problems I've found with sprint-based activity is
when team members can't (or won't) do UX work because they're working
to deliver their part on stories from a previous sprint. I take it
that you prevent this by making sure all stories are done in a single
sprint, is that right? Does that not lead to endless discussions about
how to cut stories down to fit though?

Interesting also that you say that a UX person might be the product
owner or scrum master (they're very different roles in orthodox scrum,
of course). Assuming UX designers have the necessary seniority in the
organisation to take the place of product manager, I would think
having UX in that position would lead to large "sprint zeros", no?
Thomas Donehower <tdonehower at gmail.com>
Mar 21 (9 days ago)
to SIG
Jonathan,

You mention below "such sprints developers wouldn't be coding." Doesn't
that go against the principe of each sprint yields production ready
software?  Are you saying there could be sprints that are devoted to just
prototyping for example?
Skot Nelson skot at penguinstorm.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Yes.

There notion that "every sprint results in production ready code" seems
antithetical to agile itself.
--
Skot Nelson
http://www.penguinstorm.com/
twitter. penguinstorm
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
@Skot - I wouldn't go as far to say it was antithetical. The Agile
Principles say the delivery of working software should be "frequent"
and that it should be the "primary measure of progress". But I know
what you mean. Agile should be free to do what's appropriate, really.

@Thomas: As you can probably tell, there are some difficulties with
scrum orthodoxy when it comes to UX :-) I think this is because agile
methods (not just scrum but most others as well) attempt to solve
problems that UX designers don't really have - or at last don't have
to nearly the same extent as developers have. UX isn't reducible in
the way software is, and certainly the "founding fathers" of scrum
weren't thinking about UX when they formulated their manifesto - the
term "customer" is the 1980's meaning: somebody who pays for the
software to be built. Here's the famous "principles" page:
http://agilemanifesto.org/principles.html (the background photo
texture - QED).

I think there's a world of difference between writing code that runs
on computers, and creating things that run in people's heads. Because
of this, I think it's unfair on both designers and developers to adopt
the same methods. Were I to join a development team who had adopted
scrum, I would not discourage them, but equally I would not work
exclusively on their terms. It wouldn't be worth us all paying the the
price for that later if I did.
Skot Nelson skot at penguinstorm.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Right. "Working" and "Production Ready" are totally different things.

I always have the former, but it takes many sprints to get to the latter.
magia3e at gmail.com magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Scrum's Sprints don't have to focus on software. It can be used to deliver
anything that the Product Owner dedices is of value. A whole Sprint's
Increment may just be dedicated to learning with 'knowledge products'.

The idea behind 'production ready' is that what ever is created is fully
complete within the confines of the Sprint to what ever standard the
quality/satisfaction criteria (Definition of Done) specifies.

Things that are not software have been delivered using Scrum

* The SAAB Gripen fighter jet was made with Scrum.

* The wikispeed car

I've delivered UX consulting recommendations papers using Scrum whose tram
was only ux people. Each Increment consisted of 'production ready'
personas, tree structures and prototypes because that was the outcome
sought by the Product Owner by the client. These would be used much later
to help guide a web project.

M


Sent from my HTC
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
As a one-time Agile Alliance Certified Scrum Master, I would say that
as long as both the pigs and the chickens all agree with the
definition of "done", then that's fine. However, the default in scrum
is always to produce production ready *code* (not wireframes or
personas) at the end of every sprint, and from the very first sprint.
See antipattern 16 (from the standard texts on the subject):

http://www.agileadvice.com/2011/12/05/referenceinformation/24-common-scrum-pitfalls-summarized/

... and of course the endless debates that produces!

https://www.scrum.org/Forums/aft/1273

But we digress here.

@Tom: are we helping at all, or should we just can it?
magia3e at gmail.com magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Getting *all* the work needed to deliver a user story, from analysis and
design thru to development and testing requires 'small' sized user stories
so that the work fits into a single Sprint.

The slicing method depends on a discussion between the Product Owner and
the Team with the resultant slices just being smaller user stories. The
order is negotiated between the Team and the PO. In a normal software
project each user story will be a small feature-like element.

Some of those slices will likely require more UX effort, some less, some
none at all. But each slice will represent something that is of value to
the Product Owner. A wireframe or prototype as the end result of a user
story ia only likely to be 'of value' if it helps clarify some high risk
unknown that will be looked at in a later Sprint. Architecture is some
times tackled this way. Its often referred to as a Spike.

The Team collectively decide how they will tackle their Sprint Goal and the
Increment together. They also decide how much work they take on. But the
Product Owner still has the final say in terms of whether their approach
represents value. If everyone is going to sit around and do nothing until
the UX work is complete that's obviously not of value

The Scrum Master's role in this is to help the team work out a plan of
attack and ensure that the team doesn't "waterfall their sprints"
http://www.scaledagileframework.com/sprint-execution/

When UX work starts at the beginning of a Sprint -- prototyping,
interaction design, wireframes etc - is going on, I often find other team
members are doing things like:

* Writing test scripts
* Engaging business stakeholders, clients, end users face-to-face to
clarify functional requirements
* Doing cross a functional pairing with the UX guy to understand the
interaction design and give feedback on areas where the technology is
limited
* Analyzing requirements for that user story
* Doing technical design for that user story
* Researching what the coding community says about the features in the user
story
* Doing the back end components of that user story

Or

* Delivering other user stories that have no real UX components

The Scrum Master makes.sure there is a plan of attack each day at the Daily
Scrum and ensures everyone is collaborating toward the team's goal. No one
is idle.

----- Reply message -----
From: "Thomas Donehower" <tdonehower at gmail.com>
To: "SIG Information Architecture" <sigia-l at asis.org>
Subject: [Sigia-l] Agile, Scrum and UX?
> Jonathan
>
>
>
>
magia3e at gmail.com magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
> "... they create an Increment together that is production ready each
Sprint."
>
> I assume this only really works when the team members can all (or
> mostly) do the UX and VD work as well their other roles.

I typically have one UX expert in my team. A few front end and a few back
end devs. A tester and a BA.

In Scrum, I want team members who are willing to help each other and do
what ever is needed to achieve the goal. This is why Sprint Planning for a
2 week Sprint is typically 4 hours in length -- 2 hours to hear *what* is
required and 2 hours to figure out *how* to work best to deliver it.

If the project is about building a website, then the focus of sprints will
nearly always be features that are production ready. This means my UX guys
are often thinkers who do a lot of their work in short bursts with
whiteboards and then have conversations with other team members to discuss
how to implement it.

User research for the next few upcoming Sprints consume about 10% of the
current sprint. User research then builds over Sprints to help inform the
overall product design. System architects call this emergent design and
have been working this way for a while.

That said, all team members in Scrum spend up 10% of the Sprint looking at
upcoming Sprints to get ideas about how they might tackle future work and
clarify requirements. Its called Backlog Refinement.
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
References to "pigs and chickens" has long been since removed from the
Scrum Guide :)

But it is more the domain of the Product Owner, not the Team. That's not to
say, though, that a discussion can't be had on the consequences of too many
criteria in a DOD and that perhaps a team should be aiming for WCAG 2.0 A
on a first pass to ensure that a specific user story fits into a Sprint.



On 22 March 2015 at 09:36, Jonathan Baker-Bates <jonathan at bakerbates.com>
wrote:
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
There are lots of reasons why an agile adoption fails.

http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf

It's not because Scrum doesn't work, it definitely does. 22% of failure is
born out of a lack of understanding about agile and why it works the way it
does. External cultural and political reasons comrprise about 30% of
reasons why agile projects fail.

Getting an experienced coach who knows how best to help an organisation
with this change is key to success IMHO.







On 21 March 2015 at 08:06, Jonathan Baker-Bates <jonathan at bakerbates.com>
wrote:
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Many agile projects fail because of misconceptions about roles and
responsibilities.

A product manager is not the same as a Scrum Product Owner. The same goes
for your client or your business stakeholder. They don't care about your
agile process and so will break the rules of the process when it suits
them. Most product managers I know are too high a level to be a Scrum
Product Owner.

But yes, the Product Owner gets to say what is produced and its sequence in
the Sprints. That requires everyone to understand their role. It requires
the Product Owner to work closely with other stakeholders including the
product manager. This is why the PO role is very similar in its definition
today as the way PMBoK define a PM's role.

I never have a Sprint 0. It's an anti-pattern because it never looks like a
Sprint. I often work in PRINCE2 environments that require lots of paperwork
and setup before a project is allowed to commence, but I do all this work
using Scrum. In my current web project it meant 4 Sprints of effort and at
the 5th Sprint I onboarded the team -- 3 devs, 1 front end specialist, 1
ux, 1 web content writer. one of the devs is also the SM. I was the PO, but
I coached my BA to take over from me as I've had to focus on 'other
things'. Anyone can be the PO or the SM, but if you have no experience,
training + coaching is essential to creating success.


On 22 March 2015 at 03:54, Jonathan Baker-Bates <jonathan at bakerbates.com>
wrote:

> "... they create an Increment together that is production ready each
> Sprint."
>
> [snip]
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Scrum requires all User Stories are done in the Sprint. The Scrum Master's
role is to reinforce this rule (they "own" the rules) and its process.
Sprint Planning is designed to allow time to have just enough of a
discussion to understand the size of a User Story, to break it down, and
agree (as a baseline) on how the team will approach its delivery. If UX is
required as part of the delivery of the User Story, I'd expect a discussion
on how much is needed to create a usable, accessible, lovable result, not a
minimal effort as part of an MVP.

There are lots of ways to slice a story. Sometimes the team doesn't agree
on how. Devs tend to want to separate out the front end from the backend,
but this is an anti-pattern. I find having done user journeys or story
mapping provides a useful user focussed perspective on slicing. You
ultimately want to slice a story so that it represents the smallest unit of
value to the user in a way that enables it to be delivered in 1-2 days (in
its entirety) by the team. This may mean a page of many features gets
broken down into smaller sets of features.

If it's clear that there is still no agreement, the SM will park the
discussion, the User Story will be put aside til next Sprint, and the team
will spend time (Backlog Refinement) doing some analysis and draft design
on the User Story until clarity is achieved. Sometimes, as a coach, I end
up making the decision on how to best slice a User Story because a team
typically has very little experience in knowing how best to do this. There
are dozens of patterns to use, but knowing which is a good one to apply
(there is never one "best" way) takes experience.

Sometimes there might be a User Story left over from a previous Sprint that
the team needs to work on, but if the rule of is that all User Stories must
be finished in a single Sprint, then Sprint Planning and Backlog Refinement
are mechanisms to ensure that all User Stories are sliced into small
pieces. This is just application of Batch Theory.
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
@Tom: Some experiences to consider

http://zenexmachina.wordpress.com/2013/03/12/ux-working-a-sprint-ahead-is-full-of-fail-work-as-a-single-team-instead/

Matt
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
Succeeding with Agile is one of my fav books from this perspective.
http://www.succeedingwithagile.com/

Change doesn't always have to come from the top-down. Getting buy-in first
from the CEO isn't needed in all companies.

Getting coaching from a change agent with experience in leading this type
of transformation does definitely help though :)
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
@Johnathan: I'm not sure why you feel unease about "accelerating
development".

There's a lot of good research that indicates when Scrum is done well, its
focus on building the right thing and building the thing right, removes
about 50% of the rework that is often associated with development projects.
The continuous learning also supports removing waste (from a Lean sense ...
a lot of my coaching of Scrum is heavily influenced by Lean) and so faster
delivery of the right thing to users and clients.

My own experience supports this view. Teams ability to deliver gets faster,
more efficient, less buggy over as little as 3 months if they have focus
and discipline in their Scrum practice. Creating focus and discipline is
not as easy as it sounds though :)

Scrum is like chess. The rules are simple, but to master it is hard. This
is why Scrum Coaches exist :)
Jonathan Baker-Bates via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
@Tom: So in Matt's link you may have an answer to your main question,
I think :-)

It would be very kind of you to report back on your experiences
implementing UX in scrum.
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
I'd say that *delivery* is the measure of success. But you are right about
working software vs value in terms of its delivery to end-users. This is
where I see UX brings a much needed refocussing of how a team works to
deliver that value.

This is why I feel its important to think about Scrum's Increment in terms
of Lean principles. That is, to create value (not just working software).

On 22 March 2015 at 09:05, Jonathan Baker-Bates <jonathan at bakerbates.com>
wrote:
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
@skot: if you're using Scrum that's not supposed to happen. I would be
trying to understand and learn why "production ready" isn't working and
then rectify it.

If this is not happening, then fire your Scrum Master and get one that can
help the team learn and fix this problem (continuous learning and
improvement is the main way to gauge a Scrum Master's performance). Or, get
a Scrum Coach to help identify why this is not occurring and to help the
Scrum Master learn how to do this by himself.
Thomas Donehower <tdonehower at gmail.com>
Mar 21 (9 days ago)
to SIG
Very helpful. I think the debate and exploration is worth it and encourage
anyone to contribute to this discussion. I think the most interesting
comment I've seen is the idea that when the agile manifesto was written
they did not have UX in mind and over time it seems that looser definitions
of agile and agile methods have been adopted to account for this. I also
think this points to the idea that every sprint yielding production ready
code may not actually yield the best product/software and that there is
room for improving or evolving the original thinking. Agree?
Matthew Hodgson magia3e at gmail.com via
<https://support.google.com/mail/answer/1311182?hl=en> asis.org
Mar 21 (9 days ago)
to SIG
At the anniversary of the signing of the agile manifesto, they discussed
whether there was anything they would change. Overall, they agreed that it
was still relevant, but the phrase "working software" is still something
that some consider a barrier to its further adoption into disciplines other
than software development.

That said, much of "agile" is very old. Even Scrum was born out of product
development and the article in the Harvard Business Review 'The New New
Product Development Game".

Now there are dozens of agile methods. Some continue to evolve over time.
The important thing is to remember that agile isn't one thing. It's more
important to ensure that the right method is selected for the right team,
its environment and its needs.

This is one reason I changed from a primary focus in my professional life
from UX to Agile. There's a lot that the agile camp can learn from UX. I
think the community is better from that mix of perspectives.