You keep using the word agile
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/48853 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Software developerSlide ruleLink (knot theory)InternetworkingBlogTwitterWordJSONXMLUMLComputer animation
01:09
Software developerNumberGoodness of fitProcess (computing)Kanban <Informatik>Computer animation
02:13
IterationPoint (geometry)PlanningWhiteboardSoftware developerIterationRight angleException handlingBit rateComputer animation
03:18
Software developerComputer clusterBitGame controllerTerm (mathematics)Video gameSpecial unitary groupRevision controlTowerDisk read-and-write headSoftwareString (computer science)PlanningGastropod shellCentralizer and normalizerNetwork topologyResultantMilitary base2 (number)Logistic distributionSource codeComputer animation
06:30
Focus (optics)Task (computing)Software developerSoftwareSoftwareProcess (computing)Theory of relativityTask (computing)NumberContext awarenessArithmetic progressionLattice (order)Multiplication signVelocityKey (cryptography)Complete metric spaceInternetworkingQuicksortFrequencyBlogOnline helpComputer animation
08:31
Software developerProcess (computing)Mathematical analysisDrop (liquid)Moment (mathematics)Point (geometry)Projective planeGoodness of fitResultantStress (mechanics)BitMultiplication signSoftware developerVector potentialContext awarenessTheory of relativityNumberDisk read-and-write headBlogPlanningAuthorizationSign (mathematics)Noise (electronics)Product (business)Arithmetic meanComputer animation
12:23
Product (business)Process (computing)Software developerSoftwareSoftwareProcess (computing)Enterprise architectureFood energyRight angleCausalityComputer animation
14:12
Software developerProcess (computing)Right angleProjective planeDesign by contractResultantPoint (geometry)View (database)Goodness of fitCuboidExecution unitKey (cryptography)Data managementDisk read-and-write headCycle (graph theory)Fitness functionProcess (computing)SoftwareUnit testingSoftware developerComputer animation
17:32
Software developerSoftwareDesign by contractCollaborationismDependent and independent variablesContinuous functionIntegrated development environmentInformationSoftwareBitProcess (computing)MeasurementTelecommunicationWebsitePhysicalismData conversionRight angleObservational studyInteractive televisionTask (computing)Software developerLogicMathematicsRange (statistics)Multiplication signScaling (geometry)Online chatINTEGRALEmailResultantExpected valueDisk read-and-write headDesign by contractProjective planeSound effectVideoconferencingPlanningSlide ruleComputer animationMeeting/Interview
23:36
Integrated development environmentSoftwareInformationSoftware developerRegular graphContinuous functionArchitectureTelecommunicationCollaborationismMultiplication signSoftware developerSoftwareTelecommunicationComputer architectureProjective planeSet (mathematics)Process (computing)MathematicsCollaborationismProduct (business)Arithmetic meanNatural languageLogic gateCapability Maturity ModelPrincipal idealPoint (geometry)Lie groupEccentricity (mathematics)CodeComputer animation
29:06
Software developerSelf-organizationLatent heatDecision theoryTask (computing)Point (geometry)Office suiteTrailTwitterSoftwareSelf-organizationSoftware developerComplete metric spaceQuicksortData conversionDifferent (Kate Ryan album)Projective planeBitDialectPlanningMultiplication signBlogProduct (business)1 (number)Absolute valueOrder (biology)InternetworkingLattice (order)Type theoryTheory of relativityWeightUltraviolet photoelectron spectroscopyRight angleCausalityTask (computing)Service (economics)Arithmetic meanFamilyDependent and independent variablesVideo gameProcess (computing)Instance (computer science)Direction (geometry)Computer animation
35:30
Task (computing)Point (geometry)Software developerProduct (business)SoftwareMachine visionProgrammschleifeFeedbackSelf-organizationRule of inferenceProduct (business)Self-organizationGoodness of fitData miningOrder (biology)Right angleDecision theorySoftware testingINTEGRALFeedbackProjective planeMachine visionSoftwarePlanningTraffic reportingInformationData managementPublic key certificatePhysical systemMetric systemReading (process)Multiplication signCovering spaceQuicksortMetropolitan area networkGreen's functionLetterpress printingMarginal distributionProcess (computing)Sound effectMeasurementCausalityReal numberBookmark (World Wide Web)Bit rateElectronic mailing listComputer animation
41:40
Rule of inferenceVirtual machineSoftware developerProduct (business)SoftwareTime evolutionVariety (linguistics)Focus (optics)Machine visionProcess (computing)TelecommunicationCollaborationismRule of inferenceSet (mathematics)Structural loadSoftware developerProjective planeProduct (business)Task (computing)SoftwareWhiteboardFeedbackInheritance (object-oriented programming)Data miningSoftware testingMetropolitan area networkData managementArithmetic progressionMultiplication signDisk read-and-write headGoodness of fitMachine visionEvoluteTelecommunicationInformationDifferent (Kate Ryan album)NumberCollaborationismProcess (computing)EmailRight angleMathematicsInstance (computer science)Black boxLattice (order)Moving averageCarry (arithmetic)Point (geometry)Overhead (computing)Parameter (computer programming)Streaming mediaMappingLine (geometry)TwitterSelf-organizationPhysical systemHierarchyType theoryQuicksortDiagramLink (knot theory)SpacetimeBlogGroup actionTrailExistential quantificationBitCASE <Informatik>Expected valueParallel port1 (number)Extension (kinesiology)Focus (optics)Data conversionSoftware frameworkBasis <Mathematik>Touch typingException handlingComputer configurationMoment (mathematics)Program slicingGraph coloringArithmetic meanGodHill differential equationVirtualizationMusical ensembleCheat <Computerspiel>Open setForm (programming)Latent heatPhysicalismBuildingPurchasingOffice suiteOnline helpNetwork topologyDiscrete element methodCuboidNatural languageScaling (geometry)Computer animation
Transcript: English(auto-generated)
00:07
Looks like we're ready to kick off. Just to let you all know, the slides are available online, so if you want them afterwards, you'll be freely able to get them. Twitter is the best way to get hold of me, so I tweet out the links to the slides, et cetera.
00:21
So just look me up on Twitter and you'll find the slide link. Before I get going properly, can anybody tell me which film crew I've butchered for the title of this talk? Princess Bride. Princess Bride, exactly. Exactly right. So, welcome to an extended rant from my good self,
00:47
which was driven by many blog posts that I saw on the internet throughout the last year and a half. I finally ended up doing something about it.
01:02
So you keep using the word agile. See, I don't think it means what you think it means. How many people here are doing agile? Show of hands. Okay, so a good number of you.
01:22
Other people who are doing agile, how many are doing scrum? Probably the majority. How about Kanban? Some Kanban guys. XP? So, any DSDM?
01:45
Crystal? Anything that I haven't mentioned? No. Okay, so the majority is scrum. I will caveat my rant here with fully certified qualified scrum professional.
02:01
Been there, done that, got the t-shirt, smoked the cigar, everything else. So it's not that I don't like scrum. I'm not scrum bashing. This is generally about anything agile. When you hear agile, what you tend to get are people going,
02:25
we work in two-week iterations. We've got user stories, et cetera. And somebody says to them, why do you work in two-week iterations? And they go, well, because agile, right?
02:47
So user stories are how we get the work we need to do. Why do you do it that way? Well, because agile, right?
03:01
And, you know, your collection of these work items, our backlog, why is it called that? Well, because agile. And that tends to be the answer for everything.
03:20
And that's the problem, because it's not. It's far from agile. Before I go further, how many people have heard the term cargo cult? A few.
03:41
For those, I'm sorry, I'm going to go into a bit more depth about where it came from, explain to everybody else. Second World War, the Americans needed forward bases in the Pacific. They rocked up to various small tropical islands on the ships, loaded machinery, bulldozed jungle, laid down runways,
04:04
set up control towers. Next thing, they've got the planes coming in, so they've got the logistics working. And they have this whole logistics network. Now all the natives on these islands, they've never seen anybody before. And then suddenly they've got all these people there,
04:21
and these great metal birds coming down from the sky, giving them goodies, because the Americans, being generous as they were, would give out chocolate and other stuff to the natives. Life was good for the natives. They had no idea there was a wider conflict going on. All they knew is these guys had turned up, suddenly they were getting good stuff.
04:42
Life was good. So, war ends, Americans pack up, they rip up the runways, they take down the control towers, they get on the boats and they leave. Life isn't so good for the natives anymore. But they don't understand how to get that good life back.
05:03
So, they had a good idea. What we'll do is we'll do what they did. We will make runways, so they chop down trees, lay down leaves, etc., in their jungles, to look like a runway. Still nothing, okay? Then we'll build a tower, we'll have a tower,
05:22
and that will bring them. Still nothing. Chief goes, I know, what I need is the thing that the people had. So, they've got coconut shells, a bit of string, whatever, put together, put them on their heads, climbed up the towers to cool down the great metal birds.
05:41
Still nothing. Many years later, researchers went back to the islands to see what impact had happened due to the Americans going there and building up these forward bases. And they found all this infrastructure. They found planes made of bamboo, runways, control towers.
06:02
And they termed this cargo cult. It was the concept that the natives only saw what had happened and didn't understand why, or what was behind it, or what actually needed to take place
06:22
to make the results that they wanted to happen. So, cargo cult. A lot of people doing Agile will focus on completing of tasks and stories.
06:42
That's what's important. The business wants to see stuff being done. The thing is, the software that they're producing through this can't be deployed. Yes, the stories are completed, for a given amount of completed. The tasks are done, for a given amount of done.
07:03
But the software can't be used. The business comes up with KPIs. Yeah, we want a velocity KPI. Velocity must get faster all the time. Must go upwards, shows progress, shows us going forwards. Number of tasks completed, stories done, shortened time period it takes.
07:26
All these sort of KPIs, which, again, don't help. The team doesn't self-organize at all. The team is basically just being told what to do.
07:41
They aren't actually working out what they should be doing. And meetings, the meetings. Now, when I look at the Internet and I see these blog posts and you have posts such as, Scrum should die in a fire. It's a particularly poignant one.
08:03
Meetings are quite often the key problem that people identify with Agile. We have these meetings and they go on for hours. They give us no value. They're a waste of time. Et cetera, et cetera.
08:23
I will come back to meetings in a short while. I will go into this further. My rant is only just beginning our meetings. But first, let's go back in time a moment. Let's go back to where this all began. See if we can get some context in relation to Agile.
08:47
Now, these numbers are made up. They're pulled from my head. So, by all means, pull some numbers from your own head as well. It's fine. It's for demonstration purposes only. So, 95 to 2,000.
09:02
Back then, for anybody who was working, we were in SSADM land. We were talking big upfront design. Everything could and should be designed and documented and laid down. The plan would be made and we would follow it to success.
09:21
And all we heard about was failure after failure after failure. Martin Fowler's actually got a blog post on this where he talks about the thud. It's just noise. Which was the thud of the brief.
09:40
The design document hitting the desk. You knew it had arrived. The architects from on high had created it along with the business analysis. And there was your latest drop of work, the thud. And a few people at this point thought there's a better way of doing this. The projects are failing. The business thinks developers are useless.
10:01
We're not getting anywhere. So, we're going to come up with a better way of doing this. We're actually going to find a better way of working. And these are the people who came up with Crystal and XP and Scrum. Which, strangely enough, was actually first talked about in 1985.
10:24
So that's when Snowbirds happens in 2001. The Agile Manifesto comes about. People start hearing about these new lightweight processes. Because that's what they were called, lightweight. There's many in Agile Manifesto signee who's saying,
10:42
we wish you never called it Agile. That boat sailed. This was the fight back. This was, this is what we're going to do. And back then it was all good. People were happy. You didn't see things going, oh Scrum should die in a fire, etc. You have people going, I'm not sure if this is going to work.
11:02
But there was no direct attacks on the methodologies themselves. Then we get to 2008 to 2012. People start seeing results. Companies want to start picking Agile up. It starts becoming the flavor of the month.
11:22
This is the thing, this is brilliant. We're going to get results from this. And a lot of companies did. They understood. Perhaps some of them actually employed the original signatories to help them. And they started getting traction and moving forwards. Stuff was being delivered. Brilliant. Now you get some people start criticizing some of the methodologies.
11:42
It's not a lot. It's a little bit out there, just quiet. Perhaps that could be better. But generally people were happy. Then we've moved on. Things have gone wrong. Time and time and time again you hear about Agile's dead. Agile shouldn't live.
12:01
It should die in a fire. This is useless. What a waste of time. It doesn't deliver anything. This is where we've got to. How have we gone from the point back in 2001, 2008, where everything was so vibrant and we could see the potential to now everything should be dead.
12:25
We've got here because business believes the problem, delivering a product, is the developers. We're the problem. We're the people who've caused this issue. We can't deliver anything. We ask you for something, it never gets delivered.
12:44
They're also told it would be cheaper. Yeah, it will cost us nothing to produce this. We can produce it. It's great. It will be really cheap to produce. It will save you a lot of money. It will be delivered more frequently. You won't have to wait as long as you used to have to wait
13:02
to be able to get your software. The business is liking this. It's cheaper. We'll get it more frequently. This sounds like what we want. We want this to happen to us. And then we're also being told, as a business, you can change your requirements right up to the last minute.
13:21
Agile allows you to do that. It means we can change our minds about what we're going to do as a business the day before it gets released. That's all fine. We can do that. People have bought into it. The business is, this is fantastic. How do we get a piece of this? Well, there's named processes out there.
13:45
So all you have to do is go and get one of these named methods which has all the process and practices and you bring that into your company and it's going to deliver all this cheaper, faster. It's all going to be brilliant. And even better for an enterprise,
14:02
you can get certified. You're going to get certified and that implies you know all about it. You must know. Stand back. I'm certified. Yes. This is the kind of idea
14:21
people can rush in like a superhero because they're certified and put all your problems right. It's easy. So where does this go wrong? Where do we start? One of the key problems is mistaking the practice for a result.
14:42
They think that if they do a practice, they will get a result because they've been told that. They'd be conditioned. If you do unit tests, you will get defect-free software. No. It'll help, but it's not going to completely cure it,
15:01
but they've mistaken it. If I have a backlog of items, I can make sure I can get all this done. Well, yes, but it's not necessarily going to give you the result that you anticipate. Also, why do we need to have all these new roles? Taking Scrum for an example here.
15:20
Scrum master. Sounds good. What do they do? Or they look after the team. Isn't that what the project manager does? I know. We'll just rename them. How many people here who work with Scrum have had project managers, Scrum has been introduced, and they're now Scrum masters?
15:41
Yeah, a few people. This happens, again, because they don't understand practice for result. Even worse is they misunderstand the point behind the practice. So from the business point of view of the backlog, you're supposed to be creating stuff
16:00
that isn't as a business for value. Keep the business going. But they misunderstand, so they just throw stuff in that backlog. Yeah, put more stuff in, more work to get through. But of course, the devs are going faster, and it's cheaper, and we can change our minds at the last minute,
16:21
so this is all good. One of the biggest problems that I've seen in the various companies that I've been in with Agile is Agile is development. It's that little box over there, just over there. Yeah, stay over there. We don't want anything to do with you. You do what you want, you know,
16:41
pretty little heads. You think that's good. You go and do that. That's great. And things go wrong, and I'm going to come on to this in a second. You're going to see this is probably one of the key problems with Agile and how people perceive Agile today.
17:04
And even though so far, I'm a firm believer in Agile, just saying maybe it isn't right for you. Now, there's a lot of people I know who are very, very senior in Agile who would disagree. There's Agile everywhere. Oh, that's fine.
17:20
But just maybe for your business, Agile doesn't fit. If it doesn't fit, trying to push it in isn't going to help. Maybe it's a government contract. I don't know. And this is what happens. The business are stressed and angry. The users are stressed and angry.
17:43
And the poor devs are stuck in the middle going, all we want to do is write a bit of software. We're trying to help. So, I feel a bit cleansed now. The rant is coming out.
18:02
What is Agile? This is the thing. What are we actually talking about here? How many people here have seen the Agile Manifesto? Understand it. I saw the people. I'm not going to dwell on this. I'm sure everybody can read. The one thing I do want to point out
18:22
is if you look at the various items that we have here, all the items that you have over on the left-hand side as you look at it are physical things, concrete things, processes, tools.
18:41
Documentation. Contracts. Plan. They're all actual things for the most part. Come back over to the right side. And they're more insubstantial. There's only one thing there which is concrete
19:00
and that is working software. The only thing that's concrete, everything else there is insubstantial. It's ideas. It's things that you do. Interactions. And as they quite rightly say, it's not that they don't value all the other bits and pieces. It's just that the stuff on the right
19:20
is considered more important. So most people know about the manifesto. How many people know the Agile principles? It's going to be very boring for you, I'm afraid. One person. So everybody heard of the manifesto? Yeah, we know that.
19:41
The principles, interactions and all that, yeah. The principles are the actual meat and bones of it that are behind it. Now, forgive me, these next slides are going to be fairly text heavy, but we're going to run through the principles quickly so that you can get a better idea of what Agile is actually trying to be
20:04
before we move on. So we start off. The very first principle is that the highest priority is delivering valuable software. So we're talking about working software,
20:21
it is delivered, but it is valuable. And we'll come back to value in a little bit, but it's valuable. And we do say we're happy to welcome changing requirements. We say that we'll even do it late in development. Late in development doesn't mean the day before release.
20:45
And it ties in with some of the rest of these, so that we're going, the principles tend to build upon each other because we're now saying we're going to look to deliver working software frequently, working software again.
21:01
Now here we are, three principles in, software has been mentioned twice. Working software. And we're going to actually have a preference to the shorter time scale. Now this is before continuous integration, continuous delivery, continuous deployment. None of this existed when these principles came about.
21:24
So what we're talking about here is we want to get this stuff out as fast as we can. Business people and devs to work together. This is a direct result of the big thud delivery of the design documents.
21:43
Because back in the day, what used to happen is that, boom, got delivered, business people disappear. There was not in any interaction. So this principle was there to try and get into people's heads that you do need to talk to each other, and ideally daily.
22:02
Because if there's any issues, problems, changes you want to make, as soon as you can raise them, stuff can be done. Now we're moving on a bit to how the team works. So we want to use people who we trust to get the job done.
22:23
That's us devs. Hi. But you've got to trust us to do it. The business had lost trust because so many projects have failed. So the principle's saying, look, you've got to trust us. We're motivated. We're going to get the stuff done. We're going to work with you, but trust and support us so that
22:42
we can actually get the work done for you. Also, face-to-face conversation. I mean, there's been many studies done where you have a whole range of how effective communication is. We're face-to-face at one end and a letter at the other end.
23:01
Face-to-face has been shown the most efficient way to communicate. So let's use that. Let's actually talk to each other. Now, video chat has helped a lot. Perhaps we don't actually have to come together anymore, but we can still talk. And it's better than using an IM, which is better than email,
23:21
which is better than a letter, etc., etc. We're back again to working software. Surprise, surprise. It's the primary measure. We don't care how many tasks get done. We don't care how many stories, whatever. It's working software. That is how we define
23:40
how well we are doing. Is the software delivered? Is it working? Has it got new features in? Yes, brilliant. No, we're not making progress. Because we want to avoid death marches, I mean, has anybody not worked on a death march here?
24:07
No, everybody's worked on a death march, working stupid hours to try and get something done to an arbitrary date. So again, the principles here are trying to speak to this. You know, let's promote sustainable development.
24:21
If we can go at the same pace all the time, deliver software frequently, which is working and valuable, then these arbitrary dates, are they really necessary? We can just keep giving you more and more functionality. Does that work for you?
24:40
We don't need to be working 12-hour dates to do it to this particular date. Now we move back to more team-oriented stuff. So we're saying, or development-related in a way, we're going to have continuous attention to detail. We're going to try and do the best that we can all the time
25:01
at the time we're doing it. So we're not expecting there to be a set of upfront design that's going to cover everything. That's not going to happen. But what we're going to do is make sure that what we do when we do it is the best that we can do.
25:21
But we're not going to gold plate it. This is where YAGNI, you ain't going to need it, came from. You know, let's actually just make sure that we do what we need to satisfy what you need delivered now. And as I said, the best architectures
25:41
emerge from the self-organizing teams. The teams know what they're doing. They're at the coalface, they're cutting code, they can see the problems. You know, you tell them what is needed, they can look at it and they can work out, can they do it, can they not do it? Remember, this is expecting to be using motivated individuals who are trying
26:02
the best job that they possibly can. And the final thing, which is effectively the scrum retrospectives, is saying the team should meet at regular intervals to try and reflect on how they can improve. This doesn't mean necessarily just process,
26:20
maybe it means tools, maybe it means language, technology, whatever. But the idea was already baked into Agile generally that you want to actually have a look at what you're doing just to make sure that we're on the right path and there isn't something better that we could do to actually make our lives easier,
26:43
help us with the business. So, given that, why would you want to use Agile? We've seen the manifesto, we now know the principles, we know the meat on the bones.
27:03
Communication. Going through all the various principles there, we have communication, people talking to each other. Because by communicating constantly with people, people know what's happening, know what's going on, are able to ask for changes, deal with problems, et cetera, et cetera.
27:26
It's going to help because you also have transparency. You're not trying to hide a problem, you're not saying this project's gone wrong or we've run into something and we need to solve it. You're not hiding that, you're talking to people.
27:43
You're making it all open. We're not trying to deceive anybody. And this transparency drives trust. The business are trusting the developers to actually go, okay, you've run a problem, great,
28:01
you've told us, we'll work with you, we'll work it out. Maybe there's something that business can do which will alleviate the problem that you've run into. Maybe there's a change that we want for the project which negates the issue you've run into. Brilliant. So trust. So we're talking, we're transparent,
28:21
we're trusting people, we're collaborating. We are one team. It's not the developers and the business. It is just one team getting the job done. Because we're all, at the end of the day, got the same goal here.
28:41
What we're trying to do is make the business that we work for successful. And we do that by delivering value to the business. The business needs to be selling its product or doing whatever it does to keep itself going.
29:02
And we help that by delivering them value. So the question that usually comes up at this point is, well, what is value? There's been long discussions about what value is.
29:22
Now, I've written blog posts about this in the past. Other people have written blog posts about this. Value is going to be specific to you. It could be specific to your team, your business, the organization. And you have to determine what that value is.
29:42
Maybe you're an ad network, so it clicks on ads. Maybe you're trying to compare the market type thing and you're trying to get various insurance companies, people to buy through you.
30:00
Maybe you've actually got a product, something like Basecamp, for instance, for people buying and taking the product up. You have to work out what the value is. I'm not saying that it's devs. You, in relation to the wider business, need to work out what the value is. And you'd be surprised how many companies don't actually know this.
30:22
A lot of the companies don't know, well, we're selling a product. Right, so that's the value, is it? Is that sales? Well, no. Is it return on investment? Well, maybe. Is it net profit? Well, I think so.
30:40
They honestly don't know what the value is. So you need to find out what that is. Because once you work out what it is, then you can measure it. Right, now we can measure it, great. Because once we can measure it, we can actually use that to influence what we're doing.
31:00
We've put a new feature out. Did the value increase, whatever our value is? Yes, brilliant, we're on track. No, why not? Was it not a good idea? Was it an experiment? Do we need to reduce something? Do we need to change direction? All this sort of conversations take place.
31:20
It also helps immensely with working out what work is to be done. So if we look at Scrum for an example, or XP with a backlog of items, and you're trying to work out what items should or shouldn't be done, which one is of the most value? I worked for a company a few years ago now,
31:42
a small dev team, and there were about 10 different product owners or products, projects that they looked after, and they were always demanding time. And it was a small dev team, so they could only service people, do a bit here, a bit there, and nobody was happy. So, got in there, we started looking at value.
32:02
What did value mean? We also got a regional director involved. And what used to then happen is that the people who were responsible for the projects used to have to come with a plan to a meeting and submit they wanted time from the development team. We want to do this, okay?
32:22
So, first question the regional director asks is, what's the value? Very first question, what's the value? And that was then used to be able to determine what order work was done in. When should the development team work on this? When should they work on that?
32:43
And then once that had been decided, it was right. Of the work that's to be done, which is of the highest value in that work. So, it's always making sure that the resources that we had were always working on effectively the highest priority item to give the most bang for buck.
33:07
I've had my rant about Agile. I've explained what Agile kind of principles are,
33:21
talked about value, and still we see people on the internet talking about Agile should die. And the things that they get wrong, because Agile isn't completing tasks. That is not what it is about. I've said before and I'll say it again,
33:42
it's about working software. Tasks, no tasks, whatever. Get working software. It isn't user stories and planning poker. They are useful tools, they are practices, but they are not what Agile is. They're just something you can use.
34:03
Now, I said I would come back to meetings It is not meetings. Agile is not meetings. Hadi Harari and I got into a discussion on Twitter a while back about stand-ups, where he said he saw no value in stand-ups and I said I did have thought there was value
34:22
and we were talking at complete cross purposes, because the stand-ups he was talking about are the ones with the three questions. What did I do yesterday? What am I going to do today? What's blocking me? So how many people have stand-ups in their daily life?
34:41
Most people. So how does this sound? Is this kind of something you're used to hearing? Yesterday I did ABC. Today I'm going to do a bit more ABC
35:02
and then I'm going to do DEF. I'm blocked from doing DEF because Tom's doing XYZ. Sound familiar? That sort of thing. And that's what people rail against. Yeah, that's crap. That's absolute crap.
35:21
Now, let's take the same person, go back 10 minutes to the kitchen. The team's gathered having coffee. Tom, what are you doing? I'm finishing off ABC today and I got DEF to go. Oh, when you got DEF, give me a yell. I was originally in that speccing.
35:42
I got some stuff which you might not know about. Oh, that's cool. I'll come and get you. Oh, you can't start DEF because I'm doing XYZ. Oh, I didn't know that. Cheers, dude. Tell me when you're finished. That's a stand-up. It's the same information but the idea was
36:02
it's the team working out what they're doing. Their plan for the next working day, effectively. It's sharing information. It is not reporting. It's never intended as a report. I mean, even worse, you hear about these
36:23
organizations where the manager sits in front of the devs. The devs line up around them and they all sit and talk to the manager and tell the manager what they're doing. It was never the idea. The idea was always a little sync-up
36:41
within the team about what they're doing, where they're going, and if there were some problems, the original idea of the Scrum Master was take notes, I'll go and sort that to let you get on. How would they go so wrong? Certification. No, sorry. I shouldn't say that.
37:01
The same as retrospectives. They've become a by rote. Tell me something that was good. Tell me something that was bad. Tell me something you want to change. No. There's some really good courses and books out there about agile retrospectives and things you can do. Go look them up. Go find them. You can do so much more.
37:25
Oh, this is a particular favorite of mine. The product owner to-do list, often known as the backlog to everybody else. But it's not. All they've done is they've taken all the things they need to do, it's like upfront design,
37:40
and listed them all out in an order they think is right, and they just tell you to take them off that list. No discussion. No, is this valuable? Just take these off. Just use them one after another. It doesn't work like that.
38:01
Following an agile methodology. Yeah, I said it. Agile isn't necessarily following a methodology. Methodologies have arisen partly to help, but the problem is people got stuck. How many people who are involved in Scrum
38:20
have heard of the phrase shuhari? One person again. There's supposed to be this idea that you would follow the rules, then you would know how you could change the rules, and then you didn't need the rules. It relates back to Japanese martial arts. Thing is, most people who do Scrums,
38:42
or the Scrum zealots, as I like to call them, say as soon as you don't follow the rules, you're not doing Scrum, and you should burn in hell, because the only way you succeed is by following the rules. Right. Okay. I'll leave that one there, and we'll come back when you've had some coffee and woken up a bit.
39:05
Agile. What is it? Working software. Oh, look at that. Surprise, surprise. My top thing for what Agile actually is is working software. Software that's working, delivered, it's in prod, it's being used.
39:21
Our primary measure for whether we're succeeding or not, working software. It's being focused on the vision and goals. This is more than just having a backlog of items. The team involved in doing this understand what the vision is for whatever you're doing, the goals you're trying to achieve, and how you're going to go there,
39:40
because this influences how you make decisions on a daily basis about if you need to do something in the product. Instead of having to wait for somebody on high to make a decision, you know the vision, you know the goals. You can make decisions. You're empowered. And you can get on. Things go quicker. It's feedback loops.
40:02
When we're developing, our feedback loop is usually our tests. Are the tests green? Are they passing? Yep. Great. We're happy. Do the tests cover everything? Of course they don't. But they're giving us an idea that things are working okay. Then we move on to integration tests. Is the system working as a whole? Yes, it is. Great.
40:23
Then we're putting it out to the users, and we have people like the product owner, who's a proper entrepreneurial spirit, asking users, is this what you want? Is this what you need? What would you like to see instead? Feedback loops all the time. Checking everything you're doing is what you want to be doing.
40:42
We're delivering value. We've worked out what our value is. We're delivering working software. We're delivering it frequently. We're making sure that what we're doing is valuable. We should be able to see in our metrics for the value we're measuring, stuff going up. And we also have people from across the entire organization working together.
41:04
The business understanding what Agile is. And the principles actually spread out. They don't stay within the dev team. They move. Now, funnily enough, I read a post a while back which suggested that the true spirit of Agile has moved.
41:22
And it's moved into DevOps. Because it's the same idea here that trying to get everybody working together and to get stuff done. Read The Phoenix Project if you haven't. It's a brilliant book. It's exactly this sort of idea. The principles.
41:43
It's not a set of rules. This isn't the government laying rules down saying you will follow this or a biblical commandment. There are loads of practices.
42:01
Loads of them. Here's some technical ones. You may know some of them. You may not. You may do some of them. Others you might not. Now, I'm not going to suggest that you need to know all of them and you need to actually do all of them. But it's useful, if nothing else, to know they exist and know what they are
42:23
in case it becomes something that could be of use to you. Just understanding them can help. So we look at product practices. We've got less product practices than we have technical practices. But again, these are around trying to work out
42:42
how to do the best thing for your product. If you look at these practices and you're working in a company which tends to shoebox development and agile and everything is about development being wrong,
43:00
value stream mapping. My top tip for you is pick that up and run with it. Work out across the whole business how work flows through the business. Work out where things actually take time, where the bottlenecks are. And then you can talk to the business about what's going on.
43:21
Because you may well find that development is not the problem at all. It may be that it's a lot further up the line with the business analysts or down the line when we're trying to get deployment out. And that may not be ops's problem. Maybe it's something that devs are doing wrong.
43:40
There's no blame being associated here. It's just, what's going on? Find it out. Utilize it. Then we come to project practices. And this has probably seen the biggest explosion and continuing increase in practices from the agile space.
44:01
It's also why you get the likes of Uncle Bob complaining that you have agile conferences now which are just full of project managers. And to a large extent, a lot of them are. But some very clever people are working to try and discover the best way to do the projects or the products
44:21
to help with the value, to help the business, et cetera, et cetera. You know the rest of the story. And again, it's worthwhile knowing these practices exist. I'm sure there's more than this by now. Just know what they are. You don't have to practice all of them.
44:41
You just know what they are. So that when somebody says, oh, have you heard of so-and-so? You can say, yes. We don't do it, but it's this idea. So what's the difference between what people are saying is agile and what I'm saying is agile? Well, again, working software is a priority.
45:00
We're producing software. It's got to work. It has to work. It's got to be deployed and working. If it's not, it's useless. It's of no value to anybody. It's also everybody, not just the devs, but upstream and downstream, everybody focused on the goals for that project or product. It's not about did we get x number of tasks done this week.
45:24
It's not. It's are we achieving what this project slash product is trying to do? It's looking to add value. It's not we're going to throw a feature in because, yeah, we want to throw a feature in. It's is this valuable?
45:40
Let's do what's valuable. And understanding as devs that we're looking to add value. It's not that we're trying to put this in because it would be cool. Everybody collaborates. Business people talk to devs. Devs talk to ops.
46:01
Your product champions are talking to your users. Maybe you've got active forums, user voice, et cetera, gaining the feedback. But you're trying to collaborate. Perhaps you identify super users. Most products have this. There's a few people out there who really get in under the skin of a product and use it. Super users.
46:23
Use them. Grab them. Mine them from information. What do you like? What don't you like? What's a problem? What's not a problem? And at the opposite end, grab some newbies, like hallway testing. Everybody know of hallway testing? The hallway testing, for those who don't know, is you're doing some development.
46:42
You go out, grab somebody from the hall, anybody, stick them in front of the software and go, use it. If they can use it, great. If they can't, do they need help? Is it complex and they need help? Or is it just that it's been done badly and we need to go back to the drawing board and have a rethink?
47:02
So how do we reclaim Agile then? How do we get back to what the ideas, the principles behind Agile want us to do, what I think we should be doing, and try and do in my day-to-day job, and what these other people who are, unfortunately, having to endure.
47:24
There's nothing wrong with actually starting with a methodology. It gives you a framework. It gives you something you can start to follow. You don't have to worry, you know, ooh, am I doing the right thing? It gives you something to build on.
47:40
But, and you have my permission here to quote this, you do not have to follow the rules. They're there to get you started, nothing more. Don't get caught up in we have to do this or we're not doing that. It doesn't matter. Remember, we're trying to deliver working software here. We're trying to improve.
48:02
Don't let the rules or the man stop you. Make sure the wider business is involved. You've got to pull the business in. They've got to be involved. The company I worked for a couple of years ago now, I started there.
48:21
We used to have the manager in every day, micromanaging, because he didn't know what was happening. So, we've got our blooming great board stuck up. We put charts up for how progress went, stuff tracked across the board. By the time I came to leave the company, he would walk past in the morning, he'd stick his head in, have a look, and he'd walk off.
48:41
He could tell what was going on. He didn't need to now come in and micromanage. And that goes back to the communication transparency trust. And also, you involve them so they understand what's going on. It's not a black box.
49:00
Similarly though, as a dev, become involved in the wider business. Understand what the business is, how it works. There's a couple of good books out on this recently. Agile, Rolling Rocks Down Hill, I think it is, is a good one. Which is this kind of idea, they're like parables of developers
49:23
learning about the wider business and how they fit into it. Because we're smart people, we have to be for the jobs we do. And because of that, we often can come up with ideas which perhaps the business people haven't thought about, because they're kind of often thinking in their normal work.
49:43
And we consider things which are different. But once you know what the wider business is as well, you understand the value a lot more. So when somebody says they want something, you can have a discussion with them about it. And evolve.
50:01
Evolve what you do. This is key. Agile was never supposed to be static. The principles, I grant you, are fairly static. Could they do a revamp? Maybe they could. But most of the principles there are just ideas. They're not concrete things that you are supposed to explicitly do.
50:22
They're ideas that you should be trying to follow. And one of those was, if you remember back in the principles, to meet regularly, to work out how to improve. So, you want to evolve. But what does evolution look like? If you're one of these companies and you're doing a methodology already,
50:43
what's it look like to evolve what you do? Well, you look at all those practices. You look at them all and you go, there's all these different things. You know, Scrum has this, Kanban has that, XP has this.
51:00
Lean has that. Ooh. Look at them. Could they be useful? Can we pinch them? Yeah, you can. Pick them. Try them. Do they work? Brilliant. Carry on with them. They don't work. Fine, throw them away. Don't hold on to them. If it's not working for you, throw it away.
51:21
Maybe you'll revisit it. Months, years, and it will work for you at that point. But at the point in time that you're putting this together, maybe it doesn't, so don't hold on to it. There's no need. Make sure everybody's focused on the vision and the goals, not the tasks, not the stories.
51:42
What is the actual underlying thing? There's one particular practice which is recommended. If you have a backlog, a big backlog of items, and there's stuff in there that's been there for more than six months, anything older than six months, throw it away. Get rid of it. If it's important, it will come back again.
52:03
Otherwise, it's just this massive overhead. You can have this huge backlog and look at it and think, oh my God, how are we going to get all this done? Throw it away. If it's important, it will come back again. Focusing on the visions and the goals, the same things, if they're necessary, will come back and will get prioritized.
52:21
I say it yet again. Keep delivering working software. Make sure you deliver working software, even if you can't spread out into the wider business. If the development team can deliver working software, you'll often find that offsets a lot of arguments that the business have with you
52:40
because software is being delivered. Now, if you can deliver it frequently, as the principles are trying to get you to do, and you start becoming repeatable, reliable, the business starts changing their mind about what they want because suddenly the dev team is dropping stuff every week.
53:01
Perhaps every couple of days if you get continuous deployments in place. Suddenly we're looking at other opportunities now because you start talking to them and going, we know we can have something done for you in a week's time. Really? Yes. Oh. Oh, right.
53:20
So you're sure you want us to do this, or would you rather that? It can open up conversations. Working software can save you an awful lot of heartache. Keep collaborating. The more people you talk to, the easier this is. People, as in sales, sales all the time, people buy people.
53:42
So if you're working with people in your organization, go and talk to them. Talk to them. Don't write an email. Get to know them face to face. It doesn't mean you're going to go and go to their child's christening or something, but it means that you've actually got a relationship with that person on a day-to-day basis
54:01
so that when they say something, you're more trusted. Calvin Henney touched on this yesterday. If you've got somebody he knows and he's worked with for a long time, it doesn't matter if that person moves to Australia, if that person says something, he's going to trust it because he's worked with them for a long time.
54:21
He understands the way they think. They understand the way he thinks. There is a lot of trust there. This is the same thing. If people don't know who you are, you don't trust anything you say. By collaborating, getting out, meeting, talking to people, that trust gets built up.
54:42
And then with your transparency, and they see what's going on, things generally start getting better. So what would I like you to take away from my rant and my ramble? Always focus on delivering working software. Always, always, always.
55:02
It's not about tasks and stories going across the board. Whatever you do, make your process transparent. Don't be frightened to say, we've got a problem, or this has cropped up. Because the more transparent you are, the more people are going to trust
55:21
because you're not hiding stuff. As long as you're delivering working software, because I can imagine a situation where you never deliver anything, but you say, with all these problems, it's all going to go downhill very quickly. So you want to make sure you're focusing on getting that software delivered.
55:41
Communicating and collaborating is absolutely key. You need to work with people. Talk to them, collaborate with them, pull them in, have the discussions. Maybe it's not every day. You don't expect everybody to come to your daily meeting of what the team is doing, but it's good if they're unavailable, they can come and listen anyway,
56:01
or if you need to get hold of them about something, then they're there. The more you do it, the more it's likely to happen. Please don't be bound by the rules. Don't let someone like a scrum zealot stop you from doing something which will be beneficial to your team, business, organization.
56:24
Use what's good and throw away what's bad. And remember though, something you throw away today may be valuable in the future. So it doesn't mean if you stop doing it, you discount it entirely. It just means it isn't right for you at this point in time.
56:43
You might want to revisit it. And make sure you're evolving. Change what you're doing so that you can make sure you're delivering value. Any questions?
57:05
Yes, sir.
57:21
Okay, so the question is how does Agile change and can it work across remote distributed teams? So the last two companies I'm in, completely remote, completely Agile. There is a slight change in your communication.
57:41
What's worked for us is everybody lives on Slack, for instance. Everything is done on Slack because you've got to open, you're always typing stuff in, everything is happening. This does mean that generally you want to stick to the a team should be able to be fed by two pizzas.
58:03
So a size of eight, because if you've got more than that, it just becomes a jumble and you need sub-teams and it gets complicated. So if you can keep the team smaller, it's good. Another technique I've heard about is opening Hangouts or Skype, group Skype, etc. That when you come online,
58:20
you start it up, you're there and this is almost like a virtual office. So people can just look at the Hangouts and look, I know that Tom's there. Oh, Tom, can I talk to you a second? It's around that. For tracking of work, a physical board isn't going to work for you. You're going to have to use something which is electronic.
58:42
But again, tie that into your Slack, your main communication channel, so that people understand if things change that something's happened. It is about the communication. It's just getting as many channels as you can and keeping them open. If you can get the team together,
59:02
it doesn't have to be very often, but get them together so they can all talk face to face and you get a bit of social bonding, that helps enormously. Enormously. Because while it's one thing to talk to somebody over Slack for seven hours a day, when you've actually come together
59:20
and had a coffee and a chat, all the nuances of body language, et cetera, come out, and things can change usually for the better. There's not many times where things have gone wrong unless people just vehemently dislike each other. Does that answer your question?
59:42
Yes, sir. Okay, so the question is, can I say anything about agile at scale, scrums are scrums, et cetera?
01:00:00
There's been a lot of discussion about this in various agile forums, et cetera, and blog posts. The most current thinking, as I understand it, is don't, basically. The idea of scaling like that comes from the idea of the old,
01:00:23
if you have nine ladies, you can have a baby in one month. It is a case of altering your expectations of the way these things work to enable work to be done effectively in parallel. A good example of this, I'm sure most of you have heard of this and read about it,
01:00:45
is Spotify and the way that they've organized to allow themselves to have lots of teams doing stuff at the same time without getting in each other's way. There are other examples out there.
01:01:02
There is no silver bullet. That's the thing. It will be different for your company to my company, to how things would scale. And a lot of it, I come back to Kelvin's talk yesterday about systems and trees, is it's not a simple top-down hierarchical type system.
01:01:23
There are interlinks between all the various points and some idea that you can just keep throwing people and teams at stuff and it's all going to magically work. It won't for humans and that sort doesn't happen. It will depend on your company culture.
01:01:41
Is the culture one where it's very open and everybody collaborates or that famous diagram like Microsoft which each department's got a gun at the other. It's really going to depend on your company culture. Therefore, unfortunately, I can't give you any specific advice on the best way to do that.
01:02:03
But I'm always happy to sit down and have a chat and talk about options and things. I know that's not much of an answer, but is that okay? Any other questions? Okay. If you want to grab me, I'm going to be around.
01:02:20
I'm on Twitter. Get a hold of me. As I said, the slides. I'll post a link on Twitter to them so you'll be able to have the slides. Blog's got a load of stuff on as well. By all means, grab it. Thank you very much. If you want to put a red in, by all means put a red in.
01:02:43
But I would love for you to come and tell me why so I can improve. Because if I don't get the feedback, I don't understand what I've done wrong. Thank you.
Recommendations
Series of 26 media