Now, if you were to read the definition of something that read that something, let's call it X, for that X there are certain roles, artifacts, events, and rules that

have been defined somewhere. And these roles, artifacts, events, and rules are immutable. And although implementing only parts of X is possible, the result is not X. If you read something like this and you're wired anyway like me, then perhaps you might

think about this being something like a radical political ideology that we're talking about or maybe a religious cult or something of that nature, right? In fact, the X that we're talking about is Scrum by its own definition. This is a direct quote from the Scrum Guide by Ken Schwaber and Jeff Sutherland, which

by its own definition is sort of the definitive guide, the definitive reference to Scrum. So when we're talking about actually implementing Scrum, we'll first have to think about what

it actually is. So what is Scrum really? Well, the thing is that Scrum even by its own definition isn't exactly sure what it is. Because if you look at the opening paragraph of the Scrum Guide, it will say that Scrum is a framework for developing and sustaining complex products.

Fine, that sounds relatively reasonable. But then you go on to where it says definition. And then there's a definition of Scrum where it says a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.

I think a few bingo cards just went off. By the way, just for the sake of completeness, Wikipedia has an alternative definition and that is Wikipedia says it's an iterative and incremental agile software development framework for managing product development, which I guess is sort of a retroactive definition.

Regardless, as you can see, that's basically, that's a bunch of jumbled buzzwords, right? And it's been like that since about 1995. So Ken Schwab and Jeff Sutherland, who are frequently referred to as Ken and Jeff in

the Scrum literature, first presented Scrum in 1995. So it's a little over 20 years old by now. And they claim that it had previously been, and I quote, tried and refined before they formalized it, before they first presented it at a conference in 1995 at companies like

Individual, that was a newsfeed company that was subsequently acquired, well there was a series of acquisitions, now they're part of Reuters. Fidelity Investments, those still exist today. And IDX Systems, they are now a part of GE Healthcare, also via a series of acquisitions. So they're saying that by the time they first wrote it down, by the time they first

presented it in 1995, it had already been tried and refined in actual development use at a bunch of companies successfully. Now I don't believe any of that, but that's what they say. So what is Scrum like?

This again, this is taken directly from the Scrum Guide. Scrum is defined to be as, and again, these are a few buzzwords here that should really set off a few alarm bells if you've ever read anything like this before. Scrum is said to be lightweight, simple to understand, but difficult to master.

Now I think that is actually a stroke of genius because what the authors managed to put into the very definition of their method is the possibility of you, me, and everyone else simply being too stupid to do it, because remember, difficult to master.

So maybe you're just incompetent and you're doing it wrong. Also, lightweight and simple to understand, let me translate that for you. That's basically, well, we're not actually defining a whole lot, but at least we're describing that in simple terms.

So it's basically more or less almost nothing. So let's look at some of the things that Scrum actually postulates. Some of these it postulates explicitly, some of them are implicit and sort of underpin the idea of Scrum or the ideas and the methods of Scrum.

And we shouldn't just look at what Scrum postulates, but more importantly, whether any of it actually makes any sense. So there's one very, very central tenet in Scrum. And this is one that by and large, I'm actually not going to argue much about.

And that is Scrum says, teams self-organize. Now I think every one of you will at some point in their lives have been in a team that was perfectly capable of self-organization. I certainly was. I'm sure you have. So this is not something that I'm going to argue as being patently false.

It's very clear. And I think it's self-evident and self-explanatory that teams are capable of self-organizing. But from your own experience, you'll probably agree with me that there must be, that we must meet a very critical precondition to teams actually being capable of self-organizing. And that is stability.

The more stable a team is, the less a team changes, the more it has a chance of actually becoming self-organizing. In contrast, if teams constantly change, they don't stand a snowball chance in hell of self-organizing. Now let's see how we can apply this to the software industry.

There's two things that are true about the software industry, which is one, we are a very growth-oriented industry. If software companies are healthy, they grow, they hire more people, they grow their teams, teams change. We're also a very competitive industry. Competitive in the sense that employers, companies,

