but here I wanna kind of go in a little bit of a journey with you

that's not gonna necessarily.... I don't wanna tell you where we are going

so as a result there's no clear title, but the journey begins

with one of my big frustrations with agile software development

I mean, the agile revolution has had a big impact

and it's been remarkable and very gratifying to see the impact it's had

But there have been frustrations

And there's one particularly big frustation that gets at me

Now, one of the benefits of agile

it's in the days before agile thinking

we had this notion that if you wanted to build software you have to come up with

everything you wanted done

put it together in some great document and sling it over and build software.

And we know how well that worked.

and it's very good but the agile world next splitted things up

breaks things down into independent little units of capability

often called stories and then build those stories one at the time

and by building the stories one at the time

we get a lot of benefits: we're able to get feedback as to where we all going,

we're able to see our progress

and in particular we're able to steer, we're able to change direction as we learn

and that's of course a vital part of what this whole thing is about

but there's still a problem here

and the problem is that arrow there. The notion that the stories

are given from some kind of Business Analyst kind of role

handing then to developers to code up

but the development team ends up being a passive recipient of stories

and I come across this great deal in different places

both in Thoughtworks and outside

where developers basically see themselves as we're an engine

to turn some stories, maybe some rough tests, into actual code.

We build whatever we're told to build, we don't really get involved

in thinking about what it's will to the building.

And this is very much against the idea that was at the heart of

pretty much all of the agile founders.

If you get a bunch of people from Snowbird together and you say

What do you think, that, you know,

that developers should be just building what they were told to build?

They will be horrified!

And... when we were coming up with names to agile...

hmm... Kent suggested

because at the time we didn't have the term agile software.

We needed to come up with what word we use.

We ended up picking agile, but one of the suggestions that Kent came up with,

was the word conversational, because he thought that the essence

of this approach was these conversations between the development team

and the business people about all aspects of software development

including what should be built.

And the idea here

is that developers and analysts

should collaborate together to decide

what stories should be built, instead of the analyst

feeding stuff, or the business, feeding stuff to developers, it should be just

too, I think.

And a little example of this.

I think illustrates it quite nicely. There's a story

and this isn't gonna story from Amazon where one of the developers thought that

would be a really good idea

to, when people are working in the shopping cart,

to put 'you might like to buy so and so'. You know, by analyzing what they've bought

By analyzing all the data that they have, some suggested items that you might wanna add.

And the businessperson involved said 'no, no, we don't do that because...

...we don't want to distract people while they're shopping in shopping carts, right?

Because, you know, what is the most important thing for Americans? Shopping,

exactly, so you know, 'focus on the shopping cart!'

Now, this being Amazon, the developer said

"no i think he's wrong" and so he actually built a version of the shopping cart

with the suggested things in there and ran A/B tests.

And was able to prove, by looking at the numbers,

that it increased revenue. And being Amazon, that you know,

businesspeople said "well, yeah, we can't argue with the numbers", so they

carried on doing that. And now is that notion of collaboration.

As software developers

we are familiar with the software world and what software can do

which means we can come up with ideas.

There's no rule that says all the stories need to be developed by the business.

It's true I think that they should prioritize them

And they should have the final sign what gets built in what order

but the ideas that you come up with, are often based on collaboration.

I remember a story of, an early ThoughtWorks project,

where we're doing some stuff with the database

and they did a little demo early on in the process, and that was just showing

all we've got this information in the database. And they were showing the customer

and the customer looks at the data and said:

"Hang on, if you've got this data there,

could you answer these questions for me?"

And they had a conversation and the developer was thinking SQL queries,

and the business person was thinking business process

and they figured out: yes they could do this.

And he said, well I've never asked this, but actually if we could build this,

which seems to be trivial,

that actually justifies the entire cost of the project right there.

I never even thought of coming up with that requirement

only in the conversation did it come together.

And so, conversational stories,

the idea that we should work together and collaborate to come up with what we build

is a fundamental part I think of what agile ought to be about.

And that's, of course, the whole notion of things like monitoring and AB tests.

We begin to explore what should be built by actually watching what people do.

That's, I think, a really big step forwards.

But in order to do that, it's important that developers

get a better knowledge of what the domain is about.

Because that knowledge is vital to be able to do this.

And this is one of the areas where, I think,

we've been a bit disappointing as a community.

In that we haven't put enough effort

into trying to know about the domain we work with.

