It's good to be here, thank you. My name is Tobias Meyer, I'm an independent consultant for Scrum and you can learn more about me from my website agilethinking.net. I keep a blog called Agile Anarchy on Wordpress and that's where you'll find a lot of information about my thoughts, you'll find a lot of thoughts on there. I don't want to talk any more about who I am.
My passion about Scrum is... Scrum is a different way of thinking. Scrum allows you to think in a different way, I should say. Scrum creates the framework for new thinking, new thoughts and new actions, new behaviors. And I think that, for me, that's its power. So, the WelfareCSM course... I need to backtrack here. I was employed by a company as a Scrum trainer at the beginning of this year and when the recession hit I was laid off. In the process of becoming employed by this company, I gave up my consulting business, which I'd been running successfully for about 3 years.
I handed off clients elsewhere, so I found myself unemployed with no consulting business. It allowed me to rise to the challenge, I suppose, about "What am I going to do now?". One of the things I've always been passionate about is working in communities and building communities. So, I thought "Here's an opportunity to explore something I've wanted to explore, which is Scrum outside of the software industry, and to be able to support people who can't afford this training, to get the training. Because there must be people in my position, unemployed, struggling to get back into work and perhaps a CSM certificate might help some of those people.
My model became, to make this available basically free of charge, it's basically to cover costs and to do it in cities I was going to be visiting anyway. The cost of admission to the course was to bring along a friend or colleague of yours who was not in the software industry. That allows people to come and do the training free, but also to give me the opportunity to say "Hey, here is a framework that you might find useful in your legal profession, or in your accounting profession or in your entrepreneurial profession" and to begin to explore how that might apply. That was why I set this up.
3. What have you found so far? You've been doing this for a while.
I'll be doing my seventh one in London next week. This would be my sixth one. Lyssa Adkins ran one of them in Atlanta and we ran two; that we had so many people sign up, we had to spill it over to two. I couldn't do them both, so Lyssa did one. What have I found? I found an overwhelming amount of people who need this - want to and need it - in one way or another, whether it's for personal development or whether it's because they believe it will help them get a better job or whether it's because they actually know it will help them get a better job and all three of those are true.
So there's been an overwhelming demand and of course there would be if people are not pay for something. But, although it's free, it isn't a free ride and I think this is quite important. What I'm doing with these courses is building small communities, building tribes if you like. In order to join one of these courses, you have to commit to signing up to a Google Group in advance of the course, about two weeks ahead; to introduce yourself to the other members; and to learn about them and to do a certain amount of reading beforehand, to learn about what Scrum is and how it might apply and get some discussion going on the group.
So by the time the course starts, people already know each other, there is already a sense of community among those people. I run these, by the way, I run them in church halls, community centers and collaborative workspaces, where there is no facilities to lay on food, so people have to bring their own food. One of the first self-organization tasks is for the group to learn how they are going to do lunch. How is that going to work? Is it going to be brownbag and with everyone looking after themselves, or we are going to do pot-luck, are we are going to get pizza in. Between them they have to figure that out, and I step back from it, I say "This is what you need to do. You need to feed yourselves, you need coffee, you need snacks, you need water" and begin to work that out.We actually sometimes retrospect on how well that went at the end of the first day and figure out a different way to do it the next day. We begin to practice this right from the get-go and the communities tend to stick together afterwards, the groups stay together and they carry on talking to each other. That's part of the commitment I'm looking for, for people.
One or two people slip through and they just take a free ride on this and it doesn't hurt me - probably hurts them in the long term, because the people who really benefit from it are the ones that are in the community with this, learning from one another. Because when we're bringing people in from the outside of the software industry, they are bringing all kinds of ideas and ways of working that we can learn from. So there's an exchange of learning going on here that you typically don't find in a Scrum training course, when it's the trainer who has all the information, and the people who sit there... sometimes quietly sitting there and waiting to be fed, essentially. This is much more of a "Feed yourself".
4. It sounds like it's possibly a much more effective Scrum course.
I don't know how to measure it against other people's and I've worked with other people. For myself, I love these courses. I've done five of them and I have the sixth one coming up and a few more in the pipeline. Every single one of them has been an absolute joy to run and it's been very edgy. I've pushed some boundaries, for my own personal boundaries on how to run the courses, and trying out new ideas in these things as well.
I feel that I can do that because people aren't paying a lot of money expecting an instant result from this. I tell them very clearly at the beginning that these courses are to some extent experimental - running it with people who don't know software. So, I have to learn how to teach all the same things I've been teaching in Scrum and try as much as possible to stay away from software analogies and it's quite hard. And I slip into it and people call me on it.
5. Has this changed your understanding of Scrum or of it's value? Tell us more.
It's made me realize that my intuition was right, that it is a framework that is absolutely applicable in many other fields. I've had lawyers come, I've had a guy who teaches entrepreneurs at university, I've had someone who's a suicide prevention trainer, I've had a taxidermist, I've had a yoga teacher. I've had people from many different walks of life come, and - teachers and community workers - and they are all saying "Yes, I can apply this in my work." I had a video artist and a film maker and every one was saying "This is a really useful framework."
I had met woman recently in Seattle who's an organizational change consultant and she has been for a number of years and she said that what Scrum adds on top of that is a framework in which to do her work effectively. It doesn't change what she does, but it gives her a clear framework in which to do it, which was missing before and that's absolutely what I think Scrum can offer, is this containment. We were talking earlier about the idea of, creativity thrives within boundaries - I think the more you can constrain a potentially creative team, the more creative they are going to be.
The analogy I like to use is the art teacher who tells his students to draw anything they like.
And what happens in that scenario, and I've been in that scenario at school, and what happens in that scenario is people sit around not knowing how to get going, because they can't focus their thoughts and so they just sort of doodle. Or, they start drawing something they've been successful at drawing in the past - they draw their party piece, everyone looks at "Oh, isn't that great!", and there is nothing new, and there's nothing creative in either of those approaches. When the art teacher comes in and says "Here is an apple and here are 3 coloured pens. You must only use these pens and you are going to use grey paper to draw it on and you have to view it through a telescope from this angle in the room", you put more and more boundaries in.
It becomes harder and harder to actually execute against that, but when you do, you suddenly discover a new way to do something, a completely new approach to it. That's what I think Scrum allows you to do - it puts a container around your activities and allows you to emerge creativity from that. It squishes you in, in order to burst this creativity from there, but without the container, you've got, potentially in a software environment for example, where you've got a bunch of very creative people, you've got a bunch of craftsmen, hopefully working together.
If you don't have a container, people will just zoom off in all these wonderful creative directions and not really hold it together. Hacking cultures that emerged in the early .NET boom, many of those companies went under. Not because they weren't creating great things, but because they didn't know how to contain and hold it and drive it forward in a directed way. I think what Scrum gives you is the ability to do that.
Yes, it's counterintuitive. People begin to think that, in order to be creative, you just have to let everything go. It's a big mistake! You have to put boundaries around things in order to focus that creativity.
I think there might be. I don't know enough about Kanban to really comment on that, but my sense of it is that it does remove things. It removes the timebox, for example, and I think the timebox is critical for a pulse, for a rhythm. Without that, you could stray. I think there is a danger that, yes, Kanban could lead you down a path of being into unbounded creativity, which is not a good thing. Clearly, the defined process approach leads you down a pathway of too many rules, it doesn't allow you to actually innovate at all, but there is a different level of rules here.
Scrum is very strict in a sense, it has a very very clear set of rules, it's very disciplined, but it stays away from "how", it focuses on "what", not "how". I believe that most of the processes you'll find in a waterfall environment are like that.
The defined processes and the PMP approach is very often to define how people do their work, to create work, break down structures, and you must do this and then you must do that, and then if you are free at this point, you fill in this gap here, and then and you are dependent on him, and so we tell people how to start doing their work.
That's the problem with that! What Scrum does is, it says "what", it says "This is what we are going to do", which is why it's important for Scrum to stay away from talking about engineering practices, but by saying a clear definition of "done" is "releasable product", every 2 weeks or whatever that rhythm is, you are putting the boundaries around, to guide teams towards finding a solution that's going to work for them. As far as I've learned in my work in the software world there is only really one way to create great software and that's by using pretty much all the practices that XP recommends.
It's the software craftsmanship practices. We want people to find them. We don't want to tell them they must do it, we want to guide them towards finding them, because when they find them for themselves, they are so much more meaningful. A good Scrum coach will help people, to steer them towards those things without proscribing "You must do pair programming" or "You must do test-driven development." Let them discover that that's the right thing to do, let them fail sometimes, in order to discover that. Fail in a box, because failing in a box is quick and it's not so painful and you can come out of that, you can rise again.
8. And that's the other point of the box, that it minimizes your failure. You can learn faster.
One of Ken Schwaber's famous sayings early in Scrum, is that Scrum guarantees you failure in 30 days or less. That's its promise. And I say that in the classes I run, because it's a powerful statement - Scrum guarantees you failure in 30 days or less - and it does. And the great thing about that... And of course now it's even faster - 2 weeks or less. The great thing about that is that it allows you to change direction and do something different if you are heading down the wrong pathway, which is exactly what we want. Scrum succeeds in a sense through a series of failures.
9. The failures - not everybody sticks to it. Failures are painful.
They are not when they are small. When these failures are small enough and frequent enough, they are no longer failures. Failure becomes the wrong word, they are just a process we use to build something. Rather than trying to build it like this, we are building it like this, but rather than building it, "Oops, go back to the beginning" it's kind of like really fast failure and you are spinning towards your goal by a constant process of tripping up and standing up and tripping up and standing up and moving forward. It's exciting to work in that way, it's thrilling. You are exploring new kinds of potentials, but, again, in this kind of container, you are not going crazy.
It would be nice to believe that Jeff Sutherland and Ken Schwaber knew exactly what they were doing at the beginning and maybe did.
Maybe they just got lucky. I think what they did is they created, perhaps almost accidentally, just by who they are and what they have done in the past, they almost accidentally created something that is so much bigger than the world of software and it's beautiful to me that something as almost marginalized as software development becomes the breeding ground for a way of working that can expand across thousands of different industries and across the world. That's a powerful thing!
And for people who are in the software craftsmanship movement or the XP movement, to feel threatened by that, is too bad and I hope that they see Scrum for the potential it has and celebrate being part of that, because the software craftsmanship movement, by the way, is something else I'm also passionate about, having come from a software development background. I love the beauty of writing software, I love writing beautiful software.
When I first got into that, someone said... I come from an artistic background, and a couple of people said to me "It's a shame you didn't go into an artistic endeavour", it stunned me. Software development is one of the most artistic things I've ever done in my life, because it is - it's a craft and it's an art. If people don't get that, they shouldn't be in this industry, they should be looking for different jobs. But that's separate, that is a separate thing from Scrum - software craftsmanship/XP is totally separate, they are not fighting in the same space at all, there is no need for that.
12. But they work very well together.
They work beautifully together. They absolutely work beautifully together, and Scrum will move into different places and perhaps some of the concepts of XP will move with that. I'll tell you one of the concepts that I use is test-driven development. Test-driven development doesn't have to be bound to software in any way, test-driven development is simply defining an outcome that you are trying to reach ahead of time. You are leading through testing all the time. I'm going to clean my living room, I know what my outcome is going to be. I can define that and I can say "These are the conditions of acceptance for a clean living room.
I can discuss that with my partner."
Once we've discussed it and decided on what to do, we might need to go - if we've just moved into a new apartment - we might need to go and buy a vacuum cleaner so there is some of the tools that we might need. Then, we start doing the work, but the work is secondary to the testing. And that's another interesting thing as well, because in software development teams, traditionally a software coder - the person who writes the code - is continuing to be higher up than the tester who just tests it.
I think XP and software craftsmanship, turns it on its head, it says "Lead through testing". The testing is the design, essentially - the testing is the design. For me, writing the code has always been the easy bit. I can't even type properly, I don't even touch type, but then people say "How can you write code if you don't even touch type?" Because writing code isn't about writing code. It's about thinking about tests, and it's about defining the outcomes of what you are trying to do - that's the creativity.
Apart from the framework of Scrum which is to have the meetings and have a backlog and these kind of simple things, it also has a set of underlying principles and they are empiricisms: the idea of an empirical process is learn by doing, drive by hindsight not foresight. Self-organization of course, is an important one and collaboration and time-boxing the other two, essentially. One of the key things in there is prioritization. This idea of only working on the most important thing that you have to work on and defining what that is in a really clear way, trying to get a sense of...
This thing that Kanban talks about is minimal work in progress, minimal WIP, as if it's something new. Of course, it isn't new. This is a common sense way of working and it's something that anyone who's been doing Scrum for any period of time is absolutely following that. You minimize the work in progress because it's all about focus - one of the key values of Scrum. In fact, I think the conversation I had with Jeff Sutherland recently led me to believe that focus is the primary value of Scrum, it's keeping everyone focused on the most important thing to work on now.
If you are doing that, you cannot work on other things. By its nature, it keeps WIP to a minimum, just by the nature of focus. A good Scrum... Scrum done well is about choosing the most important thing to work on and focusing on getting that thing all the way through to "done". "Done" means whatever it means in whatever context you are in.
14. But it's very important to get to "done".
It's very important to get to "done". If you don't get to "done", you end up with "half-done" things. And "half-done" things are work in progress that you don't want. And this applies... I use this idea of completion in my daily tasks. If I have a task that's to write a letter to someone, the outcome of writing a letter is to stamp it, address it and put it in a postbox. So I'm not done... If I have a letter half-written on a table, it's not done. If it's fully written and in an envelope, it's not done.
It isn't done until it's stamped and in the postbox. Then, I can check it off my list. We do that in a very natural way in our lives, we do this, when we stop to think about it. And if we don't, we end up with this accumulation of junk all over our desks, of things that are half finished and we lose context. A lot of people have found value from the way I teach Scrum into applying it to their own life in this way. Let me get a task board on my wall.
It's very powerful, isn't it? It really helps you as well to see when you've got too many thing in progress at one time, it's a big visual picture of that. Many people who've done the Scrum training course take away the idea of a task board. I teach... The task board isn't actually an artifact of Scrum. Scrum does not proscribe it at all, and yet every single Scrum team I've ever known who's doing Scrum well use a task board. The weak Scrum teams are using electronic tools. That's my experience and it's the experience of many people, not just me. The task board is the heart of Scrum, I think.
17. It's where you have your stand-up meetings, it's where you discuss it.
Yes, it's where all the collaboration happens around. All the updates happen there - the empirical process is there, the feedback is there, and the sense of team is around that board as well, especially for teams that, for some reason are not able to sit in a shared space. But even with those teams, the task board becomes the focal point. What are we going to do next? Not "What am I going to do next?" but "What are we going to do next?" - that's how you minimize work in progress by having multiple people work on single things and do it well.
I want to wrap up with this WelfareCSM idea. It seems like an altruistic approach and in some ways it is, but that's not the driving force behind it and I'm a great believer in "that there is no such thing as an unselfish act". My desire to run these courses has many selfish aspects to it. One of them is to be able to explore the spreading of Scrum to other things, other industries. But, it's not a bad thing to be selfish because sometimes other people benefit from that. What I've found though is that there are more people who want to do this than I first anticipated would and so I'm exploring other financial models for this, one being an auction, kind of eBay type auction, to sell off the places that way.
Another one is a sort of a blind bid, and the blind bid would be twofold, it would be a financial bid and it would be an emotional bid, like "I'm offering $100 and I'm offering $100 because..." and they give me a reason: "I'm unemployed, I'm struggling, I'm trying to feed my wife and kids and I really need this because I think it's valuable".
Someone else might say "I'll offer you $1000 because that's roughly the going rate, because I'm employed and I'm happy to do it." From that, those blind votes I'll be able to put together a course that feels balanced in some way, because I need to earn money too and clearly I'm earning. I went to Atlanta for 4 days and ran one of these courses and I made $400, that was my take from a four-day consulting gig, if you like. I'm at the low end of the consultancy scale with that. I want to push myself up a little higher.
What's good also is that the Agile community in general is a giving community. There are other trainers interested in this model as well, exploring how to do it and not hurt themselves by doing it. Doug Shimp is running a course in Chicago on a weekend, he is choosing to do it on a weekend, so it doesn't interfere with his regular consulting work. It's a sort of a mix of offering free places to unemployed with a few paid places in there as well. It's nice to see different trainers kind of like exploring other ways of supporting the community of people who want to learn how to be Agile. That's really what it's about, isn't it? It's like supporting everybody equally, not just those whose companies pay for them.