compete for developer talent. It's clearly more or less a seller's market when it comes to job talent in the software industry. So as a result, both you or the colleague that you're working with might easily have an offer that's too good to turn down on their table next month. And then that's one of your colleagues that's gone from the team.

And maybe at the same time, you're hiring a new person, or maybe you're growing and so you're bringing more people onto the team. Now, some of you may be familiar with something that's sort of almost an old rag in psychology, Tuckman's stages of group development. Some of you may have heard about that. It was first written down in 1965.

You may have heard about this thing of where teams go through a forming, a storming, and norming, and performing stage. I'm not going to try and beat a dead horse here too much. This is all sort of very reasonably well known. And as anything in behavioral science is always under a certain degree of discussion.

But I think what we can all agree with is that when a team goes through these stages, and the evidence is pretty good that most teams do, then the moment there is a person joining or leaving a team, you have a new team and you effectively start over. Now, you can have people who are very, very capable of dealing with these changes,

and then these phases are somewhat compressed and they take less time to complete. But the thing is your teams will go through these phases. And so the very idea, very basic postulate of Scrum goes out the window when we apply Scrum to the software industry for the very simple reason that we don't,

we're pretty much unable to meet this prerequisite of team stability. Let's talk about a few other things that are defined in Scrum. In Scrum, we have basically a time boxed time period, which is sort of our central unit of planning.

And that period is called a sprint. And the Scrum guide says that a sprint is one month or less. It doesn't really say much about anything else. In theory, you could have sprints that are one day in length. That doesn't really make a whole lot of sense. For most companies, it will be something like one month or half a month or maybe a week if they iterate extremely quickly.

If you're, by the way, if your company is using sprints that are longer than one month, congratulations, your company is not using Scrum. Because remember, you know, rules, roles, artifacts and events are immutable. And if you change anything, that's no longer Scrum, right?

But the important thing is that Scrum expressly says every sprint is followed by another sprint. Like immediately without pause in between. It also says a few things about how a sprint should be organized from a sprint planning session to the actual development sprint that you're doing, to a sprint retrospective and so forth. But the important thing is that every sprint is immediately followed by the next sprint.

It strikes me as baffling how someone could come up with something like this because effectively it's like running the New York City Marathon as a series of 100-meter dashes. That's not going to work too well.

And software development is very much a long-distance sport. And I'm of the conviction that if you're organizing software development as one sprint after another sprint after another sprint, the only thing that this can possibly lead to is very, very profound exhaustion. And eventually you're either going to run yourself into burnout or worse, you're going to do that to other people.

Then there's this thing in Scrum. Again, this is an immutable event, the daily Scrum, right? The daily Scrum is defined, this is actually funny, it's defined as a time boxed event of exactly 15 minutes, okay?

Let's give them benefit of a doubt here a little bit, okay? So let's say it's approximately 15 minutes, but it can't be any longer. That involves the entire development team. And every member in the development team answers the following questions. One, what did I do yesterday to help my team achieve the sprint goals? Two, what am I doing today to help the team achieve the sprint goals?

And three, what's holding me up? What are the obstacles that I see impeding myself or the rest of the team from making progress? Now, I find it amusing that the authors of, or the inventors of Scrum

named their defining daily occurrence, that is so defining that it actually names the whole method overall, after an event in a reasonably violent contact sport that is so potentially dangerous that professional practitioners of this sport

recognize a safe word which they utter in the Scrum when they fear that their necks might be broken, okay? If you're a professional rugby union player, people will recognize the safe word neck if players are pushing down so hard on your own neck

that you fear it might snap. I think it's really bizarre to use something like this as a metaphor for a daily team meeting. I think it's really, really weird, but that's just a technicality. That's just, you know, naming things. That's one of the two hard things in computer science, right?

The other things are cash validation and off by one errors. But while we, beside the name, right, even if Scrum called it, you know, the FUBAR meeting or whatever, the very idea that your entire development team gets together at a fixed time every single day of the week