I remember talking to a friend of mine who was a project lead on a team doing some

really interesting scientific work around genetic modeling

and he was very disappointed that most of the programmers on this team weren't

interested in finding out more about the genetics.

They weren't interested in the science, they just wanted to be told what was built.

To be really effective as a software developer, I think you need to understand that domain,

get to find out how it clicks and how it works,

become knowledgeable in that domain,

and then,

you can really influence what would be the most useful software to build in that domain.

You'll never gonna know as much as the expert in that domain.

When I worked in health care, you know,

no one's gonna ask me to become a doctor

just because I've done some computer work in the area

but that knowledge I did have was very valuable

in collaborating over what to do in terms of the software.

And in fact, when people come to me for career advice

and they say, "should I learn Scala or JavaScript or Clojure..."

I say well it's less important about learning about languages,

they come and go...

Learn the domain that you are working in.

and they are not really that different when it comes down to it.

That is a very useful skill,

and even if you end up moving to some completely different domain later on,

the knowledge of how to learn domains and how to work with them

is gonna be something that's gonna be really valuable for you.

And as well as knowledge,

I think that also brings in another thing, which is responsibility within that domain.

And here, I wanna bring up a topic that you might have heard of.

something called "Dark Patterns".

"Dark Patterns" is a website that

it's really about help people use the user interface.

encourage users to do things that are actually not in their best interest

Simple example of this:

imagine again with shopping cart, we are buying some electronics items, you know

a new camera or whatever.

And the people who run the web site say, "oh, he's bought a new camera"

Well, I know what I'll do, I'm gonna put insurance for that new camera

and I'll put it into the shopping cart, automatically.

The user didn't ask for it,

They weren't offered a popup

that says "do you want insurance?"

So user says: "why would I buy insurance on something I can afford to replace?"

"This is just a money spinner for the retailer, isn't it? No."

No? What instead they do? Just pop it in a shopping cart anyway.

Now of course I might notice that shocking item in the shopping cart

and remove it, that's perfectly okay, they make that possible.

But they've put a thing in the shopping cart

without asking me deliberately.

Now that is manipulating a user to doing something

that's not probably in their best interest.

Similar thing is, if you have something where,

"hey, sign up for free!"

And then I have this recurring 30 dollar-a-month billing thing

and they make it really really hard for you to cancel.

You know, you got this form and that form

and you know, half of the time you hit the button

submit button for the cancellation, you get a 500 error...

I mean, that is often bad, and sometimes is done deliberately.

Those things are dark patterns, and I think, we as programmers,

have got to make explicit the active rejecting this.

We need to be advocates for our users.

And my point here is:

If you write code for that dark pattern,

if you wrote the code that slips the insurance into the shopping cart

without the user asking for it.

You are every bit as responsible

as the person who asked you to do it.

We are responsible for the software we write,

both good and bad of what goes in there.

Now I'm not necessarily saying, you know,

if somebody asks you to do something like that

you should automatically quit your job, otherwise you're a bad person.

You know, I know everybody has to balance a lot of things in their lives

and all the rest of it,

but you are responsible for the decision to write that code

and you have to balance that responsibility across everything else.

Too many developers take the point of view which is...

...it doesn't matter what I code, I just follow orders.

I just code what I'm asked to do.

I don't think that is good enough.

I think it is important that we, as developers, say

what we do is something that we're responsible for.

We have to take that responsibility on.

So, dark patterns surfing an obvious case of where

we have to think about ourselves differently, and say:

we need to be advocates for our users.

But I think even goes further than that.

I mean, so far I've talked about a relatively small world

of users and analysts, some programmers...

developing software, coming up with things...

But, of course, that software and our users

are making an impact upon the world.

And we're also, in part degree at least,

responsible for that impact.

We have to say what impact is our software having on the world around us.

And that can affect, again,

what we choose and where we choose to work.

In my younger days I spent a bunch of time working in healthcare

and I had the chance and did some consulting work in the City of London,

in the financial industry.

And I was quite keen to do that, because financial industry is quite interesting.

You know, this weird financial products

intellectually interesting thing to work at.

But having worked there for a while,

I realized I didn't wanna work in that kind of place.

Because I didn't really feel that what they were doing was giving value to the world.

You could tell it from the way they treated their customers.

As far as they're concerned that customers were

a little bit more than just people to be taken advantage of, you know,