An introduction to Agile project management – covering both KanBan and Scrum. Covering a little around history, Agile vs Waterfall and examples from real projects.
Speaker Review
https://manifesto.co.uk/wordcamp-london-2017-introduction-agile/
Video
Transcription
ELLIOT TAYLOR: Hello everyone thank you for coming to track A for the next talk. Thank you to our sponsors, GoDaddy, and the dress circle, grand circle, patron sponsors. If you wander around I am sure you have seen the sponsors, do have a chat with them they make the WordCamp possible. I would also like to mention another note I have written down, that if you are a Meetup organiser of your local area, then do head over to activity room at 12.30 where all other Meetup organisers will get together and have a little bit of a round table so that’s 1230 in the activity room.
Now I would like to introduce Jim who works at manifesto who runs Manifesto I should say, and is going to be talking about Agile.
JIM BOWES: Thank you very much. Good morning, happy Sunday morning to you hope everyone is feeling fresh, did people party hard last night? A few people. I will do a little bit to try to get people to talk to each other a little bit for which I apologise I will not do any massive participation there will be no shaming I will not try to start to get people into your relationships as part of this talk but I am going to get through quite a bit. So normally when I talk about this topic I spend at least two hours on it and the material I am using today is cut down from a 4 hour workshop. I will attempt to get into about 30 minutes and leave a little bit of time for questions, but essentially my name is Jim I run a digital agency called Manifesto, I would describe us as an Agile agency, we use Agile principles to run the agency as well as to deliver the work we do. This is really just a very introductory session to Agile, where it came from perhaps how it can help you and your business. We describe ourselves as an agency of creatives and technologist that collaborate with exceptional organisations to change things for the better. We work with some of these people, we do a lot of work in the not for profit sector, we work across technologies that including WordPress but not inclusive exclusively WordPress, but for me WordPress has a very special place in my heart when I was working about 7 or 8 years ago now I did freelancing in the evening, to enable me to start my business I used to get home from work and spend hours hours trying to work out with combination of plugins which would allow I me with a very limited combination of development skills would allow me to achieve what I wanted to achieve. Very soon after starting Manifesto I had no involvement whatsoever in the development that’s better for the whole world. So we’re 5 years old now, there’s 45 of us we’re based in London, and I spoke at WordCamp a couple of years ago I love this event because it has such an amazing atmosphere and it’s so well organised. I am not just saying that because I am here as an agency that also does Drupal, I go to their events it just has a really different vibe here that I incredibly supportive I really like that.
I was just at Dave’s talk before this, and I know a couple of people had questions for me are that so really happy to catch up app lunch if people want to follow up.
So, here’s an example of a WordPress site that we delivered last year, in November for UNICEF and I have gone all through that journey that of going from freelancing pulling things together myself to projects that are really massive, really beautiful have a huge impact, but today we’re here to talk about Agile. Just want you to take a moment just in 15 seconds, speak to person next to you, I will give you a moment do this, and have a quick discussion about this question, what makes an effective delivery team. I will pause for you while you just quickly speak topped person next to you.
Ok. Bring you back in there. I realise this totally a topic you could talk about for a really long time I appreciate I gave you no time whatsoever who had communication in what they said? Yeah, who had something else that related to people? So whether that’s they had the skills or something like that. Yeah quite a few people. Ok. So one of the things I think about effective delivery teams is that is much more about people and the interactions of people, rather than it is any specific process. But what if the process that you use helps encourage the communication and the interaction between people, for me that’s a big part of what Agile is all about.
How many people in here have no experience of Agile at all? So quite a few cool. We’re going to take this from the beginning, who use Agile ways of working semi-regularly at work? So about 5050, making it incredibly difficult for me to pitch it all at the right level, that’s good. A massive room I went to one of the other rooms I assumed they after all the same size. It’s great.
So what is Agile, for me this story starts in post-war Japan in the 1950s. In post-war Japan there was a lot of import restrictions to US on Japanese companies, and Japan doesn’t have the land mass or natural resources of America, and they needed to come up with the most efficient way of making their cars. So, they developed something called the Toyota production system. The Toyota production system, becoming known as lean manufacturing concept just-in-time, there’s a flow of work where the chassis arrives just before the engine needs to drop into it. Whereas in America you can have a big pile of engines stacked up waiting for someone to fit them to the chassis. They basically said our competitive advantage will be how effective we are at working together how efficiently we can do that. And the Toyota production system one of it main goals is to eliminate waste, that’s what it seeks to do.
So taking this a little bit more up-to-date, taking inspiration from what Toyota did, there was a paper in the Harvard business review in the mid-eighties, that was then talking about IT projects, or sort of systems projects and it said that the traditional ways of working, i.e. waterfall ways of working are not suitable for today’s competitive environment and a process where people pass the ball back and forth, more like a sort of rugby like approach court be more appropriate for today’s needs. Then what happened is, following this piece of research that was published in the Harvard business review, some people, mainly in America, in the sort of late, mid to late nineties started developing new ways of delivering projects. Waterfall project management, which is called because it’s sequential like a waterfall was first described in the 1970 by Winston Royce, he scrapped that as a way to build large-scale IT systems, the truth is what it took to build an IT in 1970 and what it takes today is incredibly difficult, in fact even in his original article he said, “If you just do this it’s risky and invites failure”, but everyone just proceeded to spend the next 30 years doing it that way, at least someone described something, right in the absence of something that works well, something will do.
So is the Agile, Agile is, in 2001, about 12 guys got together and created the Agile manifesto in the context of software development and websites and digital, this is really the point at which it comes together, what they created was these four statements: these four statements and 12 principles that sit underneath them, I’ve got printouts of the 12 principles for people that are super interested, I’m happy to dish those out afterwards, the principles say things like the best designs come from self-organising teams and, it’s those kinds of things, it sort of says, we welcome change even late in delivery. The things that sit under this are those kinds of things. At the top level, the Agile manifesto is, individuals and interactions over processes and tools, customer, collaboration, over contract negotiation, responding to change, over following a plan and working software over comprehensive documentation.
What they said is whilst the things in grey have value, the things in red have more value. So when, answering the question, what is Agile, this is Agile, with 12 principles that sit underneath it and you can read those in full at Agile manifesto.org, you can see some American dudes with their hands in the centre, wearing it together bro, kind of thing, it’s perhaps a little bit earnest for the slightly cynical British sense of humour they were real pioneers of ways of working, they have gone on to be successful in this space.
What most people know as Agile is a methodology that someone else came up with, based on this principle, just to summarise Agile is an iterative approach to delivering stuff, waterfall is a sequential approach.
Some of the Agile methodology, kanban, Japanese for billboard we’ll go into that in a little while, for a lot of projects, depending on the size of project you work on, kanban can do an awful lot, it’s a lot less pre-descriptive, than some others. DSDM, dynamic systems development method, yes, I wish is was on the naming committee of that one, it’s not used particularly heavily anymore, it still exists, the thing it’s best known for is creating a category of requirements, Moscow, you only receive the requirements in the first two, it’s not particularly effective, everybody says it’s a must, must, must then something really in significant, that would be really good but if we can’t get to that tiny thing it doesn’t matter too much. XP, extreme programming, the pioneers of a lot of the practices we held dear in development teams now, automated testing, test-driven development, continuous integration, that drive l really where they’re coming from, is to be more Agile and iterative, in your approach, you need better approaches to the way that you do technology and the way you maintain quality, so Agile is definitely not about quality going down, it’s about coming up with new ways of working to maintain quality that allow you iterate more quickly.
Scrum, 30%, of Agile projects use Scrum, it’s the one that has given most people the understanding of what Agile is, Scrum has sprints, it has stand-ups, it has the sort of planning session and the retrospectives, they’re not project management methodologies they are productivity frameworks, I would describe Scrum as a product-centric delivery system, forgetting through product-related work, it doesn’t deal with budgets and you know, things like that, that’s sort of more end to end project management you need to find a way of describing that in your organisation and your situation.
It also doesn’t particularly deal with how to kick-off a project, I will touch on that later. So the core Scrum process is, you have a product backlog, that is an exact priority list of items, they are often called user stories, in Scrum officially, they are product backlog items, then sprints shown in the middle, between one and four weeks in most cases, often two weeks, just try and make it so I’m not blogging too much of the screen, in spring you take items from the back of the backlog and move them to the top, half a dozen options, it might be a few more, it might be a few less, those items need to meet a definition of ‘ready’.
I do a lot of work doing coaching with items when you team is nod getting through enough work, probably, without exception, you will, there will always be a problem if the work on the product bag log meets a definition of ready, a definition of ready is a team-owned definition of the shape a piece of work needs to be in before you are prepared to work on it. That might be, we have had a discussion of how we are going to do it technically, we know what the acceptance criteria are, user experience design for it, it’s whatever is appropriate for the team and the product that you are creating.
You then do a planning session, where you breakdown the work for the sprint and you work out how much work you can take in, every day you do a stand-up which we describe at the moment, then a demonstration and retrospective, then a definition of done, which attribute does each individual piece of work need to meet for us today it’s done and that might be, it might be that it’s, you know, past your automated tests, deployed to test, it might be that someone has checked it might that you have cross-browser checked it it’s whatever your team has decided the definition of what ‘ready and done’ are.
At the end of that process, every two weeks, I’ll use the example of two weeks in this talk, you should have a potentially shippable product, so that doesn’t mean that you have to ship it, but it means that you could ship it if you wanted to.
So, the daily stand up, is an exercise where you answer three questions and you do it standing up and the, in Scrum it’s limited to fifteen minutes the questions that you answer are: what did you do yesterday? What are you planning to do today? Is anything holding you up?
The idea of this meeting and what’s really crucial about it, it’s not an update to a Project Manager, it’s not, it’s not a status report, it’s a synchronisation between a team so they can work together more effectively. So that’s, that’s the stand up.
Often at this point I do an exercise where I pull some people to the front and give them bad stand up behaviours, people that arrive too late, go into too much detail, talking in big abstract terms, we haven’t got time today, it’s a good exercise to play with your team or people you know, you make someone the ScrumMaster who has to try and control the group.
The planning session is in a two week sprint no more than four hours and split into two halves, in the first half of that meeting, a person that’s, that’s given the title ‘product owner’, or describes the work that they are hoping you will do over the next two weeks, in the second half the team breaks it down and works out if they can fit the work that’s been discussed in, if they can’t they push the least important out, if they still have spare capacity they take some more in, provided it meets the definition of ready.
At the end of the two week cycle you do a review, a demonstration, in the demonstration you run through all of the product backlog items you have delivered in that sprint and anyone can attend that meeting, it doesn’t just, you know, different stakeholders can come and they can see what is done and ask questions. It’s not a sign-off meeting, that’s probably what is really critical to say about that meeting, it’s not sign-off, if someone raises feedback that creates more work, that doesn’t mean that you haven’t finished the sprint it means you write a new product backlog item and it gets prioritised on the backlog list.
Retrospectives one of the ideas is continually reflecting and improving in waterfall product management, methodologies like Prince 2 have lessons learned logs, you keep a list of all the projects on, at the end you save that and you put it on some network drive somewhere that you never see again. Agile seeks to address that by saying we’re not going to just try and learn lessons at the end of the project, we’ll try and learn lessons every single sprint. What you do is you go through this process, this describes one technique by the way, glad, sad, mad, it’s pretty much as you would think you just brainstorm out all the things that made you glad, sad or mad, but there are loads of different Agile retrospectives there is a Wiki available if you Google Agile retrospectives there is all sorts of techniques, Edward de Bono six thinking hats, the sail ship, one on Thursday I did, force-field, where you analyse all the things that are pushing you forward and all the things holding you back, plenty of different ones to do, they all revolve around a similar process, that is you aim to generate data, you then categorise that data you might have, let’s say you have got a problem with a hosting provider and, and that would broadly fall into the category of tech and maybe someone has been off sick and someone on your team is annoyed about it, maybe that would fall into the category of ‘team’, whatever is appropriate for the data generated you categorise it. You prioritise, what’s most important, we can’t talk about everything in depth, is the probably one hour meeting, tops., for a two-week sprint, what’s most important, what’s holding us back the most, then you do some analysis on that, let’s bounce it around, talk about it, what can we do about this. Then you create actions and take those actions into the next period.
So, four teams, for teams that are not performing, running Agile methods it’s really common that they decided they didn’t have time to do the retrospective, “We’re too busy, we haven’t got time, we need to spend the extra hour deploying the buddy code, we are too busy, too tired, we stayed here all night”, it’s just like a cycle of things getting worse and worse, no one is stopping and going, “How can we make this better”, in a retrospective, someone might have gone, “Why don’t we phone the client and tell them their timing is completely unrealistic”, it gives you the moment to just reflect and do the things that make a difference.
So, in Scrum, the team is prescribed if you like, there are three roles, one role is the team, the collection of people, who can do the stuff you are trying to make and they are described as cross-functional, so if there is a piece of testing to do and your tester is busy but the developer is free, the developer should pick up the testing there are limits to how practical that is, so for example, there aren’t that many DBAs I’ve worked with that are particularly good at copywriting for example, the idea is, you may have heard this before, you want to make t-shaped people, there is a natural cross-over so people can help each other out on the team the product owner, the customer to the team, if you work in an agency or with a client to build things, truly the product owner is your customer, but you may find that you have to play a proxy product to owner role to scrap what’s required for your product. Their job as a project owner is to do all the liaison with other interested parties they are meant to be a single voice of truth to the team.
The ScrumMaster is the owner of the process but they’re not the boss it’s really important, they are sometimes called a servant leader. They own the process and they protect the team and they are, use the process to get the best result out of the team. So, the product owner and the ScrumMaster have in warring and outward facing roles the team itself actually stays very focused on the delivery.
By not having as much noise of all the things that go on around, they can get on with the work more effectively, basically, they do have to look forward a little bit but it’s done in a — there is a process with managing a product backlog of keeping the backlog in good shape and the way that I tend to do that, I have a one hour meeting with the client every week and you just, you are just trying to set up the work for the next sprint as you go.
So, the ScrumMaster, they own the process, they protect the team, they are not the boss and they should be a good facilitator, some of the attributes required.
The product owner is the voice of the customer, so in an agency set up sometimes the account management team might take on some of this role or the strategy, they gather feedback and make decisions, the team commit to the work in the planning session they say we can do this amount of work, sometimes things change, what that also means is if they say they can’t do an amount of work, the product owner can’t tell them that they can, the team decides how much work they can do, they swarm on high value tasks they do what is most important first, they have the skills to deliver and they aim to be cross-functional. Holding there for a minute, Scrum, the course takes two days that’s a super short overview of Scrum as a process. Scrum is really, really effective for fairly complex projects, that run for a decent amount of time. If you are building a WordPress set that is very similar to WordPress sites you have built before you may find that Scrum is too heavy for your needs, because within that two-week window or if you shorten it for one week you have to do all the ceremonies, all the meetings, get a schedule for involving your client and it may just not work for your needs in that environment, it’s sort of the complexity and uncertainty that Scrum really looks for.
So, I’m going to talk about second methodology, a subpart of the Toyota system, kanban, which I’m seeing get used more and more with Agile teams. So, kanban, is a pull system, rather than having a set sprint length where you take some things from the top, you instead just keep pulling the work through as you finish other work. So, there is no real beginning and no real end and you, you split the work into sort of swim lane categories, if you have used Trello or something like that, at the simplest you have to do in progress and done you might add a in test column or whatever it is, kanban is a visualised workload, it’s a big part of it.
It provides focus, sustainable pace and regular delivery, by focusing on optimising the flow of work from beginning to end. The Kanban principles are start with what you do now, so where is in Scrum we saw it was changing people’s job titles, calling someone a produced owner, some within a scrum master, and it was giving you very prescriptive process, actually Kanban says start with what you are doing the now and respect current roles responsibilities and job titles. Agree to pursue incremental evolutionary change so let’s say that our intention here is to get better and better at what we do. Encourage acts of leadership at all levels, so there’s your principles, but they are also 6 practices in Kanban. Visualise your work flow. I’m sure lots of you use tools for visualising your work flow, JIRA, Trello are all good examples of these, but you can just be post it notes and a wall and actually with a lot of the teams that I work with, they much prefer the physical board so we have carry around physical boards in our office that after just foam board and they are really big part of what we do.
We, you limit work in progress so for a Kanban process to work you say, there can only be three items in this column, for me to be able to work on them effectively. Let’s take an example of a restaurant, let’s say we’re doing a Kanban work flow for a restaurant, we might have columns like preparing, cooking, serving. For argument sake. And when we look at the preparing part of are work flow, it tons out we have only got two chop boards and two knives so therefore we can only be chopping two things at once so think about apply had to your own workflow what an appropriate amount of work in my columns to have in progress. The theory there is people can’t think about too many things at once. Now in Kanban that doesn’t mean you have to finish something, in order to bring something else in. But you have to put something on hold, if you want to move on to it.
Manage flow. Manage flow is about thinking about how long it takes to get things through your system, so what are the important metrics is it how long we spent researching the plugins or is it how long it takes to have the feature that works. So what’s important in the restaurant example, you know, the customer in this situation probably cares about how long it takes them to get their starter. Now you might choose manage sub parts of that flow because a sub part of that flow might be how long does it take to get order from the restaurant to the kitchen, how long does it take the kitchen to get that into it’s process. So you might want to measure sub parts of the process but the one across the top which is how long did it take the person in my restaurant to get their starter, that’s the truly important one, but you might find that some of you waste lies in different parts of you sub system, so you might have to analyse that.
Make process policies explicit. So, if something has to do something in order to move to next stage, that should be displayed, shown, known, and shared. with everyone. So in our restaurant example it might be that there’s some sort of note that has to go, maybe a process that make a note of which person is in which seat at our restaurant table we want to make sure that we know people get the right meal. That’s a process policy, that’s the process in this restaurant. The reason I like the restaurant example is because service happens two times a day in a restaurant it’s a place where, in any half decent restaurant you get the team together twice a day and you go before you kick off service, you say, right, this is it the specials, this is what we’re doing today, this is what didn’t go so well in the last service, this how we’re going to make it better. They get to iterate very, very quickly.
Implement feedback mechanism’s so retrospectives at one example of that. Improve collaboratively and evolve experimentally. We can’t do this today, but what I want to do is talk about evolving experimentally, that’s about using scientific models to analyse your work flow, and your projects and what’s going well and what’s not going so well. So, the theory of constraints, scientific, that means bottlenecks. So I you know bottle neck at my work is me. Because people are waiting for me to decide stuff and I am like, doing something completely different or trying to sell some new business or something like that. The lean economic model, that’s waste. If you think for a moment, when was the last time you thought about your personal work flow, not even a project you’re trying to do just your day and your work flow, and through the glass of where’s the waste, where is the bottlenecks, where is the variation coming in my day, you could pop probably say I have pretty much developed my way of working. I have read a few of the articles that tells me I only meant to check my email 3 times a day, I check it every 10 minutes. I tell people about this stuff I am zero in boxer I waste loads of my life, my inbox had not been into zero for 4 years now. That is a constant source of slight anxiety to me because, but what I want to do I need to retrain the behaviour and I need to think about my workflow go that’s not important, I am having this conversation with myself like literally now while you are in the room. (laughter) trying to actually make myself not check my inbox. I got down to 26 before I came here by the way. I could have had breakfast with Elliot, I am not ready the reason why is because I have been zero inboxing before I had a shower. But then I come here I am like, I am at 26 I feel better about it. (laughter).
So use that. I would say create examples of waste bottleneck and variation. I didn’t describe variation, there’s two types of variation, common cause variation and special cause variation. So, a special cause variation would be a sort of unexpected event, like a developer breaks their leg. Common cause variation would be you live on the southern rail line, and therefore you expect to be delayed every single day. (laughter) so, you want to talk a bit about requirements, we talked about the product bag backlog items in Scrum, I they are often captured as user stories. A user stories in the format as a user, I can feature so that benefit. So in this example, it’s as user, you might say I don’t know let’s say it’s a bar you say as a drinker, as a user I can log in, log in is the feature, the benefit in this case is so that I can access my dashboard. That’s a user story. As a user I can log in so I can access my dashboard. On read verse of that we have cot some acceptance criteria, what I will describe as a wire frame for the feature. How much detail you go in acceptance criteria is what works for you and is right. Here we just said the user name has to be 6 characters, the password must contain a number and capital letter you get locked out after 3 failed attempts. What we hope is that is enough to take that user story into planning and people would think about a bit more and talk bit a bit more. Then, the story should be negotiable, so a good user story is pained independent. It could be released on it’s own as feature. It’s negotiable so we could negotiate, maybe the 3 lock out attempts in our login story, maybe that’s a bit of pain to implement, clearly there’s just a plugin for that but let’s say we’re not using WordPress, then we have to code it custom for some reason. Valuable or vertical that means you shouldn’t, let’s say you are building a form, you should it’s better to build one field on that form that saves to database, than all the fields that don’t save to database. People are nodding, but yeah no-one would ever do that. I have worked on a project where that what people did, the reason they did is there was a separate database team and they didn’t want to solve interaction between the people. Estimable, small so you can fit several into an iteration, in my experience about half a dozen story is, the as soon use get near 10 things within a sprint for people to be remember, people can’t remember them. Testable in principle, even if there isn’t a test.
So just back over that Scrum process hopefully with a little bit more context now we have got a product backlog often as user stories they meet the definition of ready in order to go on to a sprint backlog we do some planning we have a stand up every day, we do at demo and retrospective, then we release the product, provided the product owner wants to it up to them. So in this example, here’s are product, and if I was going to write 5 user stories for this product I would say as a drinker there is a glass, so that I can hold my drink. Slake my thirst. As a barman there is a lemon so I can charge more for my drink, as you drinker, there’s a straw so I don’t smudge my lipstick, something like that. So that’s how you break something down in this instance these individual components are our features and the thinks that I described as a benefits, and I gave benefits of two deliver types of user, that could be involved in this product. Generally, I would seek to avoid as a CMS editor, user stories. If it can be articulated the other way round of what end user benefit, so if the story is as a CMS editor I can download a rep of all the people that filled in my contact form, that’s totally fine that’s a valuable thing, internally. But if the user story is as a CMS editor I can had an hero image so I can at a hero image, that’s not, the a ability to add a hero image is into the benefit. As a user I can see a hero image so I know what is most important right now is the way that should be articulated, you are thinking about the genuine end customer benefit.
Agile estimating this a big topic, righto wrap up quickly so we have some time for questions. There’s a couple of things here these are all to scale if you were going to try to estimate these in metres off the bat you would find it difficult so Agile has some estimating techniques one of them is triangulation, take something you know and estimate based off that. So if we know that the GLA building is 45 metres we can start to use that to help us work out what in metres the others are, but actually, specific units of measurement also make our life difficult so there’s a series of number called the Fibonacci series, there’s a trade marked Agile version that been slightly modified they are called story points so you assign story points to something that you know, and then you measure other things relative to that. So the it’s Fibonacci series is half 1, 2, 3, 5, 8, 13, 20, there’s a game called planning poker, what you do is everyone on a team gets together to do the estimation and everyone shows a card, you discuss the highest and lowest, and what the assumptions are that someone has made in order to make their assess moment and when you have that that discussion you go again until you get sufficient consensus to agree what something is. Let’s give an example.
You might say, that there’s an integrate Facebook user story, as a user I can share socially so I can amplify my message something like that, and someone on the team might assume that you have to build a whole Facebook app to do the type of share you want to do. Someone else might assume you will just drop in a piece of JavaScript that is pretty much, someone might go one, someone might go 13 you use that method that planning poker game to tease out that discussion about what hidden thoughts and what hidden assumptions exist in this team. Then what you can do is you track how many point you get through per sprint. This back in Scrum land. You work out a velocity that means you can forecast if you have got 200 story points in air velocity is 20 it will take you 10 sprints to get through that work. It’s super important to set a vision this a thing called a vision board Biro man, what it does is gets you to think about your target audience, their needs what features delivered against their need how that creates value for you or your customer, more your customer normally. You can map user stories into a user journey through time using a technique called user story mapping by a guy called Geoff Patton that helps you create complete end to end user journeys. Where I have put the green that’s one release. And that’s it. Thank you there’s, those final couple of topics are big topics in their own right if people are interested in following up there’s a couple of people you can Google and see their work. I will happily take questions from the room. (applause).
FROM THE FLOOR: Thanks for that great talk how would you go about coaching developers not to over solve problems?
JIM BOWES: In Agile it tends to be called gold plating, I think the role of the scrum master as I facilitator is really, really important. Because the scrum master coaches the product owner, and also the team on what it is to be Agile, and what I often find is that the product owner is the customer, you need to do some one-on-one time with the product owner first, if you get the product owner saying I want the simplest version of this, minimum version of this, if you can get that coming from the product owner and then maybe, it just depends if you have a team where someone is really struggling with that, I definitely think there is a mixture as a ScrumMaster, facilitator and coach, to mix-up sessions that work on the principles and then one on one time where you address people’s specific challenges with certain things. Thank you.
FROM THE FLOOR: Thank you.
FROM THE FLOOR: Is there a methodology that is designed to work well with teams of one, I don’t mean team of one, but maybe me and a client and that’s the only thing? So principally there are some things we can use with that, but we never have a team of three.
JIM BOWES: Scrum is generally considered for 3 to 9 people, tops and sort of 5 to 7 being ideal numbers. Kanban would work, Kanban is a way, if you have Trello and Kanban you have a way of just managing the flow of the work you can just say with your one client let’s only have three tickets that we are working on at only one time, even that process of limiting your work in progress and getting stuff through can really, really help. Yeah. Where are we going next? Yeah.
FROM THE FLOOR: Okay, first of all, Jim thank you for the wonderful presentation, I have one question: most of the time I’m working with WordPress you have the project that you are doing and you have some other project that you are maintaining, so how do you, if you want to make, let’s say Kanban or sprint and have the teamwork over the course of a week or two on a single project, how do you feed the support in it, or…
JIM BOWES: Great question, thank you for that, how if you are doing support work on multiple projects can you fit that when you are using one team. So, I often sort of say there is like the optimum situation for doing things like Scrum and that is you know, a full-time team, one product, no responsibility for anything that is live and basically that means that you are probably some venture cap backed project and you don’t live in the sort of real world. There are a few things you can do, set up a separate Kanban board and ring-fence a certain percentage of time for support, you can also run single back logs across multiple projects and so, manifesto we have a couple of teams that don’t have capacity for full time teams so we have pairs of people that always work together and that pair, effectively, will either work across a couple of back locks and we take a judgment call at the time, there is no like silver bullet on that stuff. You are sat next to Dave who has a lot of teams in a lot of projects who might give you fantastic advice about that thumbs up.
FROM THE FLOOR: The same question.
JIM BOWES: Oh, okay, someone that way.
FROM THE FLOOR: Hello how does Agile work remotely, so you have multiple workers that work remotely.
JIM BOWES: Distributed teams?
FROM THE FLOOR: Yes.
JIM BOWES: Obviously one of the, one of the principles is around sort of individuals and interactions and that becomes a little bit more difficult, obviously, there is lots of tools out there that make it possible and sort of video conferencing and things like that. I think it really helps if that team know each other beyond their remoteness. I manage teams in India for a few years for Barclays and the difference it made after they all came and stayed for two weeks and then when they went back the ability for us to use are Agile ways of working was much better, if you can possibly manage it, spend a bit of face to face time together. What gets lost is when someone is annoyed or — sometimes people will get the wrong end of the stick if you start to address those things, that really helps, but doing distributed teamwork, you know it can work really well but you, you need to sort of set the, this is how we do it and manage everyone’s expectations and get people all on to the conference call, make it super important to get on, on time, one of the most annoying things in the world is sitting on conferences waiting for it to start. Doing some sort of retrospective or a session where you talk about how you work together, it’s called a ‘working agreement’ you establish the ground rules for you as a team and the remote team and you normally find that things go smoother.
FROM THE FLOOR: Hello, how do you succinctly explain the benefits to clients who are used to a much more traditional design, development, test, launch process.
JIM BOWES: So there is a couple of things with clients, still today at Manifesto, although we are set up as an Agile organisation, we take a judgment call on how ready the clients are. We also do training, at our studio, we do sessions every two months where we invite people in so they know more Agile and the benefits. The we have a conversation really, if you are regularly seeing stuff if you can start adding content sooner, it’s those kinds of things, about it releasing value sooner is what that, that always… umm… that hinges on, the other thing, on the way here you asked me a question about clients and selling in time and materials projects, you know, we still get asked to do fixed price projects, I, I… I take the view that if we have done something before, I’m happy to take a history of course, in it, if we haven’t done something before — I will sometimes split a project into two portions, an example is, okay, there is like… there is three templates to build in WordPress and we have done that enough times to be relatively confident in fixing a price on it, then they want a collaboration feature, it’s just describe as a collaboration feature, then I will say something like, if we have fixed price on this we can’t do that, we will agree we will spend two days creating a collaboration feature whatever you have got at the end of two days is what you are getting as a part of this project.
ELLIOT TAYLOR: We have time for one more question, anyone? Okay.
FROM THE FLOOR: What role does a Project Manager have in the Agile methodology?
JIM BOWES: Yeah, so, it depends on the methodology that you choose, so certainly in a Kanban team you would have an Agile Project Manager normally on those projects and most commonly project managers in Scrum basically ScrumMasters and the honest truth about that, some are terrible at it and some are good at it, it’s really do you embrace the Agile principles, can… I have worked with plenty of project managers for whom control is an incredibly important part of what made them Project Manager, the ones that really focused on control tend to prefer waterfall, they get agreement on what will get built the interesting thing is, normally on a waterfall project there will be lots of change requests, loads of people, waste loads of time filling informs doing impact assessments, the same thing happens, it’s really about an journey for an individual person of can they be a ScrumMaster, maybe… there is also a role in the product owner, a bit more like a business analysts, sometimes business analysts actually make great ScrumMasters, what I would say, without wishing to dodge your question, it actually comes down to the individual person and do they embrace the Agile way of thinking, if they don’t they will struggle in pretty much any role in an Agile team.
ELLIOT TAYLOR: Thank you very much Jim.
JIM BOWES: Thank you.
ELLIOT TAYLOR: You few announcements, obviously, it’s lunch now, if you like queuing go straight away, if you don’t, wet, it’s easier to get lunch later. 12.30, there is a meetup organisers event in the activity room, if you are just thinking about starting a meetup, go and meet the other people, if there is no meetup where you live, I recommend you going. Thank you.