to discuss these things strikes me as positively anachronistic. It was fine, I guess, in 1995 when people could generally be expected to work out of the same office when development teams were rather geographically closely located.

But I think it's completely out of this world in 2016 when the default is that software development teams are geographically distributed. Some of them may work in offices, some might not. Okay, fine. We have excellent video conferencing technology at this point.

So we might actually use the physical meeting and translate it into something that is virtual. But people work in different time zones. People work based on their own way of basically, you know,

chunking up the day into work time and family time and so forth. The idea for everyone to get together in a 15 meeting at the same time that is somehow compatible with all time zones, I don't see how that works. I have a colleague who works in Brazil. If we need to get together on a conference call

with a customer in Australia, that's almost impossible to schedule, even if it's just for 15 minutes. Try doing that every single day. That's not going to work too well. Another thing, this is not expressly stipulated in the Scrum guide or anywhere else, but it's something that strikes me as relatively typical

of organizations that are attempting to practice Scrum. You might have garnered at this point that I don't really believe actually implementing Scrum is physically possible, but at least a few or a lot of organizations try to, is the thing that you're planning generally covers the current sprint. You have basically short-term planning,

that's your daily work, and then you've got your sprint, and that's about all the definitive planning that you're doing. Beyond that, you have a product backlog. The product backlog is prioritized, so you know in which order you're going to be doing certain things, but you don't really know, and you also know when your next sprint is going to be,

but you don't really know, okay, what are we going to do the next sprint? What are we going to do the sprint after that? Because that's kind of, you can't do that. Now, okay, fine, this might work. In my humble opinion, it will likely only work if the number of customers that you have is zero. Customers are users, it doesn't really matter,

but people will want to have some sort of information when they can expect certain functionality or certain features. Now, people are generally fine with understanding that software schedules tend to slip, and that these, I mean,

unless you're actually dumb enough to make a binding commitment, but if you're just saying, okay, we're expecting this feature to land by time x, or by release x, which is expected at time x, people are generally willing to understand that these estimates are to some extent tentative, because you might be running into certain issues,

you might be running into bugs, certain things might take priority and so forth. But having no planning at all is something that has also been described as just being dangerously short-term. You generally tend to lose sight of the big picture if the only thing that you're really caring about is your sprint and nothing beyond that.

Now, I'm not gonna argue that something akin to what we're doing in Scrum development isn't reasonable under certain circumstances. For example, a method like Scrum, it's not gonna be Scrum,

but a method like that where a team comes together, elects not so much a leader, but a spokesperson, and then just starts hammering away at a task, that's something that's entirely reasonable for emergency situations. And I don't necessarily mean life-threatening emergencies.

It may be something like, okay, if we don't ship this by time x, our next funding round doesn't come in, or something like that. So under those circumstances, I think it's perfectly reasonable to use an approach like, okay, we're gonna get together, we're gonna elect a spokesperson, we're gonna divvy up our work, and we're gonna start rolling.

And then importantly, when it's done, we go back to our usual mode of operation. And if you're using a development method that is reasonable for emergencies all the time, that basically means that we're acting as if our company was always in an emergency.

If your team is permanently operating in emergency mode, you need to quit. And it doesn't really matter which side you're on. If you are basically a developer on that team, then you need to get out of there because you're in a really bad place, and it's only gonna get worse for you.

And if you're someone who actually imposes this method on the team, then you're doing something even worse because you are basically burning your people out. And that's not something that you wanna do. By the way, just for the sake of completeness, specifically in large corporations, if you are up at the CEO or CXO level,

it's relatively common that those people are going to spend most of their time fighting some sort of fire, responding to some emergency in the original sense, something that has just emerged that they need to react to, fine, but it's not something that should trickle down

all the way and should not govern your entire company. One thing that Scrum advocates, and I'm not gonna ask for raised hands for Scrum advocates here. One thing that Scrum advocates frequently tend to say or put forward in favor of Scrum

