Introducing the Agile Extension to the BABOK® Guide
Shane Hastie, Software Education
Tuesday, July 9th, 2013
Public Webinar
Maureen:
Hello everybody, and welcome to Introducing the Agile Extension to the
BABOK® Guide. I am your host for today, Maureen McVeigh.
Thank you all for joining us. I’m calling to you from Ottawa, Canada. We
have Shane Hastie. Kevin Brennan was supposed to be presenting today,
but in Toronto they had more rain in one day than they had in a month,
therefore there was flooding and he has no power, so Shane is taking on
the task of being our presenter for today.
For those of you who are unfamiliar with the International Institute for
Business Analysis, we are the world’s leading association for business
analysis professionals. Our mission is to develop and maintain standards
for the practice of business analysis and for the certification of its
practitioners.
The Agile Extension is one of those ways in which we help to maintain
standards. I’ll do some introductions and some housekeeping, and then
we’ll get right to the presentation. Don’t forget that you can post your
questions at any time in the question box. My role here is to monitor
those questions and to ask them of Shane.
Just a quick introduction of me. I’m the Head of Learning and
Development and have over 16 years of experience in various industries
as a business analyst. Really, my favorite job is working for IIBA and
helping people to develop their skills and their careers as business
analysts. I’m really pleased to be a part of this webinar today.
I’m so pleased to introduce Shane Hastie. He is the Chief Knowledge
Engineer Agile Practice Lead for Software Education, which is an
endorsed education provider based in Australia and New Zealand. He is
a board member of the Agile Alliance.
1
International Institute of Business Analysis
Shane has been passionate about Agile since 1999 when he was
introduced to XP. That, including 30 years in a broad variety of IT roles,
mostly practicing as a business analyst, really made him the ultimate
choice as the Program Director for the joint IIBA and Agile Alliance
program that actually produced the Agile Extension.
A member of the core writing team for the BABOK® Guide 3, he’s really
dedicated a lot of time to the BA community. Thank you Shane, and
welcome.
Shane:
Thank you very much.
Maureen:
Kevin, our illustrious leader, could not join us today, as I said. He’s with
us in spirit. Again, don’t forget to type your questions into the question
box, and I will be monitoring them and Shane will be answering them.
Shane, I turn it over to you.
Shane:
Great, thank you very much, Maureen. Good morning from where I am,
everybody. Welcome.
The structure we were going to use was more a question and answer
between Kevin and myself, but with the weather having taken that out
for us, I’m going to be a bit more of a monologue, so please forgive that
style.
To kick off, I suppose Maureen gave us an introduction of the IIBA. The
Agile Alliance is a non-profit organization. We are a global organization
that was founded in 2001 after the significant event where the Agile
Manifesto was launched. This manifesto guides the philosophy that Agile
practitioners bring to the world of software.
The Alliance is actively looking to explore, to expand, and to extend
those practices. Our goal is to help make the software industry more
productive, humane, and sustainable through the application of those
practices.
You can find a lot more about the Agile Alliance at the Agile Alliance
website and our guiding philosophy, the Agile Manifesto, at the
AgileManifesto.org website.
The other thing that the Agile Alliance does is part of that spreading the
news, so to speak, is we run the annual Agile 20x6 Conference. The next
one is coming up in August in Nashville. I know that the IIBA will have a
stand there, and a number of us will be there talking about the Agile
Extension. We hope to meet many of you there.
2
We wanted to start with the rationale for building the Agile Extension.
Why did we put this together? This goes back a few years, now. This
program has taken quite a while to come to fruition, but there has been a
perceived schism between the communities – the analysis community
embodied in the IIBA and Agile practitioners. You hear roles described
in Agile, and somehow analysts don’t seem to be there. But analysis, of
course, is incredibly important.
As a group, we were looking to answer the question, “What do I do with
my analyst skills? How important is the application of these things? How
does my role change?”
The reality is that Agile projects are somewhat different to perhaps
where many of us have traditionally come from with a more predictive,
sequential style. They are legitimate questions. As a community, when
the questions started being asked, a number of us were looking to find
ways, and various authors out there have been doing it, as well. Practices
have started to emerge, some new practices and the existing practices
that actually we’ve had and used for a long, long time.
What we wanted to do in the Agile Extension was to pull a set of these
together. We’re not saying that this is the definitive, only set and that
there is any one right way. The group of us who put this material
together, who pulled stuff from many different forces, were looking to
find something that is practical and useful for the community as a whole.
Here are two of my favorite quotes in the analysis and Agile space. Scott
Embler, “Analysis is so important that we do it all the time.” It pervades
an Agile project. The nature of an Agile project is very much the just in
time, just enough nature of gathering the detail. We’re constantly
engaged. Every iteration, every cycle of work, every sprint, we’re doing
the just in time, just enough analysis activities that are part of the
delivery of that valuable product increment that is produced in every
cycle.
My friend James King, “We don’t just write code like free form poetry.”
One of the myths about Agile is that we don’t do any up front analysis,
we just sit down and we start building the product.
The reality is all of the Agile approaches, whichever brand you’re talking
about, whether it’s scrambling screen programming, feature drummer
development, adaptive software development, or any of the others, and
there are myriads that fall under this Agile umbrella. All of them have a
structure that says you have to know where you are going, know what
the problem is that you are trying to solve as a team.
3
[reference point 0:10:00]
The way you express that problem will vary. That’s going to be very
context dependent. There is no one size fits all. I think at times, for some
of us in the analysis space, that can be a little bit frustrating, that there
isn’t a nice, clear set of guidelines. I’m sorry, there isn’t.
Every environment is different, every project, every initiative. We need
to find the sweet spot of how much up front versus how much
progressive and evolving analysis, with a bias toward as little as possible
because we know things are going to change.
One of the fundamental drivers for the adoption of Agile in the world has
been the fact that business change happens a lot more rapidly today. I
was reading something recently and the author was talking about the
half-life of a requirements statement. Ten, 12, 15 years ago, the half-life
of a requirements statement was 18 months. 50% would change in 18
months. Today, the half-life of a requirements statement according to
that author is six months. In six months, 50% of what we know about
something will change.
Long, heavyweight, predictive projects don’t work in that environment.
This has been the driver for Agile. Our analysis practices and the
analysis practitioners have to adapt to this very rapidly changing world.
That’s a bit of some of the why. Here’s the history of the Agile Extension.
This is a very brief history. It started before I got engaged, about 2008 or
2009 there was a very slow start. A group of people got together at the
Agile 2010 conference and there was had a workshop where we actually
brainstormed and we used a lot of the Agile practices. I think there’s a
YouTube video actually showing how we worked and what we did and
what we came up with, if anyone is that interested.
After that, the Agile Alliance and the IIBA engaged together. Through
2010 the first chapter was put out for public review. We got good
feedback on that. In August, 2011 a group of 12 of us got together at Salt
Lake City for a writing weekend. That was just before the Agile 2011
conference. This was jointly funded by the IIBA and the Agile Alliance,
and there we pulled a lot of that content together.
That gave us something. In January of 2012 we actually had an initial
draft ready for review. We put that out to the world, and we were
overwhelmed. We got over 1,000 feedback items, and it’s taken us a
while to go through them, to respond to them.
4
Quite honestly, we haven’t addressed every one of the feedback items.
We have them all still on record for those who did contribute. We’re
expecting that there will be another writing cycle at some stage, and at
some point the IIBA will be putting out a call for volunteers to take what
we’ve done and continuously improve it. We know that these things are
never done.
In early 2013 we had a version that we felt was solid, that was able to be
released to the world. That’s what is being launched today. Just to
acknowledge him, Paul Stapleton took our writings and turned them
into a cohesive whole. Paul is the Technical Writer and has done a
tremendous job of taking what was a variety of different styles and
perspectives and turning them into what we have today as the single
voice. We could not have done it without Paul, so I just wanted to
acknowledge that.
What’s in the structure of the Agile Extension? We have, obviously, a bit
of an introduction, a why, a little bit of background to what it is. Then,
we look at a variety of the different branded Agile methods and we only
take a few. We look at Kanban, we look at Scrum, and we look at XP.
We haven’t gone into all of the different brands that are out there,
mainly because we just didn’t have time and bandwidth to do all of that.
There are others, there are things like adaptive software development,
there’s dynamic systems development methodology, there’s Agile
unified process, a whole range of different Agile approaches.
They do have a lot in common, and the Extension is about looking at the
things that they have in common so that business analysis and Agile
approaches, we try to answer the question where does analysis fit in and
how is analysis done in these different styles, different approaches?
The next section is we mapped the existing techniques from BABOK®
Guide Version 2 against the Agile practices and discuss which ones apply,
which ones don’t, where and how they can be used. The reality is, a lot of
the skills and things that we as analysts have been doing , the good
practices that we know about, those still apply. They haven’t gone away.
This Agile Extension acknowledges that and we try to show how they
can be used.
Then, the new stuff. There are 21 techniques that we have pulled out.
Some of them are already mentioned in the BABOK® Guide. Others were
not in the BABOK® Guide, but we have a framework, a structure that we
call a discovery framework and a delivery framework.
5
Being good analysts, we have a structure within that framework. We
have decomposed things. The discovery framework, we came up to
acknowledge here. This was the pulling out these sections of the
framework was work done by Louise Parcinella and Dennis Stevens,
predominantly, but he rest of us certainly did contribute. This was one of
the things that really came out of that writing weekend, was we had this
great structure that we all felt was something that [inaudible 0:19:58].
[reference point 0:20:00]
We came up with that framework at the writing weekend. This was one
of the things that came out of it. I acknowledged Louise Parcinella and
Dennis Stevens as being the ones who actually came up with this
discovery and delivery framework.
The elements of that framework, the discovery, typically the intent with
the discovery component is early on and then constantly through, you
will be looking at the project, at the initiative. The three elements here,
see the whole, look at the big picture, think as a customer, bring the
business value mindset to the fore, and analyze to determine what is
valuable. Make sure that we’re able to deliver the maximum return on
investment and that it’s delivering the right stuff, that we know what is
needed to deliver the maximum benefit.
Maureen:
David asks, “How much was the discovery and delivery idea drawn from
Ellen Gottesteiner’s book, Discover to Deliver, if at all?”
Shane:
Ellen was in the room. She was strongly influential. She was part of the
team. She had never launched the book at that stage, and we knew she
was writing something, but she didn’t tell us what it was called.
Maureen:
The bleeding edge.
Shane:
Yeah. We were, at the very least, strongly influenced by Ellen’s work.
Louise and Dennis came up with these six topics. I think I’m sort of
struggling to remember the precise structure, but I do remember the
two of them actually giving the rest of us a small presentation on these
six. It might well be that Ellen actually pointed out that the discovery
and the delivery is the breaking of the structure.
David, I hope that answers your question. Without wanting to endorse it,
that’s a great book.
6
Maureen:
Thank you so much, Shane.
Shane:
The delivery component, gunning down on an iterative moment by
moment, continuous basis, these are the things that we’re looking within
the team on a day by day basis. Get real using examples, understand
what is doable, stimulate collaboration and continuous improvement,
and avoid waste.
These are the things that we as analysts are expected to be constantly,
actively doing through the life of the project. The discover stuff starts at
the beginning and we continue through it. The delivery, we’re actively
doing this every cycle of work, every iteration.
If we take an analysis approach and a decomposition approach and we
go a little bit deeper, being good analysts, we’ve broken things down
even further. Our techniques for discovery, see the whole and these are
the individual techniques which are in the Agile Extension and which are
explained in there with a view of this is how you can use them.
The tools foresee the whole business capability, analysis personas, and
value stream mapping. Three ways of understanding that big picture,
and making sure that you’re doing the right thing. Look for where the
true value is, understand who our customers are, and know where this
initiative fits in terms of the level of effort and approach that we should
be taking.
Think as a customer. Here, everything is about stories. One of the most
prevalent techniques for identifying needs in an Agile project is this
concept of the user story. The existing BABOK® Guide 2.0 does talk about
user stories. We felt it didn’t go deep enough for us in the Agile
Extension, so we took it, we expanded that, we tackled what do we
actually mean, and then we looked at the different approaches. Story
decomposition, starting with features, epics, and down to stories,
acceptance criteria.
Story mapping, where we see the stories as an end to end sequence and
you have almost a visual process model. Getting to the detail through
user story elaboration, and story boarding being a visual graphical way
of showing flows.
We’re not saying use every one of these techniques on every project, but
we are strongly saying that these techniques are going to be useful. If
you’re going to add value as an analyst on an Agile project, these are
things you need to learn about.
Maureen:
7
I have a quick question for you, Shane. A lot of people are asking this,
and I think it’s a common question. What is the role of the business
analyst in an Agile project? Because there are different ways of doing it,
how would you describe it?
Shane:
The role of the analyst on an Agile project is to be the value conscience
of the team. The analyst is bringing the detail when it is needed, but is
also looking beyond the current iteration cycle sprint or time box and is
thinking about the big picture.
We as analysts have to have two viewpoints. We look up and we look out
to make sure that where this project is going is heading in the right
direction, and then we also are actively engaged in a day by day, moment
by moment basis with the other team members. We are doing the
analysis, and often it’s using these particular techniques and tools. The
activity of analysis is constant and ongoing within that interaction with
the other team members. We’re not typically writing big documents, but
we are facilitating a lot of conversations.
On some projects, the job title ‘analyst’ goes away. The skillset of
analysis is absolutely crucial.
[reference point 0:30:00]
If you are a small team, if you are working with a single prob act with a
single initiative, then the Scrum defined role product data may be
sufficient. This is that one individual who knows everything about what
the needs are, and it may be that that person is doing a lot of the
analysis. It may be that that person used to have a job title of business
analyst. Or, they’re just taking the analysis mindset.
In a large, complex organization, that role of product owner doesn’t
work particularly well. You don’t have the single individual who knows
everything about what the business needs are. You have a complex
community of stakeholders who probably have disparate and conflicting
needs.
There, you will probably see more active engagement of somebody who
would be recognized as a business analyst, bringing the right voice to the
team at the right time, and knowing when that right time is. Does that
answer?
Maureen:
It does. I think because there are different methodologies and that you
can get mixed up in terminology, I think your answer is very good.
One other question just about the role, and it’s from Jane. She says, “We
often found that the BA role increases in an Agile project or as we are
doing the analysis for the next sprint and facilitating the answers for the
team for the current sprint. Is this your experience, as well?”
8
Shane:
Absolutely. In predictive projects we had this perception that we did
some analysis up front, threw something over a wall, and ran away. We
all know that the reality was that we were constantly being called back
and asked and asked and asked and asked because the documents were
never good enough, because we can’t embody all of our knowledge in a
document.
In an Agile project, the engagement of the BA is constant and intensive.
It’s not just a little bit of work up front and go away, it’s with every
sprint, with every iteration, you’re doing work with the team about the
current cycle and you’re doing, the Scrum talks about backlog grooming.
Preparing the upcoming work, as well.
Yes, as somebody taking an analysis role on an Agile project team, you
are busy. What you have to be able to do is to change your focus from
the here and now immediate to the future. Sometimes that future is just
one or two iterations, sometimes you have to actually look up and say,
“Okay, where are we going in terms of this overall product to make sure
that we only build the right thing?”
There is a temptation because the Agile engagement is very deep and
interactive; teams can lose sight of that big picture. The analyst, and here
I like the term bringing the value based focus to the team. We aren’t
talking a lot more about value rather than requirements.
Maureen:
That’s an interesting view.
Shane:
Thank you.
Maureen:
The value view is a very strong one. This kind of leads into this other
question from Trianna. “How do you see the product owner doing the
requirements management traceability? What would you recommend to
manage requirements?” Everybody asks tool questions.
Shane:
First of all, my immediate response when thinking about tools is do not
forget that a fool with a tool is still a fool. Automating a bad process just
makes bad things happen really quickly.
However, tools can help. The simplest tool, and for projects that do stand
alone quite vastly, is just a list of user stories. In Agile we have a bias
towards writing stuff on cards and sticking them in the wall and doing
that visual story wall. That’s really powerful.
Inevitably, we support that with some sort of an electronic record. Don’t
make the mistake that I once did on a team. We were a small group;
there were only four of us. We were working on a small initiative, so we
9
had everything stuck up on the walls and it was great. We had this room
to ourselves for the month or so that the project was going on, and
halfway through we came in on a Monday morning and the cleaners had
been there. Our walls were pristine. Everything was gone.
It was horrifying because it had all been shredded already and thrown
away, so we couldn’t recover it. It took us a couple of days to just get
back to where we were. Subsequent to that, at the very least I’ll take a
photographic backup of my stories every day.
In the vast majority of situations, a simple spreadsheet type list. Don’t
get bogged down in heavyweight tools, but if you’re in a bigger, more
complex environment, there are a lot of tools out there. Naming some
brands that I am aware of, and I’m not endorsing these, I just happen to
know that they exist. Version One and Rally are probably the two biggest
players. Agira with Green Hopper is another one. There’s Serena
software, there’s Exersoft, there are dozens out there.
I do believe that most of them have a sort of community edition that you
can try them out free of charge. Find the tool that is going to work the
most effectively in your environment. Find what level of traceability you
need on the project. Things are going to change. How important is
having that record of change, or is it more about that focus on business
value? We know that change is coming, so don’t get bogged down in
trying to track it.
Maureen:
Excellent, thank you so much. That was a very comprehensive answer.
Shane:
Analyze to determine what is valuable. This is part of that constantly
adjusting, the Moscow Prioritization Backlog Management. Again, that
word value, business value definition.
One of the things we found when we were having the writing workshop,
this term value and business value came to the top all the time. The
Purpose Alignment Model, this is one of the tools to determine where
should we be spending our money, in what way? What areas would the
initiative fall into? Where is the value?
Starting to think in value management terms is probably the biggest
mindset shift. Have we done this all the time? Yes, I think a lot of good
business analysts have and do. We want to really push this up to the fore
and bring it to the front. Value is what we’re responsible for and it’s
bringing that value based focus to the team.
That was the discovery set of techniques. In the delivery framework, the
get real using examples, the technique there – behavior driven
10
development, acceptance test driven development, the specification by
example. Those are different terms for that BDD approach.
[reference point 0:40:00]
It really is a great way of expressing the right detail on a just in time
basis. When we understand what is doable, how do we contribute to
estimation, how do planning workshops work, and this concept from
Chris Nacks and others of real options, incredibly powerful technique to
help us know when is the latest responsible time to make a good
decision.
Stimulate collaboration and continuous improvement. This is something
that, as the analyst on an Agile team, you really have to encourage
constantly the conversations. It’s not a matter of going out and gathering
some requirement. You can’t gather requirements; they’re not
mushrooms lying in the field, which is why I love the IIBA term, the elicit
requirements. It’s not even a matter of going out and eliciting
requirements, it’s go out, find the right people, and bring them to the
team to have the conversations.
One technique that helps in that is collaborative games and the use of
gamification approaches to get people interacting well together. Another
technique, part of all of the Agile processes, is the concept of the
retrospective. At the end of every iteration, every sprint cycle of work,
we stop and we examine both the product and the process and we look
to see what are we as a team doing well, what do we want to improve?
As the analyst on the team, you are contributing to that, and you’re also
bringing your analysis mindset to it. The last of the techniques here, the
avoid waste, lightweight documentation. We actively say we know that
things are going to change. Spending in some cases many years writing
beautiful, big documents doesn’t actually help. What is the minimum set
that is needed?
Of course, the answer to that question is it depends. In some projects
that I’ve worked in, you have heavily compliance driven or legislative
driven set of activities that have to be done. As part of every iteration,
we deliver the component for certification, perhaps, or the component
for compliance conformance that it would be needed to get signable on
each piece.
What we have to do is find out how much is the minimum that will be
useful and add value. That lean thinking of avoiding waste. In some
ways, it’s quite embarrassing as an industry. Lean is a wonderful term
and something that we think about now.
11
The manufacturing industry figured this out in the 1960s. It’s taken
information technology nearly 50 years to catch up. We thought we were
the leading edge. It’s quite embarrassing. Doing the minimum that will
be valuable. That’s the intent of the avoid waste component.
Maureen:
Thanks for that, Shane. I think that’s a really good point about avoiding
waste and keeping things to a minimum. Joan asks a question kind of
related to this. She says, “Much Agile discussion is focused on the front
end of projects. Long term software often gets replaced by other
software that often needs to meet many of the same requirements as the
old software. How does Agile preserve the requirements and rationale
for the decisions made, such that it’s available for reference?”
The old adage, “You don’t know where you’re going until you know
where you were.” Any comments on that?
Shane:
The right answer there I suppose is again, it depends. One of the things
that we need to understand early on in the project is what is the
anticipated life of this thing, and what would future generations or
teams need from us? Then, part of the delivery of every iteration should
be that piece that will help those future teams do their work.
Alistar Colburn talks about software development as if it is a goal based
game of invention and communication. He says that every game has two
goals. The first goal, the primary goal, is to win the current game, to
deliver the product that will meet the current state of business needs.
The secondary goal, and this is one that is often forgotten, is to set up so
that future teams can win their games, too.
The how much do we do comes down to business value conversation,
what is it worth, and what is the minimum set that will be useful for
future teams? In some projects I’ve worked on, that minimum set has
been an internally documented, well structured body of code with a set
of test cases that we can replicate. Those become all that is needed for
the future.
In other projects, we’re actually defined as part of the work for the
project, that we have to provide this artifact for the future teams to work
with. From an organization perspective, we understood the value of that
artifact. It was an as built requirements document. It defined what had
been done with quite a little technical detail, and that was delivered
iteratively along with the code base and the test base.
In that organization, we understood the value of it. They used it. In other
organizations, doing that would be a total waste of time. This is where
the avoid waste and the lightweight documentation comes in. If you’re
12
building a document that is going to go onto a shelf and never be looked
at again, why do it?
If the technical support team and the maintenance teams are never
going to look at your architectural documents or your design documents
in the future, build them to be used by the team now. That probably
means draw them on white boards and take photographs.
If, on the other hand, they’re going to have to go out to an external body
for legislative sign off and licensing before you’re allowed to release the
product, such as in an FDA environment or an airline environment,
that’s a different beast. The value of that beast is the ability to be allowed
to release the product to the marketplace.
I did one project where we were building something that had to go
through a Medicines Control Council audit. The sign off documentation
for that audit was 1,000 pages. I couldn’t turn around and say, “We’re
doing Agile. We don’t want to do your certification documents.”
They would have simply said, “That’s fine, you can’t sell your product.”
We understood the value of the time and money invested in producing
those documents. What the avoid waste mindset says is really focus on
the value. If it’s never going to be used, don’t bother building it. If you
need it as an interim artifact for the team now, then build it in the way
that the team can use it now.
Draw it on white boards, take photographs, post it notes, those things.
They’re valuable to the team at this point in time. Does that make sense?
Maureen:
It does, and it actually allows for quite a bit of flexibility and decisions
around what should and shouldn’t be documented and be still using that
value statement.
I have a couple of questions about technique, so I’m just going to go back
to the Kano analysis.
[reference point 0:50:00]
Could you give a very brief definition of what this is? We have about 10
minutes left, so I’ll probably ask maybe two more questions and then
we’ll go on to what’s next.
Shane:
13
It’s one that I will confess, I have not used it extensively. It is on page 81.
As we say here in the purpose, the Kano analysis helps an Agile team
understand which product characteristic or qualities will prove to be a
significant differentiator in the marketplace and help to drive customer
satisfaction.
It’s a system identifying features that will have the greatest impact on
customer satisfaction, either because they’re exceptionally important or
because the absence will cause intense dissatisfaction. This helps the
team determine which features are most important to implement before
releasing the product to market.
It’s a two by two grid where we write characteristics of the product onto
axes, the extent to which the feature is implemented and the level of
customer satisfaction which will result from how deeply or how
thoroughly this is implemented.
Do we need just the minimum slice, or would there be more value from
producing more and more of this? In an online shopping system, what
forms of payment? We certainly want to take credit card payments, but
are there multiple different credit card types? Maybe it’s a lot harder to
implement integration with American Express cards, for instance.
If 70% of our customers are likely to use American Express, we want to
make sure we do that effort. If only 1% of our customer base has ever
had an American Express card and not likely to use it in our
marketplace, then don’t spend a lot of time building that extra
component.
In using the Kano model that we talk about, we come up with
characteristics, threshold performance and excitement characteristics.
Thresholds are absolutely necessary. If we don’t have them, table stakes.
Everybody has to have this. Performance, increase the delivery and we
get higher satisfaction. There are things customers expect to see, and
they’re beyond table stakes so they’re starting to create a bit of customer
delights. It’s there, it’s nice, and it’s working well.
The excitement ones are the things that create the wow in the customer
base.
14
Maureen:
Probably Zappos used Kano analysis because they’re known as the
customer service kings out there in online shopping.
Shane:
Yes, and I think that they were actually discussed at some point. I
certainly know that we did use various examples when we were coming
up with this stuff.
Maureen:
Excellent. I think it leans towards really focusing your effort on what’s
more important to the organization.
Another question on a technique – real options. Can you briefly give us a
definition of that?
Shane:
Real options is about deferring decisions until the last responsible
moment.
In “traditional” projects, we actually made all the decisions up front. We
did that detailed analysis, detailed requirement, we have everything, and
we made our minds up about what we’re going to do.
We’ve learned that things change. The change management processes
that are out there have caused all sorts of pain for projects, but not
changing is even worse.
In Agile we explicitly defer decision making and the concept of real
options. This is a lot of work from Chris Matts. There’s a lot about it on
the internet. He’s drawn from the concept of financial options. It’s the
ability to know when to make a decision. When does your option expire?
When is it valuable to make a commitment? If we’re doing development,
to choose how to implement this little piece versus consciously deferring
that decision until when it is needed.
The balancing act with real options is known, the just in time and not too
late. Chris often uses the analogy of getting somewhere. If you’re at
home and you have to get to an appointment by a certain time. He lives
in London so he talks about his options would be to take the car, take the
train, take the bus. If he’s going to take the train, he knows that he has to
leave home at 7:00 in the morning to make the 9:00 appointment.
His option to take the train expires at 7:01. Then the only choices he has
left, maybe to take the bus he has to leave by 7:30 but if you take the car
you have to leave by 8:00.
If you oversleep and only get up at 7:35, your option to take the train or
bus has gone. You don’t have the choice anymore. You’re left to the
single choice, which is take the car and then you are sitting in the risk
factors of maybe you can’t find parking and what do you do about the
cost of the travel and the time in traffic jams and all of that. You’ve
actually increased your risk by allowing options to expire.
If you’ve consciously done that, that’s a good thing, or it can be. If you’ve
done that unconsciously by, in that example, oversleeping, you’ve
actually decreased your choices, decreased your options, and potentially
created a riskier environment.
15
It’s a way of assessing when should we make good decisions, and what
pieces should we implement when. A user story is an option. We have
the option to implement that piece of functionality. When should we do
so? This is that prioritization.
The option on that expires when the business need changes. If the only
amount of work we’ve put in is defining that one line user story, the
expiry of that option and replacing it with a different story is not an
expensive activity.
If, however, we’ve taken that user story and we’ve elaborated it in detail
and we’ve spent a week or so coming up with a big document about it,
and then the business need changes, that is actually going to be quite a
bit of waste.
Does that make sense?
Maureen:
It does. Thank you so much. It’s too bad we don’t have more time. There
are so many questions, especially about product owners and different
techniques. We’ll have to move this to a discussion on the IIBA LinkedIn
to talk more about it.
We’ll finish with next steps. Maybe people have asked for your contact
information.
Shane:
I think it’s in there. Is it in there?
Maureen:
Unfortunately not.
Shane:
It’s [email protected].
Maureen:
Thank you so much. I really appreciate it. As always, we want to hear
your feedback, not only on the Agile Extension but also on this webinar,
so please if you have a minute you can complete the assessment of the
webinar.
This has been very informative. Thank you, Shane. I know there’s so
much to talk about with this and an hour is never enough. This is just
acknowledging those folks who have worked on it, and I’d like to thank
you very much Shane for your contribution. It’s incredible how much
work you’ve done.
16
Shane:
It’s been my pleasure.
Maureen:
To the Agile Alliance, a wonderful partnership with IIBA. This is how it
works.
Shane:
Yes. The top left-hand corner is the picture of the people who were there
in the Agile 2010 workshop. The bottom right were those of us who
were at the writing weekend in 2011.
Maureen:
Awesome. What a great bunch of folks.
For more information, go to IIBA.org/Agile. Certainly email us with your
questions and comments.
We really thank you for taking time from your busy schedules today to
join us. You as well, Shane. I know it’s quite early in the morning, and as
usual you’re traveling.
17
Shane:
I am. Thank you so much.
Maureen:
Have a wonderful day.
Shane:
Bye.
Maureen:
Bye now.
18