Professional Documents
Culture Documents
Agile Just Basics PDF
Agile Just Basics PDF
about:reader?url=http://www.alexandercowan....
alexandercowan.com
What is agile?
1 of 60
about:reader?url=http://www.alexandercowan....
Basically, it says:
Individuals Interactions
Processes & Tools
Working Software
Comprehensive Documentation
Customer Collaboration
Contract Negotiation
Responding to Change
Following a Plan
Side Note I often encounter misunderstandings on two of the
terms above:
1. Documentation
When they talk about documentation, they mean big, long
specification plans. If you feel you need to deliver documentation,
help, etc. to your user, agile doesnt suggest you do otherwise.
2. Contract
By contract, they dont just mean a legally binding contract. They
also mean implicit contracts, like the idea that we should make sure
product management writes sufficiently detailed specifications and
then we should make sure that engineering writes correct software
2 of 60
about:reader?url=http://www.alexandercowan....
for that specification that never breaks. Yes, it turns out that
approach isnt very functional and structured collaboration is better.
More on that soon.
Thats the core of it and thats about the only part of agile that
everyone will agree is agile.
On the one hand, I feel like the manifesto is perfect. On the other
hand, I totally get that its not actionable. This is where practicing
agile starts.
Basically, your job as a (de facto) agile coach is to do three things:
1. Pick and choose the methods you think will help you and your
team
2. Discuss and adjust with your team and make sure you all are
applying those methods (within the limits of good judgement)
3. For each iteration, assess (with said team) how those methods
performed and go back to #1
Simple, right?
Like most ideas of its type, its simple in concept and complex in
practice. Practicing agile is hard. If you want to cross things off your
list, confident you did your job, dont do agile. Its hard. Hour for
hour, youll be thinking harder and digging deeper to make sure you
understand your colleagues. All that said, agile is the best way to
do meaningful work and drive to innovative, valuable outcomes with
3 of 60
about:reader?url=http://www.alexandercowan....
a team.
4 of 60
about:reader?url=http://www.alexandercowan....
5 of 60
about:reader?url=http://www.alexandercowan....
For more, see the section below Agile and Story Mapping
If youre rearing to go, is it really OK to give agile a try with just
these three items? Personally, I would spend a little more time
skimming the sections below and digging in where you see the
need, but, sureit can work. The key thing will be that you remain
very observant about whats working well, and at the end of your
iterations you and your team consider how to evolve your practice
of agile to make it more effective.
6 of 60
about:reader?url=http://www.alexandercowan....
What it Is
Maybe you saw this above, but the user story has a specific syntax
with 3 clauses:
As a [persona/user role],
I want to [do something]
so I can [achieve some benefit/reward].
The first clause establishes who youre talking about, the second
clause what they want to do, and the third clause why you assume
they want to do this thing and how youll know if they were
successful. The user story is a testable narrative. Testable means
you could sit down a user, ask them to attempt to achieve a goal,
and observe whether they think they did it. For example, lets say
the user is saving a record of some type. When theyre done, are
they clear that its saved and OK (or not)?
How it Works
7 of 60
about:reader?url=http://www.alexandercowan....
works well. But also there is some layering and organization. Epic
stories broadly describe an interaction, and child stories detail the
individual steps. Test cases then offer a place for more detail on the
stories.
Size matters and stories should be small. Particularly if youre new
to product design, youll probably start by writing stories that are
way too big and broad. When you discuss the stories with your
team, hopefully they ask you about facets of the story that (likely)
will make you want to decompose it into more detailed stories. If
that happens, dont worry its natural and healthy.
For more detail and examples, see the User Story Tutorial here. To
learn more about how to improve your User Stories, check out my
agile course on Coursera: Agile Meets Design Thinking.
8 of 60
about:reader?url=http://www.alexandercowan....
9 of 60
about:reader?url=http://www.alexandercowan....
I find that drafting first helps teams surface all the things they didnt
realize they need to know. For this, I use my personas template on
Google Docs. Following that, I recommend drafting the interview
guide and then interviewing subjects.
From an agile perspective, the purpose of personas is to write
better, more valuable stories to discuss with your team. As you may
remember from the last section, the purpose of those stories is to
create a strong understanding within your team about whats
valuable to the user. Theyre only a substitute for that bad old
practice of big requirements when theyre used to drive regular
narrative collaboration within the team. The next section deals with
a great tool for facilitating that: the story map.
Other than the personas tutorial I mentioned above, the Customer
Discovery Handbook is a good guide. If you want something with
more structure, course 1 of my Coursera class (Agile Meets Design
Thinking) steps through the process, including live dramatizations!
10 of 60
about:reader?url=http://www.alexandercowan....
11 of 60
about:reader?url=http://www.alexandercowan....
of whats happening with the user (via various personas) over the
course of the relevant journey. In terms of stories, this will almost
certainly span multiple epics.
The job of the subsequent stripes is to organize and prioritize slices
of the narrative in Stripe 1. If your feature/area has the basic flow 1)
search 2) edit 3) share, then dont do all the search stuff in iteration
#1 and then move on to edit. Youll end up running out of time and
not have something functional you can ship or demo and it wont be
because you didnt code fast enough: it will be because your
prioritization was broken.
How it Works
Great newsif youve been following the tutorials and/or agile
course above, you already have the inputs for a story map. All you
need is a big space to post up your storyboards and some
discriminating judgement about how to slice your stories.
And, yes, I cant help but mention: you can find out more about this
in the user story tutorial and my UVA/Darden School of Business
online agile course at Coursera.
12 of 60
about:reader?url=http://www.alexandercowan....
a use case.
While its good to think about things from a user perspective, 98.6%
of the time Ive heard this term used, the situation would benefit
from a little more structure and specificity about who the user really
is and what they want. I know, I said I was not orthodox, but in this
particular matter I have always found the user story (with all 3
clauses carefully considered) to be the best prescription.
There is also a clinical definition of use case as an alternative to
user stories (Wikipedia page).
13 of 60
about:reader?url=http://www.alexandercowan....
14 of 60
about:reader?url=http://www.alexandercowan....
15 of 60
about:reader?url=http://www.alexandercowan....
16 of 60
about:reader?url=http://www.alexandercowan....
Often in agile, theres the idea that on the back of the card (physical
or virtual) where you write your user story, you write test cases. I
think this is a good idea as a way to add additional detail to the
story and surface important questions for discussion. As agile
thought leader Bill Wake once said to me, Sometimes, you just
need to establish that x + y should equal 14 to make sure everyone
knows how it should work. (Or something similarIm
paraphrasing).
Those kind of tests are good. But saying, You have to tell me now
the test well run to call this done, and then thats it, is setting
everyone up for a hard working environment and the user for
something they probably wont like.
But how can we get the businesspeople to do their homework and
give engineering good inputs? Good question. They should get
outside the building and talk to users and generally know that the
software engineering is about to build is a good investment. Thats
their job. Furthermore, asking for tests and examples may be a
good way to show them the level of thoughtfulness and specificity
the team needs. But, overall, youre much better off creating a
collaborative environment for that with a shared understanding of
the target outcomes. Its hard. Agile is hard (but worthwhile).
How it Works
Basically, it doesnt work this way. Examples are good, tests are
good, but setting specific criteria up front to call something totally
done is not a good idea.
17 of 60
about:reader?url=http://www.alexandercowan....
One simple formulation I like is that idea that there are 0, 30, and
90-day test criteria.
0-Day: It tests as usable by way of structured, phase-appropriate
user testing (see below on that).
30-Day: Users are using it regularly/at roughly the frequency you
established to call the feature relevant
90-Day: Its contributing to whatever is the target outcome for the
user- selling more, collaborating better, etc.
Note: None of this deals with whether the software breaks. For
that, see the sections below on TDD (test-driven development) and
continuous delivery.
If you want to learn more about testing against an outcome, I step
through answering these three questions in my agile course Testing
with Agile:
1. Should we build it? (And then: Did it matter?)
2. Is it usable?
3. Did it break?
18 of 60
about:reader?url=http://www.alexandercowan....
Usability deals with how much effort it takes your user to achieve
their goal. A usable product is not necessarily a popular
productyes, its sad but true. Theres also motivation. Motivation
deals with how motivated your user is to use your
product/proposition to achieve their goal. Theyre different and,
believe me, I see tons of beautifully executed products that users
arent motivated to use.
To explain the difference while still bearing the relationship in mind,
19 of 60
about:reader?url=http://www.alexandercowan....
20 of 60
about:reader?url=http://www.alexandercowan....
21 of 60
about:reader?url=http://www.alexandercowan....
where think you have an approach thats ready to go and you want
to validate that. (Obviously, if you havent done the prior testing,
your odds of being wrong about that are a lot higher.) Youre
probably using coded software, youre timing the user to see how
long things take. Your results should match the results from your
field analytics relatively closely.
For a tutorial on doing this kind of testing (including a test plan
template in Google Docs that anyone can use), see the Usability
Hypothesis section of the Customer Discovery Handbook. For even
more depth, see the section on usability sprints in my Coursera
course Running Product Design Sprints as well as the final course
in that specialization, Testing with Agile.
22 of 60
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
end of each iteration to discuss how things went and what youd
like to try changing to improve, your agile is born stale.
4. Whole Teams. Dedicated, interdisciplinary teams are the new
normal for any company that wants productive outcomes and
innovation. Siloed organizations with resources split between
projects are the old normal (that mostly didnt work so well).
What it Is & How it Works
Since iterations are themselves a process, these two facets are
tightly coupled. Starting at the top, the input to an iteration is a
prioritized list of user stories (backlog) and the output is really two
things:
1) working software (or conclusions, if its a design sprint), and
2) a completed retrospective on the sprint itself.
Lets step through the process. The diagram below uses terms from
Scrum, a specific methodology described below, but most of the
iteration elements are common to agile practice at large.
24 of 60
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
Now youre working the sprint for the next 2-4 weeks with a process
that looks something like this:
26 of 60
about:reader?url=http://www.alexandercowan....
donesprints have fixed time, not fixed content. At the end, the
team will usually hold one or more demos to talk about the content
(sometimes one internal and one with a larger set of stakeholders,
for instance). The working software should be potentially
shippable, but will not necessarily be released. Some teams will
complete multiple iterations before they release; releasing is closely
related to sprint completion but not the same thing in agile.
The last step is very important if you want to realize agile
outcomes: the retrospective. The whole team will spend a
substantial amount of time, say a few hours (varies with sprint
duration) discussing the sprint and what practices and methods
they want to change for the next sprint. Typical agenda items are:
The main thing is honest discussion vs. the perfect format. One
popular technique is the five whys. When something doesnt go
right, answer the question Why? five times to really get at the root
of the issue. The output of the retrospective is a set of decisions on
how to run the next iteration.
I think whats most important about running successful iterations is
thinking about the jobs you need done and how youll measure
success (and dont get too caught up with what the various
methodologies specify).
27 of 60
about:reader?url=http://www.alexandercowan....
28 of 60
about:reader?url=http://www.alexandercowan....
29 of 60
about:reader?url=http://www.alexandercowan....
30 of 60
about:reader?url=http://www.alexandercowan....
31 of 60
about:reader?url=http://www.alexandercowan....
Note: In the book The Lean Startup the author Eric Ries describes
a Build-Measure-Learn loop. I think thats fine; I just prefer the
above for drawing attention to the things Ive found are important.
32 of 60
about:reader?url=http://www.alexandercowan....
this is how you figure out customer motivation and I would focus on
that before you invest (much if at all) in usability for the reasons I
described above in the section on user testing.
How it Works
Any practicing scientist will tell you that the best way to get a
positive result out of your experiment is to go into it with a strong
hypothesis. If you just do Lean Startup and neglect your
understanding of the relevant personas and problem scenarios (see
also above), youll invest in testing weaker hypotheses/ideas. This
is one of the things I emphasize in the Venture Design process:
even though Lean Startup type experiments are way cheaper than
building product, theyre still more expensive than talking to
customers (relative to getting an actionable result). So, make sure
youre testing a proposition that at least solves a problem the
customer has.
Make sure your hypotheses have causality implied in them (if we do
x, then the customer will do y), otherwise their relationship to your
experimental design is likely to be murky. When you design your
experiments, make sure to include threshold metrics (pass/fail
threshold). Also, I highly recommend sketching several experiments
before you decide. They will probably vary a lot in their relative cost
and duration.
Finally, make a habit out of experimenting and sharing the results.
The most successful teams I know include them in weekly team
meetings about outcomes.
33 of 60
about:reader?url=http://www.alexandercowan....
For more on practicing Lean Startup, see the Lean Startup tutorial
here on the site. That tutorial also links to a Lean Startup template
in Google Docs. If you want more depth, I cover running Motivation
Sprints around it in my Coursera course Running Product Design
Sprints and go into more depth on managing experiments in
Testing with Agile.
34 of 60
about:reader?url=http://www.alexandercowan....
35 of 60
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
(agile-wise).
How it Works
If youre a titular or acting project manager, youve likely been given
a charter thats narrower than what I described above. Thats
normalorganizations change slowly. A lot of how businesses
operate is still leftover from managing widget factories in the
1950s. Rest assured, whoever your manager is, somewhere up
their chain of responsibility, theres someone that just wants you to
make them some money. (Unless youre a non-profit, in which case
substitute the orgs target outcome for money.)
The implication of this is that, above all, you should focus on
making your project successful. If you need change or you need
something from someone else, your best bet is to frame your
request in those terms. Will you then automatically achieve a
beautiful, harmonious, interdisciplinary paradise? No. But, youll be
taking steps towards it, and thats whats important. Create small
wins, show (with practice) that your approach is working, and youll
be fine.
I realize this How it Works is kind of general. Partly this is because
the concept of project management is pretty expansive if you
apply it to agile. But, fear not, the sections below go into more detail
about specific methods.
If you want to learn more about the jobs of proposition and product
design, see the related sections above on personas and user
stories. The Venture Design page has more detailed tutorials and
37 of 60
about:reader?url=http://www.alexandercowan....
38 of 60
about:reader?url=http://www.alexandercowan....
39 of 60
about:reader?url=http://www.alexandercowan....
(and test it and deploy it), and in what sized batches? Is that
process resulting in overall more valuable deliveries, measured in
terms of user outcomes? Is the work environment getting better for
the team?
3. Building
How is your team actually building, testing and deploying the
software? Are the methods in place contributing to progressively
higher output velocity, lower bug incidences, and smoother
deployment/operation? Do the team members feel theyre learning
and improving their craft?
4. Managing
How is the team being managed and managing its interface to the
rest of the organization? Do team members feel that they have
meaningful discretion to self-organize and do what they think
makes sense? Do they understand and buy in to the team
objectives in a way that allows them to see the value of their work?
Are there surprises from outside the organization (last minute
product changes, surprising assessment results from outside
stakeholders)? And, last but not least, how much time is everyone
having to spend in meetings of >2 people vs. doing work?
ROLES
The sections on agile methodologies below describe their view on
roles. Ive made the role descriptions below generic and functional
specifically to avoid oversimplification on roles and overemphasis
on their prerogative vs. what they should be doing for the team. If
youre familiar with the Stanford Prison Experiment, you know that
40 of 60
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
discussion. This may seem like a paradox but whole you want to
draw on the wisdom of the whole team, but its important that
someone is in a position to finalize product decisions that are not
obvious or split. Otherwise, you end up with something thats
averaged out and crummy or uncertain and shaky. Remember,
everyones solution is temporary and your emphasis should be
making the best possible decision under the circumstances,
building it, and then testing it.
3. Creating Human Interfaces
One or more people on the team may do this, but probably not
everyone. This area in particularly is tightly tied to the related job of
Product Design.
3. Creating Software
This role involves not only coding but writing unit tests, evaluating
alternative approaches (including use of 3rd party apps, modules,
and services). Id also lump tasks like version control and build
automation here, though these are highly interdisciplinary.
4. Testing Software
Tightly tied to the previous job, this includes unit, integration, and
system tests (or whatever you call the various levels of
testingsee below on that). This includes design for testability
(though that could equally be placed in #3), creating test
infrastructure, as well as executing tests.
5. Designing and Operating Systems
This role includes designing the system parameters for the software
42 of 60
about:reader?url=http://www.alexandercowan....
43 of 60
about:reader?url=http://www.alexandercowan....
next section.
If you want to learn more about managing with agile, I step through
it in my Coursera course Managing and Agile Teams.
44 of 60
about:reader?url=http://www.alexandercowan....
45 of 60
about:reader?url=http://www.alexandercowan....
46 of 60
about:reader?url=http://www.alexandercowan....
From these, you mark your actuals each day, decrementing the
story points of completed (done, tested, shippable) stories. Thats
the more wandering curve you see. Some teams use burndown,
some prefer to focus on measuring velocity based on actuals.
Whether or not burndown will be useful for your team is probably a
function of a) the decisions you want to be able to make during the
sprint based on its values and b) the predictability of what youre
doing. If your team is working on a brand new problem thats not
that well understood, burndown is likely to add stress. If youre
doing another batch of something you do all the time, it will be
relatively more accurate and more likely to be useful.
2. Learning
At the end of the sprint, theres a demo. Often, the team holds its
own demo to discuss the gory details and another to present to
external stakeholders. While this isnt a substitute for the kind
design research, usability testing, or motivation testing we
discussed above, its a good opportunity to vet the state of the
teams shared understanding and its success understanding what
constitutes a valuable outcome with external stakeholders. Suffice
to say that big surprises during the demo point to a problem in the
practice of agile.
Scrum-Demo-1000px
Like most agile methodologies, the process deals mostly with the
process of building of software itself. While agile has always been
very design-friendly, linking the overall practice of agile with best
practices in product design and design research is one of the more
recent, faster evolving areas of agile.
47 of 60
about:reader?url=http://www.alexandercowan....
3. Managing
To conclude a sprint, the team conducts a retrospective:
Scrum-Retro-1000px
Possibly the fastest way to predict how likely a team is to improve
their practice of agile is to ask about the nature of their
retrospectives. Is it a boring meeting everyone feels they have to sit
through while someone goes through the motions? Is it a dreadful
blame-fest? Or is it an honest, sincere appraisal of how things went
and what could be better where everyones #1 priority is to help the
whole team do better on the next one? The questions you see
above are common but a retro. for, say, a 2-week sprint should be
at least a couple of hours. Another popular technique is the
5-Whyspeeling back the root of why certain things happened.
4. Building
Other than a few details, scrum doesnt so much deal with the
specifics of how to build the software. This is one of its major points
of contrast with XP, which well describe next.
ROLES
There are three major roles in scrum.
Scrum Master
48 of 60
about:reader?url=http://www.alexandercowan....
49 of 60
about:reader?url=http://www.alexandercowan....
Agile and XP
Why its Important
Like scrum, Extreme Programming (XP) is a fully articulated agile
methodology. One of its major points of contrast with scrum is that
it is more prescriptive regarding actual programming practices. XP
is closely associated with high-performance programming practices
like test-driven/test-first development and pair programming.
Because it generally requires a deeper level of buy-in and practice
from developers, you may frequently get the sense that theres a
certain reverence for XP as an agile practice. It has contributed
substantially to advancing software craftsmanship.
Understanding the basics of XP is important for agile practitioners
even if theyre not themselves practicing coders. It is a large and
important body of work in the area that continues to be a common
feature of successful teams. That said, because of the level of
depth and specificity of the practices I would always look to the
development team for a decision on whether they want to adopt
some or all of the XP practices.
What it Is
XP-MethodologyLike scrum, XP preceded the Agile Manifesto itself.
50 of 60
about:reader?url=http://www.alexandercowan....
51 of 60
about:reader?url=http://www.alexandercowan....
52 of 60
about:reader?url=http://www.alexandercowan....
53 of 60
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
55 of 60
about:reader?url=http://www.alexandercowan....
How it Works
Youve probably seen a kanban board like the ones here (and if you
havent just Google it or check out my course on agile
management):
Trello-Agile-Kanban-1000px
Trello is the most popular tool I see, though there are many that Im
sure are fine. These are easy to set up and pretty easy to use in
practice. The main thing is to make sure that youve followed the
steps above, working with your whole team to make sure the
steps/phases on your board match your actual process and
assigning WIP limits. In the example above, I added the WIP limits
in parentheses. There are plug-ins for Trello to help with this if you
want something more full bodied.
The most important thing with the WIP limits is just to have an
explicit definition. If youre looking for a place to start, one idea is
that each developer should take a user story all the way through
the process before they start on something else- so that would
mean the WIP limits at each stage would be equivalent to the
number of developers. If you have hand-offs, to QA for example,
then youll need to model that. Just take your best guess (as a
team), and then be sure to consider how these are working in your
retrospectives.
If youd like to know more about kanban and how it fits into the jobs
of software development, I cover that in my Coursera course
Managing an Agile Team.
about:reader?url=http://www.alexandercowan....
about:reader?url=http://www.alexandercowan....
58 of 60
about:reader?url=http://www.alexandercowan....
include:
1. automation of different types of testing
2. automation of build and deployment processes
3. standardization and abstraction of deployment environments
(servers, etc.)
DevOps is a movement- closely related to CD but different. DevOps
promotes a set of practices and methods to encourage
interdisciplinary collaboration in the area above and more
thoughtful, disciplined work in the areas of testing, releasing, and
operating software.
How it Works
While Ive dealt with the related topics in my various roles over the
years (and even implemented a bunch of tests in Selenium that
broke a lot), I am no kind of expert in these emerging areas of CD
and DevOps. When I talk with experts, they just about all mention
the same first step: as a team, diagram your whole code to release
process together.
Just creating an explicit view of the process and talking about it as
a team is a valuable first step, not to mention foundation for what
follows. From there, decide where the biggest pains lie. Dont just
assume you need to do more test automation because thats
common- it may or may not be the best initial CD project for your
team. Consistent improvement is likely to be more important than a
59 of 60
about:reader?url=http://www.alexandercowan....
big tear down and rebuild of how you do things. The reason is that
its hard to get everything right in one big go.
If youre successful working on CD, its likely youre doing a lot of
what the DevOps folks would recommend. One thing I hear a lot is
that teams should avoid the fallacy of recruiting a DevOps expert.
Yes, experience in the area is super valuable, but since its
fundamentally an interdisciplinary practice, cultivating an emerging
expertise across your team or teams is most important.
There are a lot of great resources online in both these areas. In the
area of continuous delivery, Jez Humble maintains a site with a lot
of free (and paid) resources: https://continuousdelivery.com/.
Jenkins is a popular open source automation server, if you want to
try out a tool. There are a ton of great resources online for DevOps,
the site http://devops.com/, being one easy place to start. If youre
interested in a general introduction to the topics, I also cover them
in my Coursera course Testing with Agile.
60 of 60