or in defense of Scrum, or for that matter, really in the defense of Agile, is that they're saying the waterfall method is bad and Scrum, insert Agile here if you want to, isn't novel. So Scrum is kind of like a manna from heaven

that finally sets us free from waterfall, right? Now, this is almost like a bit of a straw man, right? And it's also not true. I mean, the whole novel thing isn't true. And it hasn't been novel since about 1975. If you are in any kind of software development

or engineering role, if you have not read this book, you've made a big mistake. You really should. It's a classic. It's Fred Brooks's Mythical Man-Month, Essays on Software Engineering. It originally came out in 1975. It had a 10th anniversary and a 20th anniversary edition where additional content was added.

But what he said back then was, waterfall is a terrible idea. And in fact, guess what he proposed? He proposed a model of iterative development. He basically said, what you should be starting out with is a piece of program as it was called at the time, right? We're talking about programs

because we're programming from mainframes at the time. But basically he said, you should start out with a program that perfectly does nothing, right? That's perfectly fine at doing nothing and then you add features iteratively

and you always continuously have a working program. Now at the time, he called this the spiral model of development. Since then, that term has slightly shifted. So that's why I'm not referring to this model as the spiral model because now you're thinking of spiral model as something slightly different, which is a risk-based development method

where you have a certain set of features and now you're thinking about changing these and then you try to assess, okay, what's the risk that associated with this? It's a very, very defensive effort. So the meaning of that has changed a little bit. But if you want to look at iterative software development, you really don't have to go to 2005 or 1995.

That's an old hat. That's something that's much longer. And so to present Scrum as the antithesis to waterfall, that's just, yeah, okay. You're comparing it to something that we all know is terribly imperfect anyway. Something that I think is particularly toxic about Scrum

is that Scrum advocates frequently tend to argue along these lines, which is if the Scrum method doesn't work for your team, your problem is your team. You should be firing some of your people and you should be hiring people that are better at doing Scrum.

I firmly hold this to be untrue. If Scrum doesn't work with your team, your problem is Scrum, not your team. And what you need to change is the way that you're doing your development method and not necessarily the people on your team. A corollary to that or something that you frequently find sort of in the same vein

is if Scrum miserably fails to deliver results in your organization, it's because you're doing it right. I think this would only, this is because you're doing it wrong. I think this would only happen if you're doing it right. I don't think this is possible, mind you.

I don't think it is possible in an organization to implement Scrum by its own definition, which means with all the rules, roles, artifacts, and events completely unchanged, I don't think that you can really do that. But if anyone were to do it, I think it would certainly lead to disaster

and straight into it. So here's my first message. Please just don't be a Scrum bag, okay? Try to not be a Scrum bag. If you were at some point, here's rehab for recovering Scrum bags.

Because it turns out there are certain things that we find in Scrum and in Agile and so forth, that are actually reasonable. Now mind you, I'm not gonna argue any of this as doing sort of Scrum half-assed,

because by its own definition, you cannot do that. So what I'm talking about is certainly not Scrum, but there are certain things that we can salvage out of what Scrum postulates. And you know, salvaging things is not necessarily a bad thing. Something, sometimes you can go through a pile of rubble in a landfill and find some really, really valuable things.

This is the Atari game dig in New Mexico in 2015. You know, Atari in the early 80s dumped a bunch of game cartridges for games that didn't sell. Just basically buried them in the ground. And so, and now of course, some of these cartridges are like worth hundreds of dollars. So they dug those up and they got a special permit for the,

dug those up. And you can, there's like several Atari 2600 cartridges of ET, the extraterrestrial, which they dug up from this landfill. So there's one thing that I personally actually think is a reasonably good thing in Scrum, even if it's not very adequately named, right?

A product backlog, a backlog is something that's sort of akin to a traffic jam, right? It's an impediment to movement. So it's like, it's a little weird as far as the naming is concerned, but the very idea that you have a transparent list of things that your product

should at some point do, and then be able to prioritize that, so you know, okay, this is what's more important than this other thing, provided that you actually take an order of priorities that ranks things that are important higher than those that are urgent, right?

