So we talked about the discovery process, the lean approach to
collaborative cross-functional building a shared understanding. How do we
combine this with an agile Cadence with the Cadence of a scrum
process? And that's what we're going to talk about next and I like to start this
section with an anecdote. I used to run the
user experience team at a company called the ladders and the latter's went through an agile transformation while I was there
and I was building my design practice my user experience and Design.
Practice through that transformation. And as we grew the team and as we evolve the
process, we had to understand how to integrate user
experience and design into the agile process.
And we struggled with it a lot, especially at the time there was not a lot of material
available with successful Integrations of agile, and user experience. And so we
tried a lot of different things and over the course of about six or seven months, it
felt like we'd stumbled a lot. Finally, hit a Groove where it felt like
things were working really well.
The complaints seem to have died down, productivity seem to have gone up.
And so one day, I was feeling pretty good about how things were going. I came into
work, it was a Monday morning and I get to my desk and there's a printout
on my desk, that's a diagram printout and this was the diagram that was left on
my desk.
Now, it turns out that my team had gone
off on their own and was very, very frustrated, as evidenced by this
diagram about how things were currently proceeding with the integration of
agile and user experience at the ladders at the
time. And if you notice all the, all the roads in this diagram,
lead to the center of a, where it says that agile, and
ux at theladders currently creates a negative environment that Fosters
failure and generates low,
Wow, it's clearly things we're not going as well as I'd hoped coming in.
Obviously the title of the diagram alone diagramming a negative environment,
will give you a sense that this we were not as far along, as I had
hoped in the process and all of those little boxes were
specific pain points that the team was feeling about what was not
working. Well, in the integration of our agile,
engineering practice, and the user experience and design
practice. And I want to highlight a couple of these because
The learnings from the once all of these have value but from the ones that I
highlight, the learnings speak directly into this lean ux approach.
And so, the first one is this one. The best experience never ever gets
built. We came from a waterfall World in a waterfall
world. You get one shot to get it right. Whatever the length of the project
is 9 months. 12 months 18 months, you build it
and you launch it.
And that's it. You get one shot to get it right now. We just took that
same mentality and applied it to two week iterations.
And so all of a sudden, the teams had two weeks to
build the best product that they could now. Of course, you're not going to build the best possible
product in two weeks, but we never went back
to iterate on that process. The agile philosophy
is an, iterative one. It's one of building something learning
and then improving it. And optimizing. It's not an incremental approach
to software development, but we had that waterfall mindset.
Where we would build something and then never look back. And so the team is struggling to keep Pace to launch a
product every two weeks to design something and launch it, every two weeks
and of course the best experience never gets built in a situation like that.
The next point was this, the ux team didn't feel business critical because we didn't
build the best experiences and so because they only gave the team, two weeks
to do their work total from design to development, attesting to
deployment.
Whatever design they could get done in that time, frame was launched and of course it wasn't the best
design.
And the team started to feel like they were just pixel pushers people who
just did the best that they could in the time that they had and the experience would just go out
regardless of how it affected customer experience or the brand. And so
that the, the engagement of the team suffered significantly
because they weren't given the opportunity to go back and to iterate on their
ideas and to move forward, simply let's build it and let's just move on and get whatever you
can done.
Agile, projects are never complete. That was a big complaint.
They never seem to be any kind of an end point to these iterations.
We just built two weeks, two weeks, two weeks, and just kept going
indefinitely. Now, coming from a waterfall world, that was a
drastically different in a waterfall world. You start a project, you work on it for an extended
period of time, 9 months, or 12 months. At the end of at the end of the time. Period, you
launch, you have a party, you get a T-shirt and you get to move on
to the next project.
In this world, in our new agile world, we didn't have
any success criteria. It was simply launched a feature launched a feature launched a feature
and this is when we really started talking about focusing on
outcomes, how do we know when we're done the
agile? Definition of done means that you've launched a feature, that's past its
testing requirements, and that is usable.
But in reality, but we're looking for our business outcomes in this is
what we started to have that conversation, we know we're done when
we see this outcome, this change in behavior in our
customers and that fundamentally changed the way that we
started thinking about our projects. Because all of a sudden, it wasn't
about launching features.
It was about determining outcomes by cheating business outcomes and
that's how we knew when we were done when we hit those kpis those metrics,
that's how we knew we were done. That completely changed the conversation. That was a big one.
The next one is no ideation time because of that rapid, iterative
cycle. The ux team had no time to work on their ideas
and to refine them and to make them better. And
this was partially because there was no integration that was no cross-functional
collaboration between the design team and the engineering team.
We still working essentially in very small waterfalls with a design team with design
up front for a day or two and then show it to the engine.
Is within start, developing it and then we q a by the end of the week.
And so the design team wasn't attending agile stand-ups.
They would do working independently and they were functioning almost as a standalone
operation separate from the rest of the engineering team,
this was a breakthrough moment for us because what we realized is that by integrating
the teams building, this cross-functional teams,
having everyone attend, all the meetings, all of a sudden you're having
conversations that are relevant to all the disciplines involved in the
success of that project designers,
Have a conversation to say, it's going to take me more time, to design. This feature
Engineers can have a chance to say when we could start working on something else while you're
designing that
But those conversations were not happening until we started to build
cross-functional team. That was also open to
democratizing the creativity in the design process by opening up.
Those processes for input from Engineers from
product. Managers to say we're thinking about heading this way. What do you think?
and by building those conversations in real-time,
And having those negotiations around, what I need to do my job, what you need to do your job,
we increased, the amount of ideation time that each team had.
The last point, I want to highlight in this diagram is the concept of minimum viable product. We really struggled
with this, this is such a a
nebulous phrase. When it's first introduced into an organization, what is
viable really mean? You know for engineer's it's functional for
designers it's it's
minimally. Beautiful product for marketers, it's the minimally marketable product, is
it? You know Is it feasible? What is that? What is the definition here? We
really struggled. We had a
Of War about what was good enough to go live.
And this was something that we had to come to agreement and consensus on as an organization
about what was good enough to go live for our organization, and as you
think about the MVPs for your organization, you have to ask yourself.
What's good enough for our organization? What are the
promises of our brand? What is our current customer experience? What are our
design thresholds? What are we comfortable putting in front of
customers?
Based on that context, and that's a conversation that you have to have
internally.
Before you can start releasing MVPs to your customers.
And so as we talk about agile, I want to talk about the mechanics of scrum specifically because
scrum is the process of agile and I think it's worth it to do
some level setting. When we talk about how lean ux fits into agile
by defining, some of the agile terminology, these are my
definitions. And I want to make sure that I set some levels about what I mean when I say
these specific phrases. So we'll go through them. The first is Scrum
and scrum is an agile. Methodology, that promotes time-boxed Cycles.
We work in a
We work in two week, iterations team self-organization. So, the Team figures
out how to work and high team accountability. The team is accountable
to itself.
User stories are the smallest unit of work and they're typically
expressed as a benefit, to the end user. So we're always thinking about the customer
as we're working through our requirements, user stories, essentially being our
requirements, right? As a, as an online
Shopper, I would like to buy a sweater so that I can be warm in the winter.
For example, the benefit to the customer is always in the user story and it's the smallest unit of
work. This is what actually ends up going on the on the cards that we prioritize
on.
Our scrum boards.
Now, the backlog is by far the simplest and in my
opinion, by far, the most powerful tool in any kind of project management. Including
agile project management, a backlog, simply a prioritized
list of user stories.
And when used properly you never have to say, no
to any requirement ever, again in the future, because there's a prioritized
list of estimated effort and when someone comes
in and says, we have a bug that needs to get fixed or the CEO is requested
that we round all the corners and make everything pink.
You can say that's terrific, we can do that. What are we not going to do in this
iteration? In order to accommodate that we're in? Are
prioritized list does this story fit?
And what's the cost of inserting it? Because you can't just stuff
stories into a backlog with a Time. Boxed cycle. It's a finite amount
of time. You can only do so much work and so if you if you if you're
going to insert stories into the backlog, whatever comes after those
stories may not.
Get into this iteration.
So if you groom your backlog honestly, and transparently,
it's a terrific way to manage projects and you never have to say, no, again, you just have to
prioritize against other work.
An iteration is a single team cycle. And the goal of most iterations is to
reach working software at the end. Especially and the in the traditional
actual world, the goal of each iteration is to deliver working software at the end of
that cycle.
Now we talked about high team accountability. The stand-up meeting
is the main tool of hi team, accountability
on in scrum and it's a daily short team meeting or each
member addresses. The days challenges, you literally stand up and you
talk about what I did yesterday, what I'm doing today and
What's blocking me? What's keeping me from doing my work effectively today.
Now, the reason this is such a powerful tool is because when you stand up with your team every day,
And you have to tell your team. This is what I did yesterday.
And this is what I'm doing today and this is why I'm not getting my work done. All of a sudden. If you were to stand up
there and say, well yesterday, I surfed Facebook all day long. And today I'm going to buy
some shoes online and tomorrow and what's getting in my way is all
this work because I can't buy shoes, right? You can't, you can't have that
conversation on a regular basis with your team. They're going to
get fairly frustrated with you fairly quickly.
And so, what you're doing is you're introducing a layer of transparency, a level of transparency,
into your team, Dynamic on a daily basis. And if you can't get your work done, if
people see that a card is story is stuck and it's not moving
forward, they could say Jeff, why is that card stuck, here's What's blocking me
and then someone will help you get that unblocked so that you can move forward with your task. This
is a terrific team accountability tool and it keeps everybody aware of where
the team is today and where they're going tomorrow. And how the
Chris is coming along.
There are two meetings that bookend and iteration at the end of the iteration, there's a
retrospective now. Retrospective is a meeting at the end of each of
these iterations that takes an honest look at what went
well and what didn't go so well during that last iteration during that
last time box. So as a team you reflect back and say
this is what went? Well let's keep doing that. This is what didn't go. Well, let's
fix that and you assign an owner.
To fix. What didn't go? Well, someone has to personally be responsible
for improving the handoff from design to engineering or two
for fixing the login problems for the wiki or whatever it is that kept your
team from being productive that week. So we're not just doing iterative
product development. We're also doing iterative process
Improvement
So, we're making our product better in the short time Cycles, but we're also working
better. We're learning how to work more effectively as a team by having these
introspective. Retrospectives, at the end of every iteration,
Now, the other end of the meeting is the iteration planning meeting.
And that's where you plan, what you're going to do for the next
iteration, the entire team needs to be at that meeting design product, engineering
content, editorial. Whoever needs to be there. Discuss what we're going to
work on.
Prioritized the stories and make a plan for the next week or for the next
two weeks. Now, my experience the most successful teams
also, do story Gathering or story writing, and estimation,
during the iteration planning meeting some teams like to separate those out into separate
meetings and that's fine. In my experience, the successful teams I've
worked with have done all of that together. In this meeting, they write their stories together,
they estimate them together, they prioritize them together
and they discuss them so they
Plan for how to move forward for the next two weeks over the next
week.
Now, one of the interesting things that's come up that came up early in the days of trying to integrate agile user experience as the
concept of staggered, Sprint's or Sprint zero.
And this was popularized by Lynn Miller and Desiree. See in a paper that
they wrote about think in 2007 where they discussed the concept of a
Sprint 0, where design Works, a Sprint
ahead of engineering
To Define and design what will get built in the next iteration?
Now, what's interesting is that this works really well as a
transition between waterfall and true agile,
ux and lean ux integration, but it's not where you want to stop along
the way. Because what happens here, is that you've created a
set of many waterfalls, actually, you can see it in the diagram. You can see this little
waterfalls coming through. There you, the designers are designing up front. And, in the first time that
the engineer, see, it is on day, one of the next Sprint. So
then they have to estimate
It at that point and decide what? They can, and can't get
done from that design in the next. Iteration
anything that can't get done in the next iteration is waste. That's a waste of the
designers time. It's a waste of conversation, it's a waste of time and so that
cross functional integration doesn't happen. Meanwhile, the designers are
designing for the next iteration and supporting the current iteration splitting
their attention. And costing them, a lot of times through costs, the context switching,
And at no given point is the entire team. Working on the same thing. At the same
time and building that shared understanding,
So, as a transition, this is a great step because it introduces teams to short of time,
Cycles, greater conversation and greater transparency between teams,
engineering and user experience and product, and so forth. But this is not where you want to
end up and so the question is, how do we integrate
lean ux cross-functional collaboration into a
scrum process and what's nice is that scrum is rhythmic. There's a
rhythm to it. There's a meeting Cadence that happens through there and we can use those as
mild.
It's to build in these lean ux activities. So again, we'll take two-week
Sprints as the model for this that are tied together by some kind of a theme.
A project, a feature, an effort that the team is doing.
The sketching, the ideation, the prototyping, the concept eating
the early validation, the, the lean
ux work happens before
the theme starts before the project starts with the entire team for
a day, a half a day, two days. Well, however long it
takes for that team to build a shared understanding of what they're building.
What direction, they like to take the solution in and how they'll measure
success.
But do so together as a cross-functional team, now I've done these
Inception workshops with a last half a day and I've done them when they've last five days.
But at the end of that, we have a significantly clear goal of what
we're building and how we're approaching it and what everybody needs to do to
move forward. Now we take the output
of those efforts
and we bring them into the iteration planning meetings, we bring the sketches, we bring
the, the Proto personas, we bring the research notes from
from the research from the collaborative, Discovery efforts that we've done as a team and and we and we
build our prioritized backlog based on that.
Shared in sight.
But we don't rest on The Laurels of that particular effort.
We build in a testing regimen
that has a speaking to customers on a weekly basis. So through every two weeks
Sprint there is at least one two or three conversations with
customers that are continuing to validate our approach
and the evolution of our thinking, as we move forward. And so what we're doing again,
is that there's a significant effort up front
to build that shared understanding as a team and then to motivate
Continued momentum throughout the development process.
We take bits and pieces of those activities. Maybe we'll do a
brainstorm to kick-off iteration to maybe, we'll do a design studio
to kick off iteration 3 because we're not sure exactly how to how to design something as a team.
And then we bring the assets. Those transient artifacts that we create in
these lightweight sessions, whether they're again, sketches,
prototypes notes conversations and we plan
Iterations together. And then we continue to validate our
thinking with a steady stream of qualitative Insight through
customer conversation. Now what's interesting, is that as you start to build, you
start to launch product, you're also going to gain quantitative Insight
because you're going to start launching software at the end of each. One of these iterations.
And so the testing and the learning comes in with a 360 degree view of your
customer. You're going to the qualitative Insight because you're talking to customers every week
and you're getting quantitative Insight usage metrics based on the software that you're actually
launching every two weeks.
and what's interesting is that you'll start from sketches and as you work together as a
team,
you'll begin to understand the requirements. For your colleagues, you'll build
a level of trust and camaraderie.
And understanding of what each engineer on your team needs to move forward or what each
designer needs for them to do their job. And so, you'll understand you'll get a sense of whether
this level of fidelity is enough. With the, we need to do visual design mock-ups or
maybe just some whiteboard sketches will get the conversation moving forward
and the further that you work, the longer that you work with your team's, the more trust is
built. The faster you can move forward and have conversations based on artifacts
at this level of fidelity.
now, what's interesting is that the integration of
of lean ux and agile,
Forces, another level of responsibility onto the team because you
don't have a clear roadmap for say and that you're
working towards specific business outcomes. The people who have a
stake in the success of your project, your managers business line
owners executives
We'll want to know what you're doing and how you're doing and how you're progressing.
So the onus is on the team to continually communicate,
both up and out to your colleagues, about your progress,
you have to insert a level of transparency that may not be
common to the way you're currently building products. And when you build that level of
transparency everyone on your team understands, what the team is doing because
you're having these daily stand-ups. And these iteration planning meetings and retrospectives
Your stakeholders.
Have a sense of what's Happening.
How you're progressing towards your success, your metrics and what you're working on.
Your product owners and your business line leaders begin gain a level of
comfort that you're progressing towards a solution that solves their needs. The
thing to keep in mind is that Executives will always want to see what you're up to.
So the more public that you can make your
progress, the better if you can post your success
metrics on a screen at work or in a print out every day that
says here's how we're progressing towards our conversion rate goals. Here's how we're progressing.
Towards our sign up goals that will drive things forward
significantly.
One thing to keep in mind is that you have to keep you
other departments aware of what you're doing.
It's who really easy to get caught up in these fast, iterative Cycles.
And forget that there are other people dependent on the software that you're
launching within your company. Specifically, I'm thinking about marketing,
And customer support.
If you are launching new software into production and it changes the way that the product
workflow behaves. There are people in a call
center somewhere who have a script that is based on the old
workflow. If you break that script, you're going to get a very angry
phone call or an email from the manager of that call center very, very quickly.
If you're launching features that are succeeding and you don't tell the marketing department, they're going to be frustrated
because that's what they like to do. They like to advertise and promote but there are new features
for the product to use, maybe we can change our pricing scheme, maybe we can do something different
retain, new customers, the onus on you, as a team is to be as
transparent as possible, not only with your stakeholders, but with other
dependent disciplines out from you and ensure that they're aware of what you're doing,
reach out to the call center and say, next Thursday, we're pushing out this new
workflow.
Here's what it's going to look like. Here's how you the scripts should change.
Let the marketing folks know that you've been iterating on a feature for a month and it looks like it's going to stick.
And they have an opportunity to promote it to a certain segment that's been asking for it for a
while.
The onus is on you as a team to ensure that your organization allows you to
continue to move at this pace, because if they can't see into what you're
doing, they're going to start asking questions and asking you to stop and write reports and have
meetings. And that's going to be the road block and making it in stopping this,
iterative Learning and Development process.
One more note on story Gathering and prioritization. It's
as I mentioned before, agile is an exercise. In prioritization
we have to choose what work we do in each
iteration. We have to decide. We're going to work on this
but not on that. And by building a shared understanding,
as a team, we have a much clearer sense of
what we'd like to work on, but as far as the prioritization
exercise is concerned, everyone has to be involved.
In the prioritization exercise. This is by far the most inclusive slide. I could
find on the internet but everyone has to be
involved in the prioritization.
Designers have to be part of the conversation to say. This is I can't the story can't be
first because it's going to take me three days to design. It Engineers could say, well, this story
can't be first because I have to do some research about the technology by having those conversations.
You can build a backlog that buys time for everybody
on the team to do their particular job and the same goes for
estimation
Sometimes a heavily designed story. May
take very little time to implement.
Other times the implications of adding a checkbox to the UI,
something that probably take 30 seconds for a designer.
Could trigger six months worth of development work, simply by checking that box you
have to have these collaborative conversations, these cross-functional conversations about
the estimation process so that gets baked in and then you can
prioritize properly and if you're not getting the time that you
need, you have to negotiate for it. You have to have those
conversations even Midstream to say
I'm not going to be ready like I thought for this particular car that's coming up, is there anything that we can prioritize
above that? You have to have those conversations and the only way to have those,
if you're actually participating in the process itself, whether
designer engineer product managers that are everyone has to be involved.