That is an interesting question. I have been to every single Agile conference since there has been an Agile conference. So, I would feel odd if I didn’t show up. But lately I am not sure I know what to talk about at the Agile Conference. It has gotten so big, there has been a kind of Cambrian explosion of different ways to talk about the same things over the last 10 plus years. What I spoke about at the conference is actually something we were talking about back in – the first Agile Conference was in 2003 and the first XP conferences were in 2000-2001. I am talking about Agile requirements (which is kind of an oxymoron) and Agile development. We are trying really hard to really discriminate between what we really need and what we want. So I am mostly talking about user stories and product ownership. It’s the basics. That is what I was here to talk about.
That’s a tough question because in this conference I am just catching up. We were talking ahead of ... you and I talking and I get puzzled a lot. I spend a lot of my time these days working with software product companies, companies that build software, where they know that the software is the product. It is different than traditional IT.... Let’s say I work for a large bank and I build software for the bank. The bank knows their product, our bank accounts or other financial vehicles and the software supports them in selling that main product, but if I am a doct com, if I am making an iPhone App, that app is my product and I know it. When I work with software product companies, their bigger concerns – let’ say that they know when they are building that app that there is a high degree of risk that people will not like that app, that it will fail. We do a lot with metrics to measure, not just how fast we are building stuff but if people buy this stuff, use this stuff, tell other people about this stuff. I draw a big distinction in talking between output – what we build – and outcome – what happens when things come out afterwards. You measure output in terms of features and story points and velocity and things like that, and you measure outcome in terms of number of people who adopt and use your product and how much, you measure in people’s behavior.
With a lot of companies I work with, when they start really being deliberate about measuring whether this stuff actually achieves anything they intended, what you find is that there is failure but that failure is not what we think it was. Maybe there is 20% or a small amount of things that when you ship it, people say “Things went bad. People reacted poorly. They hate it. They did not like it”. A number of companies I worked with have released whole new versions of website only to find that sales dropped significantly. It hurts, it costs them money. The outcomes were awful. Then there is a small number of things that are really successful. But there is this big – 60% - kind of in the middle, when we release it and nothing happens. Some people use it, some people don’t, noone really cares. It doesn’t hurt us, it doesn’t help us. But, at the end of the day, if we had not spent that money, if we had not built anything at all, nothing would have happened also. I would find an awful lot of the time, what we built is crap we should not have built. So, with product companies, you become very aware of it. You build the stuff and the metrics you are watching for don’t change, they don't go up. It is a little harder to detect in IT centric organizations.
So, I become more aware of it. Now, if you are in a product company – what I find that Agile development is good at is the delivery. It is focusing on how we work together as a team to effectively deliver more stuff, faster. But, if we are in a world where most of the stuff we build is stuff we shouldn’t have built, now we are talking ahead of this. How important is it that our code is well factored and unit tested? How important is the quality, if what we should be doing is ripping out what we just did? How do your strategies change? Now, where a lot of this thinking comes in is in the current next wave of thinking comes in a lot with “Lean Start Up” kinds of practices and the re-definition – a long time ago I used to use the term MVP for minimal viable product – that was the idea that it was a product was viable in the market, that it would be successful, but Lean Start Up has redefined the term “MVP” to mean minimal viable product experiment – the smallest thing I could build to validate my idea. Sometimes the teams I work with these days are focusing on building small experiments and sometimes experiments involve code and sometimes they don’t. Well, where does Agile fit in when we value working software over comprehensive documentation? An experiment is neither working software nor comprehensive documentation.
If it is working software and I am going to deploy it to a fraction of my audience in a test or it is a live data prototype – it is a prototype that actually works its code, it works on top of my data but I am only going to show it to selective users – does it need to be unit tested? Does it need automated acceptance test? Do I need to worry about a lot of the quality issues that I used to worry so much about? Where does all that fit into Agile development? So, what I find myself pondering is: a lot of all those Agile tenants that we have been worried about for the last decade – my concerns shift to more practices to help me determine if I am building the right thing. It is maybe becoming a little less religious about some of those Agile practices as being necessities. They are necessary for delivering high quality stuff, fast, but a lot of that Agile thinking is based upon the huge assumption that what we are building is worth building at all.
I was talking yesterday about using user stories and one of the tenants of user stories in Agile development has become this template – people will consider a story to have this form: “as a type of user I want to do something so that I can get this benefit”. Then I will put up a slide that shows someone learning to ski and they use this technique called the snow plough where you put the tips of your ski’s together. Snow plough is a great practice. If someone was learning to ski, one way that does not work to learn how to ski is to find the best skier on the mountain, follow them to the top and watch as they bounce down a bumpy icy run and say “I’ll do it like that guy”. If you are new to skiing, that is a way to get seriously injured or die. A best technique for learning is this snow plough thing, but there is no Olympics snow plough event and when you see somebody skiing in a snow plough you don’t think “Wow, that is a great skier”. You think that is someone learning to ski. So, when I am teaching somebody to work with stories and things like that, the template has a valuable part, but I want them to recognize it is a learning practice, not a best practice and they need to jettison it in favor of doing other things. So, yeah, when people start contextualizing - contextualizing is for people that understand the basics. It is one of the things that concerns me a little bit about the conference and concerns me about experts that understand the tradeoffs behind a lot of different practices or can do that and maybe someone who has some expertise can help novices make some of those tradeoffs but some of the practices that are most appropriate or most appropriate, given the skills and expertise, there is still value in learning some of those practices that we want to learn to use and then throw away later. I will always recommend somebody learn how to snow plough before they start trying to ski.
I wish it was a little bit more like skiing. I wish if you tried an Agile practice before you were ready you really would break a leg. Then people would know it is a bad idea. These days, if you try a practice before you got the skill, you fail at it and you say “That practice does not work”. When I tried to learn how to snowboard, which I do now, I could have easily walked away after the first three or four times saying “snowboarding does not work” because I failed a lot more than I succeeded at it. I think that yeah, it would be great, but I think it would be great if there was a way for people to learn core practices and there is a track in the Agile Conference for people to learn the core stuff and if people that are newer would sit through that whole track, throughout days 1 and days 2 of the Conference - and that is what I was teaching yesterday morning was the track on requirements and trying to help people rethink what they thought of the requirements and talk about stories and story mapping – a practice I am known for.
But no one wants to do that. No one wants to consider themselves a novice. No one wants to start from the beginning - and again, people coming in to learning Agile development would consider themselves that it’s their job, their profession and they are professional software developers and we don’t want to start at the beginning again of anything. I was talking to someone a little bit earlier on – maybe I am changing the subject too much, but I do not think we think of process right. In our heads we – and I don’tknow who the “we” is when I say this – but we think of process in a very Taylorist-assembly-line kind of way. That there are specific people and roles and the things that we do and if we follow and do these things, the results will come out, like manufacturing something. We fail to take into account skill and expertise and we fail to take into account that we are not assembling widgets and it is not the same every time. When I am teaching the basic core Agile stuff I will do a bit of a word brainstorm where I say “Look, I am going to say the word process; I want you to give me the first words that come to mind”. And I write a whole list of words that people shout out and I will get words like “predictable” and “repeatable” and words like “bureaucracy” and “pain” and things like that and then I’ll talk a little bit about where Waterfall-style processes came from and what they were intended to be and what they evolved to be. Then I will introduce the concept of Scrum and then we’ll go back to an original Harvard Business Review article where Scrum got its name. It got its name from an old Harvard Business Review paper called “The New, New Product Development Game”.
It was written in the mid ‘80s by a couple of Japanese authors and they were comparing, they were looking at organizations that developed new products – that is why it is called “The New, New Product Development Game” – and they were looking at the different ways they worked and they found that people that were most successful - the fastest, the most successful – the way that they worked looked a lot more like playing rugby than they did other things. They used a rugby metaphor throughout the paper; at one point they used the word Scrum and this is where Scrum gets its name. But they saw, when they watched people work, that it looks a lot like people playing a team sport than it does – that made the point of the paper, that looks a lot more like a team sport than an assembly-line-style process.
So then I do the same brainstorm: “Look, if we write down team sport, game here. Give me all the words that come to mind” And then people brainstorm a bunch of words that they associate with games. For instance, when I give people the word “process”, the word “team” never comes up. When I give people the word “game”, “team” always comes up. There’s a lot of adjectives that come up when we stop thinking of process and start thinking of sport. Then, when we start thinking of sport, things like skill come in. No one expects to learn how to play football in a two-day class and then join a professional team. They expect to have to do a lot practice and they expect to skill to come in there. And in processes we have roles and responsibilities, but on teams, we play positions and if you help each other play that position, people can fill in in each other’s positions. There is an understandability with the word cross-functional , but we have specialties and it is a little bit better mental model. So, if I track this all the way back to where we started, I think our heads are broken when it comes to process. We believe we can learn where to stand in the assembly line, so the widgets always come out predictably and fast, but it works a lot more like a team sport, a lot more like playing a game and we don’t acknowledge that there is any kind of learning curve, we don’t acknowledge expertise, we don’t acknowledge the fact that we win and we lose. So, we go about learning wrong.
Katherine: And maybe that contributes to the confusion soup.
Yes. What I see more and more at the conferences, now we have been playing this Agile game for a long enough time that in talking about that metaphor – of game versus process – I will draw distinctions between what are the rules of game and what are strategies and tactics. What we hear people talking about at the conference are lots of cool strategies and tactics. But we know those are a choice and they are contextual, they’re not rules of the process. When people have their process hats glued tightly on, everything new thing they think of has a rule. “Oh, ’I've got to adopt this rule. We have to use Kanban canvas before we start doing anything now because that is part of the process. We have to write stories in the ”As I want to, so that” because that is a rule, it is part of the process. No, it’s not just the learning strategy, it is the rule”. We mistake those two things for each other. So, what we’ve got at the conference is a lot of cool strategies and tactics and they work really well for people who understand how to play the game. But we are teaching these kinds of strategies and tactics that people are just learning how to play the game.
So it is almost like when people come to something like this – the conference – it is a cultural adjustment that they need to make from being in process-centric environments and looking at things in terms of roles and responsibilities and sort of shifting into this game space or game space thinking.
Exactly. So that is the biggest impedence that I see, when people – gosh, I remember we started doing this Agile stuff years ago. It was kind of a breath of fresh air. It was just the simple stuff that we did that made life a lot better, and now, when I am working with the organizations, this Agile stuff is so complicated for them. I have been told a number of times that doing this Agile stuff is far more complicated than the process that we used to follow. And it’s not the Agile, it is not the rules, that are complicated, it’s people incorporating strategies that are tougher than maybe they are ready for and acknowledging that there’s a learning curve with everything. I was just on a family vacation last week and my niece, my brother-in-law’s daughter, is 15 years old and she is studying for her driver’s license exam and she is reading the driver’ s license book while we are there and she is reading all these rules and she is saying “I don’t know why I have to read all this stuff and know all this stuff”.
Learning how to drive seems very complicated for her, but we drive every day, it is not complicated for us because we have internalized all these rules, we know them, it is not complicated any more. I think this Agile stuff sounds very complicated for a lot of newer people. It is because of maybe first, I think, acknowledging that there is a bit of a learning curve, we need to learn some basics, but then it is mixing the basics with all these advanced techniques and practices. I tell people that one of the dysfunctions of process is to fix process with more process. If the processes is not delivering good results we need to add yet another process or yet another rule on top of it and what I see when people are trying to adopt Agile development is that they are trying the basics and it is not working, so, consultants, experts, idiots like me say “Try one more thing! And try one more thing! Let’s add one more thing to this” and they just need to learn the basics.
Katherine: Keep it simple.
Yes.
Katherine: Thank you very much.
Thank you.