I think a product backlog is absolutely reasonable to have. Basically keeping track of all the things that you want the product eventually to do is a perfectly fine thing to do. Sprints, well, kind of useful. So here's a few things that I already mentioned this

that I think are really terrible about sprints. One, we're only planning in the current sprint. We're not looking any further. Two, we are not really worrying about anything that is further on down the road.

Three, every sprint immediately follows the next sprint. So the way I do it with my development team is number one, we have our product backlog. We have the immediate next sprint, and we use a typically a two week period,

sometimes a one month period for that. And so we know when our current sprint is, when our next sprint is gonna be, when our next sprint is going to be. What we do now is we put down all the items, all the user stories, the product backlog items that we want to do on our current sprint

and then on future sprints. And everyone on the team understands that only the current sprint is binding. Only the sprint task for the current sprint is binding and everything else is completely tentative and is subject to change. So what does that give you? That gives you a bit of a better overview of where we're going.

And we're losing this completely short-term focus and we can look out a little further. And also, and I think this is just a reality and a fact of life, it is perfectly fine in a project to have a hiatus. It's perfectly okay to have a sprint that is followed by a break and then a couple of weeks later you pick up the next sprint.

Remember, this is not Scrum because in Scrum you cannot do this. In Scrum, explicitly in every project you have sprint after sprint after sprint after sprint. So I think the concept of sprints is kind of reasonable. It's something that you can use albeit in a very modified fashion. The next thing, story points, right?

So in one admirable thing that Scrum tends to do or tends to want to do is rather than assigning a measure of this is gonna take such and such effort or worse still, this is gonna take so and so many person days, right? Remember, read up on Brooks,

Mythical Man Month. In 1975 he wrote, the man month is a dangerous and deceptive myth for men and months are not interchangeable, right? That was the exact quote in 1975. So what Scrum tries to do is it tries to assign an abstract measure of complexity.

Some teams tend to use the term bananas for that, right? So a user story is so and so many bananas or whatever you come up with. Funnily enough, Scrum doesn't really say anything about perhaps renaming your story points.

Maybe that's legit actually. And so the idea is that you have sort of this abstract measure of complexity and then you figure out via your burn down like into what time that translates, right? So you've got so and so many bananas and you're burning so and so many bananas per sprint, right?

And so then you get this abstract measure of complexity. Now again, this in my humble opinion is something that self-explanatory only works if your team is stable. Because only if your team's stable will it eventually converge on a reasonably accurate measure of complexity across teams, right?

And I really think this is far inferior to a different approach, which is and believe me, this is a complete Scrum no-no. Is to actually take your user story and break it down into tasks

and my degree of granularity that I think makes the most sense to me is the most reasonable to me is break it down into a granularity such that the tasks in your user story could at least in theory be done by a single person.

So basically you have tasks in there that do not require splitting up anymore. And then what you can do is you can have people basically estimate the complexity of those tasks separately and then you can add them up. Again, like I said, an agile practitioner will say,

no, no, no, no, this is a terrible idea because what the team should do is it should take an arbitrarily complex user story and should somehow come up with a measure of complexity for the whole thing by consensus. I think that's a really, really terrible idea and I think that breaking it down into individual manageable tasks and then estimating those separately

and adding them up is something that simply works way better for human nature. So my personal verdict on story points and by the way, you know, by all means feel free to disagree with me on this one is story points are useful to an extent, not a whole lot, but a bit.

There's one thing that's related to story points that I think is patently ludicrous and that's the idea of planning poker, right? So the idea of planning poker is that when the team comes together and it's expected to assess the complexity of a user story by consensus,

you have this concept of anchoring where whoever says any kind of value first that's what everyone else is gonna be calibrated against, right? So let's say, for example, we have a certain task

which someone estimates to be 20 bananas but the first person talking says five and they say, well, maybe I was a little high on that. If I make it double the estimate of the other person we should kind of sort of be okay. And then they say 10

and in reality you find out it's more like 22 and you would have been right in the first place if it were not for this anchoring thing and so the idea is that you get this deck of cards and you put down, everyone selects their estimate, puts it face down and then you turn it up all at the same time. I think if you're thinking

that that makes any difference, you're just completely lying to yourself because eventually a discussion is going to ensue and then you have the exact same anchoring problem again which is what happens if you've got three people in this area of like so and so many story points and you've got one person who is like well below.

Is that just the person who is more competent, who knows and understands a shortcut and correctly estimates that it's actually not as complex or is it a person who is just overly optimistic, right? I don't think that planning poker really adds anything

to the whole thing. So for me that's a clear no. So like I said there are certain things that in my humble opinion you can take out of the postulates of Scrum that you can and perhaps should do but it's definitely not Scrum at all by its own definition

and Scrum by its own definition really needs to go out the window. Now this being a technology conference of course, what would I do if I wouldn't also talk about tools? So what we did in our own development team

was we looked at and you know there's a bunch of agile or agile-ish project management tools out there. We looked at a few of those and we calibrated them against sort of the way of managing our development projects

and to see how well they were suitable for that. We looked among the tools that we looked at were Asana, Trello, there's an agile mode for Jira. We found all of those lacking to be lacking in one way or another and we eventually settled on a tool which some of you may know, some of you may not.

Who in here has heard of Taiga? One? Okay, I'm here for a reason, good. So Taiga is a, defines itself as a project management framework with Scrum in mind, okay?

So it doesn't say it's Scrum, it just says with Scrum in mind and it's a particularly useful tool. It's something that you can get as a service. It comes out of a company from Argentina and it has a handful of tools

that you will find quite reasonable and useful. So for example, this is just a regular project dashboard where you basically get an overview of like the projects that you're currently a part of,

the things that you're working on, whether those are tasks or issues or something else. That's reasonably useful. One thing that I particularly like about Taiga is the fact that number one, it supports GitHub login. That's always helpful.

So you don't need to basically log on there. It also has very, very good GitHub integration. So for example, you can do certain things like there is a, you can update the status of a user story via GitHub commit message in Git. And those things are kind of useful.

But one thing that I think is particularly neat is that you have development teams that are per project and you can bring externals in on individual development teams. So specifically, if you're contracting out some of your software development, this can be very, very helpful where effectively,

or not you're contracting, you're being contracted for software development where you can, for example, bring in your customer as a product owner if you want to use that terminology. Which is what we're doing, for example, here with the Cloudify course. That's for one of our customers, Gigaspaces. And we're bringing some of their team on effectively

as product owners and people on the team. You also get, if you like burndown charts, you do get a burndown chart. You do get a task list and so on. And of course, you also get user stories

that you can then break down into tasks. You can add attachments, you can add comments and so forth. And there's something that I think is particularly cool about Taiga, and that is this thing. This is relatively new to Taiga. They call it Taiga Tribe. And you can effectively define a user story

and you can then contract it out if you want to. You can post it as a gig on Taiga Tribe and then you get connected to a developer who might be suited for doing that. And then you can basically contract a job out on a one-off basis and then hopefully, actually establish a relationship with that person.

So if you're a hiring manager, that may be a good way to find talent as well. And best of all, and I wouldn't be talking about Taiga if it wasn't this, it's all open source. So it's not one of those things that you can only run as a service and whatnot. You can self-host this thing. It's under the Ferro GPL3.

All the code is up on GitHub. You can go to github.com slash taigaio. And it's everything. It's the front end, the back end, the APIs, everything's up on GitHub and is under the AGPL license. And they're also eating their own dog food. So they have their own user stories for Taiga in Taiga as public projects.

So you can effectively follow their development transparency. If you do go, by the way, with the hosted version, it's currently, I don't think they have any intention to change that, free for all public projects. So if you do the same thing

that they're doing with their project, which is make everything public for everyone to see, that's for free. And only if you have private projects that people who are not on the team cannot see, those are what you pay for. Of course, unless you self-host, in which case you can roll this out on your own server. And it's actually pretty cool stuff. And it's something that you might want to look into

if this is something that interests you. Just in case you're curious, what have we used this for? What have we built with this? And you will see that effectively, we're using this for something that is pretty much straight up software development, but we're also using it for something that is more on the DevOps side of things.

We run a learning management system called academy.histexo.com. We are originally a professional services company that offered and did a lot of face-to-face in-person training on things like Ceph and OpenStack

and distributed technology and so forth. And what we wanted to achieve is we wanted to do all of this in what we call Spot, self-paced online training. So basically the idea that you can log onto this thing and you get your own Ceph cluster to play with and you run through a series of hands-on labs and exercises and so forth,

it basically takes you from zero, effectively having blank servers, to having, say for example, a fully working OpenStack cluster or a fully working Ceph cluster and so on. If you're curious, you can certainly visit us at academy.histexo.com to see that. So we manage that. We manage effectively the iterative development

of our own learning management system platform, which by the way is based on Open edX, with Taiga and with this development method or development management method. We also do the same thing for a full integration of the Open edX learning management system stack and OpenStack.

So we worked on making Open edX work on any OpenStack cloud. So if you're in any way interested in learning management systems and running those on private or public clouds, that's something that you might be interested in as well. And this also includes interacting with OpenStack through these on-demand lab environments,

where effectively we can point our system at any OpenStack, private or public cloud, to fire up these arbitrarily complex distributed systems for labs as learners need them. And finally, what we had to do in order to do that is make some contributions to Open edX itself.

Open edX has a plugin system that are called Open edX X-Blocks. We wrote a couple of those and those are up on GitHub, they're open source, they're public and also the Taiga project boards for those are public as well and we use that just the same.

It's a development approach that we have been using for just under a year and a half now. It's something that we're quite happy with. Maybe it's something that you want to consider. Before I take questions, I'll be happy to share these slides. All my slide decks are normally

under a Creative Commons attribution share-like license. So if you want to use these, modify them, whatever, you're certainly free to do so. And the slides are at github.io slash fghos slash frostcon2016. Those are the ones, those are actually the sources for the slides.

If you want to go to the slides directly, they're here. So if you want to grab these, and those should work fine on your phone and so forth as well. Okay, with that, I thank you for now and then I'll be happy to take questions.

What's your reasoning for saying that if you keep a prioritized backlog and only plan for one sprint in detail, you cannot keep a big picture in mind? So this is not so much a challenge

for the development team, right? So if you have a smart development team, and by definition, normally you do, right? They will have a fairly good understanding of, okay, this is what the backlog looks like, this is the priority list and so forth. But how do you communicate that

to your customers and your users? If you don't care about that at all, which in my humble opinion you can only do if you have zero of them, then you don't mind that either. But I think it's very important to have at least a rough idea of this is going to land, this is going to complete or will be finished in about such and such time frame.

But again, that's just my opinion and by all means, please feel free to disagree. Yes, sir? Yeah, but you have the product honor for that. If you really do scrum, your team isn't supposed to talk to your customers. That's the product owner's task. Not that I find that good. Yeah, no, I mean, yeah, fine.

So of course, yes, your team isn't going to talk, but where does the product owner get their information from? The only thing that they do is basically a backlog and they're not allowed to put anything on a future sprint either. Yeah, but they can put stuff in the backlog. They're allowed to do that within Scrum. Like I said, the only thing that you can actually tell people

is you can effectively make relative statements well, you can make the absolute statement of we are going to do that or we're not going to do that. You know, you could of course say, okay, no, this is completely out of scope. Don't hold your breath. This is never going to happen. And you can say, okay, so we're going to do this, but not until this other thing is done.

So basically you can tell someone, well, come back after X is done. So we can talk about why, but that's about it. Well, there are releases. I have no idea if that's Scrum Plus already or if that's in the original Scrum, but yeah, it's true. Either way. Okay. We have, I saw a hand over here. No, over there.

Okay. You said you don't care about the planning poker that much at all, but said story points can be important in a way, at least maybe for burn down, but you cannot, at least for me,

I would say you cannot have story points without the planning poker. I think you can have story points by actually having at least a tentative breakdown into tasks. If you can't break a user story into tasks to the point that you can define your task

as being manageable by one person, then most probably what you're thinking about is too complex for a user story anyway. You basically have to break it down some, right? And if you are able to effectively say, all right, so here are these individual tasks

and you can now effectively estimate the complexity of these individual tasks and then add them up. But who estimates? What is that? But who estimates the task in this case? The team. Ideally, if you can break it down to like a single person and you perhaps actually have a person in mind

who might be the qualified expert to do this, by the way, again, this is something that in Scrum is a big no-no because in Scrum everyone's a developer, right? By the way, it's explicitly mentioned in the Scrum guide is that within the team there is only one role that is acceptable and that role is developer

and it explicitly says, semi-colon, there are no exception to this rule, period. So if you work on a team that claims to use Scrum and your business card says anything other than developer, no Scrum, just so you know. And so like I said, you know, what Scrum does

is that pretty much everyone's equals and no one's a specialist. And of course, well, if that's what it is, then you can't reasonably get to the point of, okay, let's break this down, let's talk to this person, he or she is the expert for exactly that thing and he or she is going to be able to tell us, okay, this is about the estimate that we can do.

And of course, that person is probably not going to be quite as specialized in something else that their colleague is qualified to do. So like I said, this whole idea of, you know, let's somehow draw an estimate for a user story, a complexity estimate for a user story

out of thin air. For me, it just completely doesn't make sense, but perhaps that's just how my brain's wired. I've never seen a team which could say what complexity of the story is. So yeah,

so that's, the comment was exactly what I mentioned. It's fundamentally impossible almost for a team to just basically dish out a complexity estimate along a Fibonacci series, of course, right? Because we're not doing anything else there. Yes, sir.

Well, a lot of people suggest Scrum is a good method for startups, but from what you've just told us, it sounds like a very terrible idea because in startups, you nearly never have a stable team. So what would be your point on this?

I agree. Next question. So you agree that's a terrible idea? I really think it is a terrible idea. Yes, I think that the idea of expecting out of a team to somehow magically organize itself

while it is constantly changing is ludicrous. It's an entirely unrealistic expectation. So I was just curious because it's suggested so often on the internet, so Scrum is the most suggested thing for startups.

If the internet would have been around at about maybe 200 AD, it would be full of statements saying that the sun revolves around the earth. So the appeal to majority never really works actually, right? We had the gentleman

in the bright green shirt up here. I've heard once that you should look at Scrum as a framework of tools. You should just pick the tools you like

and use them how you like and fill it in as you like and not let Scrum master your process but use Scrum as a tool in your process. You are perfectly free to do that within the very limited freedom

that Scrum allows you, right? So for example, you can organize your daily Scrum in any way that you want. You could, for example, put out the rule that everyone has to stand on their chairs or something or that everyone has to come in red t-shirts but it has to be daily and it has to be 15 minutes. So the frame, yes, it is a framework

but it's a relatively rigid one, right? It's, I mean, I guess you could call a full body cast a framework but it doesn't allow you a lot of flexibility and a lot of movement. Yeah, because I guess the way we use Scrum as a company, I guess you wouldn't call it Scrum

because it doesn't obey the strict rules. Okay. Just don't be a Scrum bag. Yes, sir. So all this Scrum bashing that's going on here, it's like, okay, you have to stick to the rules

and switch off your brain. Come on. If you, it's a set of guidelines. Use your brain and act accordingly but stick to the rules. Who does it? I've never seen this. Right, fair enough. Then what does that say about a method that explicitly said,

you must stick to these rules otherwise you're not doing it. I'm sorry. That's just not a method. There, I agree. Okay, all right. Thank you very much. That was, well, I'll be happy to take questions later on. Okay, thanks for coming. That was great.

Thank you.