This week on the Boagworld show we are joined by Brett Harned, Sam Barnes and Holly Davis to talk Agile.
Paul: Hello and welcome to the Boagworld show, the podcast about user experience, digital strategy and digital management. My name is Paul Boag is normally I would be joined by Marcus Lillington. Unfortunately, he’s not with us this week as he has had a last minute thing come up which means he can’t be joining us, but it’s okay as we have a panel, a plethora of guests joining us this week and I actually think that is why Marcus isn’t here. I think he felt like he would be pushed at the limelight and so threw a little bit of a tantrum, that’s what I think.
So our panel of guests is Holly, Holly Davis. How are you? Good to have you back on the show.
Holly: I’m very well thank you, thanks for inviting me back.
Paul: Twice in a season, that’s how good you were.
Holly: You’re making me blush now.
Paul: You are in Lala land aren’t you because you’re about to go off on holiday, so your checked out of this podcast entirely.
Holly: No I am fully committed, as always. I’ve written notes and everything.
Paul: That’s the thing that amused me about Marcus when I talked to him on the phone and he said he can be on today. He said it’s really annoying as well but is the first podcast that I’ve ever actually prepared for. And it was like, oh great, fine, wonderful. I am glad that those 300+ previous podcasts you made an effort for. We’ve also got Sam Barnes joining us on the show, hello Sam.
Paul: So have you prepared? Have you got lots of notes?
Sam: Of course, absolutely. This is my field?
Paul: Exactly and you made an effort in buying a new microphone as well.
Sam: I think I messed it up last time so do it right this time.
Paul: Blame the podcast and never the guest.
Sam: It was probably Marcus actually is he is not here.
Paul: Yes, what a great idea. What is it you’ve got? A Samsung Go?
Sam: A tiny little mic which clips on the edge of a laptop and apparently according to you it sounds good, so it’s very cute.
Paul: Very impressed, well done. And finally, representing the other side of the Atlantic is Brett Harned. Hello Brett!
Brett: Hey, thanks to having me on again.
Paul: Well it’s a pleasure as always Brett. So what have you been up to these days? Anything interesting?
Brett: Oh, a little bit of everything. Finishing off a book, planning a new conference which I mentioned to you earlier – I am working with White October events to plan a conference in April 2017 and the conferences called Ground Control and it will be a new conference for digital project managers.
Paul: I’m very impressed that you picked up on my subtle segue to that, you’ve spotted what I was doing there.
Brett: You are so kind.
Paul: Well, you know. You know I am a huge fan of digital project management conferences. There needs to be more of them. I was a bit disappointed mind though because of the beginning of the show before we started recording, Brett said to me, I’ve got this conference coming up in April next year and I thought he was going to invite me to speak. But no, he just wanted to plug it on the podcast. What an arse! Just typical.
Talking of arsey comments… Brett, how is the book going? I think we have a bit of a bet?
Brett: The book is going quite well. I am working currently on my final chapter and I just recruited five technical reviewers so at the end of this month the manuscript will go out to technical reviewers and then it starts to get real.
Paul: So when we had our bet as to who could finish their book first, we didn’t work out the details did we? Where we talking about the first draft because in which case I’ve one? Or are we talking the first to market?
Brett: I don’t remember a bet but I wouldn’t put it past you to make these kinds of things up. So I am okay with losing. I don’t even know when it’s going to go to market but I would actually say I’m ahead of my deadline which I’m very proud of. Very project manager-y of me. I’m not sure how long it will take to work through the remaining bits though. Lots of work to do as the technical edits come back and then a full copy editing process and then I’ll be working through illustrations and screenshots and all of that stuff, so I’ve been told that I am over the most critical part in the most difficult part which feels really good.
Paul: Yes it is. Again that initial draft writing is the hardest part. The other bit I don’t like is going back through and adding in illustrations and stuff like that. I’ve done it as I’ve gone along this time as it just drives me nuts. I think we will conclude that I won.
Brett: I think your book will probably be out before mine, which is good because then mine can come out and you can start promoting mine.
Paul: We don’t want it to come out of the same time because otherwise I can’t promote you.
Sam: I feel a sales figure competition is needed.
Paul: Ohh yes… Hang on a minute Sam, are you setting us against each other?
Sam: I am stirring it, yes.
Paul: Because I have to say, I didn’t remember the bet with Brett until you said something and so for all I know you may have made that up?
Brett: I believe it was said in the last podcast that we were together and Sam listened to it and read the transcript because he hangs on every word.
Paul: He does hero worship as a bit I think.
Sam: I cannot deny this.
Paul: Anyway, when he you going to write one? No, forget it. Some writing a book is silly. Holly, when you going to write a book?
Holly: Hopefully one day.
Paul: Would you like to? Something that you’d want to do?
Holly: I absolutely love writing. I prefer writing more than talking. So maybe one day if I come up with a strong idea.
Paul: You don’t need a strong idea, look at the stuff I churn out. Is quantity over quality every time. That’s my general approach to life in general.
Holly: It has worked well for you.
Paul: Don’t rush guys, to contradict that by the way. There was just an awkward silence at that point.
Brett: We were just giggling.
Paul: So yes, it has worked for me Holly. Thank you very much for acknowledging that. So anyway, today is a bit of an experiment for me which hasn’t started great as this is already the second time we recording this, but next season I’m talking about doing round tables like this the whole time. So for every episode we are going to have a selection of different guests and we’re going to have a designer, a developer, we going to have a project manager and have somebody from each discipline and they will all bring along a different thing for us to discuss. That is the idea anyway but we thought we would try the technology out this week and we thought we would experiment on our team project managers, which is Brett, Sam, and Holly. So sorry, you guys are guinea pigs but you don’t care.
Sam: No we are into it.
Paul: That is good. So I thought, what shall we talk about? It occurred to me that all season and this is the 13th episode, not once have we talked about agile. A project management season that doesn’t talk about agile! So that is what we going to do. We could spend a little bit of time talking about agile and agile development and how agile fits into your average web projects. But before we do that I just want to quickly talk about our first sponsor which is FullStory. FullStory is a pixel perfect playback session to that empowers every person in your company to help build the best online experience for your customers because you just need to add one tiny little script and every click, every swipe, every scroll, everything the user does is recorded. There is no manual events tagging so you don’t have to go in and say, I want to know how many people have clicked on this so I need to take that as an event, none of that. All you do is install this little script and then you can get high fidelity playback, so you can watch user sessions including the full dom and console logs which is just brilliant for diagnosing bugs and that kind of thing, as it would run in a customer’s browser. See can do things like funnel analytics, you can do detailed searches, you can do customer segmentation all of that kind of stuff see can drill down and find out what is going on as I said it’s great for finding tools and integrates support desk software.
You can sign up today and get FullStory for two weeks absolutely free to give it a go. There are a few things to give you the top level summary before you go and play with it. It will work with your Ajax heavy single page app or anything built on a modern framework like React or Angular, FullStory will still record everything perfectly. It only takes about five minutes to implement you just into any page that you want to record and that is it. Every user action and element on the page is automatically captured without the need to manually tag anything. Because every aspect of the user session is captured you can use a Google -like search engine to ask specific questions as you got this really rich dataset to draw upon. The interface is deadly simple to use as I run it on my own site so it has to be pretty simple. It’s something the designers, engineers, project managers, support people, marketing, whoever can jump in and immediately start learning about stuff. To give it a go, go and check it out at Boag.world/tryfullstory.
Discussion with Holly, Sam and Brett
Paul: Let’s talk Agile. So I’ve got three questions that I’ve pulled together to give us something to talk about on the show so they are not from specific individuals but as a collection of themes.
The first one is, ‘you can’t talk about project management without mentioning agile, so what do people think about agile vs waterfall? What are the pros and cons and do you use it wholesale or do you pick and choose? Holly do you mind if I start with you as I get the impression you are the only person who has done any prep for this?
Holly: I’m happy to kick-off. I’d say about 70 or 80% of the projects I PM at White October are agile of nature so we work in fortnightly sprints and I transitioned about three and half years ago from an agency that was more 70 to 80% split between waterfall and maybe even higher than that and one of my main reasons for moving was having a difficult last project at that agency where I thought the project and the client would have been much more well-suited to agile. At that point is mainly theoretical knowledge of agile but I was fed up of issuing change requests and charging the client every time she changed her mind and I thought there was a better way of doing it. Looking back at why I moved and how we are using agile, obviously it’s not a magic bullet is it doesn’t fix everything overnight but I have definitely seen benefits and have become during the last three years, quite an advocate of agile. It’s not suitable for every project and we’ve yet to make it work on CMS projects or mobile work but it is definitely this complex software builds with front-end and back-end working and fortnightly sprints and all the agile ceremonies have helped us work better together as teams. There is a strong emphasis I think on the product owner and the client being involved and collaborating with the team in terms of defining the scope small batches of work, which I much prefer over the big reveals and upfront technical specs. So as a PM I definitely prefer it is a methodology and I believe and think the principles of agile have remarkable benefits on the team culture and ethos of how you manage technical software development projects. So yes, I am a fan I guess in summary.
Paul: You said there that don’t find they work particularly well on a CMS project, so are you saying they tend to work better on web apps rather than websites? Is that we mean is it something else?
Holly: No, that’s exactly what I mean. That’s my personal experience. I think you can probably adjust the process to work for different types of projects but I wonder maybe if it ties into the fact that on those sort of projects, the scope is more fixed so perhaps agile doesn’t work as well and maybe something like kanban would work better. I find where the scope is likely to change and adapt as you work through the project, agile works best.
Paul: Can I ask a question? This is a bit of an embarrassing question; can you tell me what kanban is? I’ve heard about it but I’ve no idea what it is. I know it’s a project management methodology I am guessing. Is it a bit like agile but not?
Holly: There’s definitely agile principles instead of working sprints, you continuously prioritise the backlog which is essentially the to-do column and instead of looking at velocity as a measure progress, it’s more about cycle time into the issue counts them start to finish on that journey from to do, in progress, in test and done. You can do reports on how many issues you are getting through the team and I’ve used it more on support projects but I have used it on a couple of projects where the scope is fixed so sprints is more of an arbitrary thing and not necessarily useful for those projects but it still instills collaboration and involvement in the product owner to prioritise the backlog. On some projects I know that the developers can pick from a list of tasks that are prioritised at the top the backlog rather than working through the things in a certain order. I’d like to learn to know it a bit more as I’ve used it on a very small level. I don’t know whether Sam and Brett have ever used it?
Sam: I think like you have used it for support work, work that doesn’t need to happen or doesn’t have any dependencies. I’ve also known operations teams use it as well for work that has to be done. It’s just ongoing to us a nice way for someone to prioritise it, and I think it’s a lighter touch than either waterfall or agile.
Holly: I would agree with that.
Paul: That’s interesting. Going back to the website and using agile for developing straight website, Brett or Sam or whoever, have your experiences been the same? You agile just doesn’t suit a CMS type build and if so, what is it about it the makes it incompatible?
Brett: I think it’s interesting because I’ve never thought of it in terms of the process working for a web app vs a website but I do see how that definitely makes sense because I think adding a CMS just adds complexity to a project when it comes to technology and building it and getting stakeholders involved. I think for me the biggest factor when it comes to trying to run projects with an agile methodology is the people involved, particularly clients because I think a lot of the work that we do typically it happens earlier in a project when it comes to either research or design, it does require a lot of outside input into the process and that outside input can be from a client project manager or a team of stakeholders. I think that is usually what tends to slow the process down, whether it be agile or waterfall or whatever you are using. I think for me; I like to pull aspects of agile into projects to make it work. Think of it almost like Frankensteining the process that works not just for the team who is building the product but also for the people that you are almost selling the product to as well right? Because on some level that is what we are doing when we are creating designs and selling a design for something and trying to gain input and consensus from stakeholders within the client organisation. And so I recently worked on a couple of projects that were touted as being agile. But as I got further and further into them I realised that this particular agency, and this is me working as a freelance project manager with an agency, there are using principles of agile and the ceremonies and all of the things that if you were to read about agile, you’d say yes, this is agile but as you get more into it you realise there were so many dependencies when it comes to a client team and there are still so many places where they can hold up a process, whether that comes to making a decision on something or delivering content, whatever it might be.
Paul: I’m just quite interested in which bits of agile you find particularly worth keeping and what you discard if that makes sense?
Brett: So personally I think the things that I really like are the fact of having a backlog and user stories of things that point back to that are all roll to specific tasks which roll up to goals. I think that’s really helpful to keep everyone on track. I also really like the daily stand-up just as a PM I like to know what’s happening and what the potential issues are on the project and I like, what agile calls the ceremonies so I like sprint planning, planning the work that’s going to be done over the next couple of weeks and then the sprint review coming back around and discussing what’s been done. I think if you are going to run that, an agile project in an agency setting with clients is really important to hang on to those things because you really want to do everything that you can to keep the communication transparent and keep the team honest about the work that they are doing and what can actually be done, basically keeping expectations in check.
Sam: I think Holly got close to the real problem for me which is that she said some projects are good for agile and some aren’t, that’s what it boiled down to. For me is about the unknowns of the scale. One thing I remember reading about agile was that you shouldn’t confuse manufacturing with web development and analogy is designing a car vs building a car. So to design the car you need to go through an exploratory process and is going to change and find out things and you could have to adapt and whatever but once you’ve nailed the design you’re ready to put on the production line and you could just create that spec and fire it off and it will build a repeat and repeat. When you’re working with a software development project, something bigger, quite frankly the unknowns are more. There’s lot more they don’t know, a lot more integration into systems, a whole load of more variables that you can’t control of the beginning. Whereas if you work on something that is your bread and butter perhaps or something that you’ve done the client many, many times, be it campaign work or small CMS based websites, then you are going to find that there are parts of that process, all of that relationship with that client that will fit a repeatable cycle. That’s for me is the key difference between the two.
Paul: So it is a bit of a loaded question but if we are saying that there are some bits of agile that we like, by implication there are some bits that we don’t often fit with the projects and we dump. Which of the bits that you tend to dump some?
Sam: Tend to dump? You could do a whole season on that. It sounds like a really rubbish answer but the truth is I completely agree with Brett as it may does depend on the client, the team and the particular project. So one of the things that will get dumped in an agency environment is the product owner interaction. Now the product owner should be the client but the reality of that is pretty difficult to get a client so engaged on a daily basis.
Paul: Which is a shame because in theory one of the most valuable bits potentially of agile is having the client embedded in the process and seeing how it works the whole time.
Sam: There are ways, you could use a proxy product owner and this is what an internal team or agency would use any just means that there is a representative on the internal production team who is masking as the product owner. Really you’re just being a traditional PM, understanding requirements and translating them into the team so it’s debatable the value of that as such in terms of the actual product owner being there. Is how you get by if you are going to work agile in certain environments.
Brett: I agree, I think if I am on the client side and I have hired an agency or even just a group of people like this to create something for me I don’t care as much about the process because I have potentially five or 10 other projects happening at the same time and other things that I need to handle in my day-to-day I want you to just come in and guide me through a process this going to work. I probably am not going to have time to be a product owner and be in every single meeting, especially a daily stand-up I think that’s where things start to break down. When you run an agile process you place a pretty high expectation in terms of people’s time and involvement in the project and I think it’s just not realistic to ask all plans to do that. When you do find a client that can do about I think it’s a dream scenario and I think it can work out really well. But I think the roles tend to break down and it’s something that you drop.
I think to, the thing that I am not necessarily a fan of in general is rigidity. I don’t want to be tied to something really specific. I want to be able to pivot at any point in the product and say that the way we are doing this isn’t working, we going to try something else, for the sake of getting it done fast and having a better product at the end of the day. I think when you tend to follow a process so tightly, you lose that flexibility and I think the scope of things tends to creep a little bit and there are more ways of being efficient without having to stick to a single way of operating.
Sam: It’s actually another twist on the whole repeatable analogy because thinking about that, where I have seen the rigid agile processes working is where the environment is a lot more predictable. For instance, internal production teams working on a product for their own company. When you get that right and to get the heartbeat of all the ceremony going, there is a lot less that can come out of the blue and surprise you or if it does there was a mechanism to deal with it because it’s happened before. But when you’re dealing with clients, as you will know, you can never tell what is going to happen so that ability to change quickly is absolutely critical in terms of changing process.
Brett: I think to, it’s just my mind always goes to design and the decisions that need to be made and that’s just based on where my interest lies within the process of I get really into UX and design. I think that’s where it tends to break down a little bit more as I do think once you get into development it is a little bit easier because things are mapped out and there are less decisions being made and you can really be heads down, getting work done. The projects that I worked on recently, we were doing design and code altogether and it was pretty exciting to see that come together see the client that wouldn’t be a big reveal as it would be part of a process, but seeing the fact that we are building something in a sprint that is potentially shippable within two weeks, that is pretty cool.
Paul: That brings us on to the next set of questions really which is one of the big criticisms about agile is that it’s not very designer friendly as you just said Brett. I’m interested in whether you guys agree with that or what adaptation needs to be made to agile in order to make it a more design friendly process. Holly do you want to kick us off again on that one?
Holly: I think the goods far outweighs the bad but it is a challenge as I think as a designer you need to be challenging the level of fidelity for each user story in the sprint and the level at which you need to produced your designs at. Sometimes it’s a sketch and sometimes it will be a full on design. I think designers once they get used to that will find it quite empowering and liberating and it really focuses the whole team on reuse in terms of a component library and once you’ve got a certain level of design that you are happy with and the clients are happy with, looking at the subsequent sprints at what components can be reused for those pages or templates, I think that is quite a good behaviour and a financially sound way to approach a project. We found two things which have made it a lot easier from a design point of view, the first one is that we tend to start these larger agile projects with a preparation stage which we internally refer to as runway. One way just determines the minimum amount of design and UX we need to do before we can start sprints. That differs per project in terms of length and what exactly it involves. The type of activities might include competitor analysis, building personas, viewing brand guidelines, starting a mood board, site map, style tiles, basic grey box wireframes and at that stage we feel able to go into sprint development now we’ve done enough up framework but not too much to define the design but enough for the designer to feel comfortable because I think previous to that we didn’t have that stage and designers going into an initial sprint with a bunch of work that needs to happen before they can start producing designs and the pressure right from day one on the designer to deliver designs and sprints which was literally not achievable. So I think that they found at the starting block of the project and the foundation that they build upon really useful.
The second thing is sprint refinement which is another agile ceremony so if you’re working in a two week sprint, one week into the sprint you would sit down as a whole team and look at the stories in the next sprint and look at what level of UX we can do prior to that sprint starting. Start thinking about the user flows and the areas of complexity if we want to do any user testing or corridor testing, we can do that ahead of the sprint starting. I found those two things, the runway and sprint refinement during the development really helps. Our design team also do something called fresh eyes where they get together as a design team and project team members I invited if they are available to look at each other’s projects which helps the team to take a step back and see the project at a higher level and highlights areas in need of attention. Because I have found working on agile projects that you get so caught up into the current sprint that you don’t sometimes take that step back and think is this working at a higher level?
Paul: That’s so important from a design point of view as well because designers tend to look holistically, especially in the early parts of a project where they are looking across the whole thing, does this user flow work from one place to another? That’s where I’ve always struggled with agile is that you end up getting bogged down in a specific piece of function and a specific part of the experience and you end up making design decisions that don’t then translate well across the rest of the website. I am guessing things like the sprint refinement and the fresh eyes bit would flag those?
Holly: Yes, to some degree and I think what’s quite useful if you can do and the timescales allow for it is to build in user trials which have specific goals that break up the project into even smaller chunks that are even larger than the sprint but you can say you are working to this goal and at this point we’re going to be able to test this certain area of the system. That will quickly unveil if there are any problems with the user flow or the usability issues at which you can then planned for in the next user trial. Something that is important rather than leaving higher level user flow reassurance and testing until the end. Giving the team the ability to be able to add UX improvements to the backlog, we often add new stories to backlogs but it’s up to the whole team really if you see something that’s niggling you or something that doesn’t seem to be working as well as it could do, to be able to empower the team, that’s a good thing to be doing and to be reviewing those at the end of each sprint and thinking, should we tackle these now show we come back to them.
Paul: bet you have some concerns about agile from a user experience and design perspective. What problems have you encountered?
Brett: I think it’s mostly been about decisions and I think to, a lot of it has to do with sensing expectations with clients and what they are going to see when and how’s can evolve. I think it’s probably really important to sit down and the very beginning of the project and we really clear about what the stories are based on the goals for the projects and I guess what those stories will then turn into functionally. My biggest concern is always that you deliver something and a client will see a piece of functionality and won’t be happy with it and then you have to continually iterate on it throughout the course of the project, whereas there are a lot of pieces that you need to work on. That is the goal of agile, it’s not that everything is done within one sprint, a lot of it is about iteration. I think that you have to be really diligent about setting expectations on what the definition of done is. I think there can be really particularly difficult especially in the bigger projects where you do once in space and time to think and iterate but you’ve got a deadline. I think that in our agency world, you are constantly working with a fixed budgets and a fixed deadline whereas I think agile is a little more open in terms of iteration and launching with a project that is an MVP rather than a product that is a final done deal with a closed off budget.
Paul: Yes, which is a whole other conversation about how many organisations finance digital projects and how they see them as this capital expense that you invest in every few years and then you do a redesign which is probably not the best way of viewing your website.
Sam, what about your experiences from a design point of view?
Sam: I think my points are been touched on already but I think it’s one of those areas but I think when people start to think about working a bit more agile they don’t consider that, I certainly didn’t and it took me to by surprise little bit. Is really just twisting the hold traditional workflow on its head for design I think and you mentioned it yourself. What we found as a decent solution, I wouldn’t say it is the be all and end all but it does require that the teams that were working on projects for the duration of that project as the design team or single designer. If you work on a product especially across teams, you need to really get a line with the rest of your design team and have a holistic approach to that design strategy. You need to know where you’re going at some kind of level because when you get down to the sprint plan its so micro level that it’s hard to bridge those two worlds. I think the designers particularly struggle with this and we tried all sorts of things. Initially we started doing the design exactly the same in one sprint. We found it didn’t work for us because it’s one of my frustrations with the community around agile in a way. The context of agile is never focused on since starting up agile after using scrum in a start-up or small agency, building a product is completely different to an agency with clients or a very large software house who has 10 years of legacy systems in place and processes and things like that. One thing that we found help slightly but did have a downside was that we either did something similar to what Holly’s team do but we call it a sprint zero, so it was a two-week prep to get ideas in place. You weren’t tied to delivery and we also tried to do design one sprint ahead, so we would know what was in the backlog. We know how to prioritise we know what’s coming up essentially so we would get some design people inside each team, thinking about that sprint ahead. The benefit of that was of course that we were able to go into the production sprint and be a lot more efficient and deliberate but will be found was the downside was actually to do with the designers as people themselves. They felt very isolated and outside of their own team, so they are always in a different world. I wouldn’t say I’ve worked some whereabouts in practice it’s a really hard thing for the context is so important as a lot of blogs and a lot of people talk about how easy they find it but again if you’re starting with a greenfield product and a very small amount of clued in people, I think it can appear to be easier than it actually is in the reality of most businesses.
Paul: From my point of view, for a long time utterly dismissed agile because I come from a design background and a UX background and it just felt wrong to me.
Sam: One thing Holly said was the word component and I think that stands out to me is very much anti- what a designer is to bring to the world. It’s like a factory again.
Paul: Also, the majority websites that I produce and I imagine a lot of agencies produce are not web apps, they are content heavy websites, CMS-based projects. Eventually I did come around but it’s quite a Frankenstein approach to agile which is that I keep the sprint mentality but instead of a sprint consisting of addressing a series of user cards dedicated to a specific set of functionality, what I do is each sprint is dedicated to a different level of fidelity. So the first sprint may well be just doing information architecture and some drawings on bits of paper that we test and iterate within the sprint, then you go from there may be and the developers install the base CMS and you put the information architecture in that and you map out the structure of the website a little bit and you identify key bullet points for the different content that appears in different sections and that’s it. Then the next sprint you are adding in some typography and some basic layout and then the next sprint you are adding in a bit more, all built into the final platform. Essentially you iterate the entire site in levels of fidelity, adding in colour, adding in more and more layout. You get the idea.
Sam: That sounds like a good solution in many situations that I can think of.
Paul: It seems to work quite well within those kinds of projects where they are design and content led rather than design and functionality led. Expecting a developer to iterate functionality is not impossible actually. To begin with you ignore all your error handling and you ignore whether every little bit of that functionality works, you get the main core of it working and you iterate that way. What I guess you are not doing which is a fundamental no-no in proper agile is, you haven’t got a shippable code at the end of each sprint.
Sam: Exactly, you talked about early about which bits you often dump. I bet a lot of people actually dump that even though they probably wouldn’t really recognise that because what you just described their sounds like a very sensible approach. I’m thinking that as you are saying it but actually throwing away one of the main tenets.
Paul: Holly, what do you think about my random solution?
Holly: I think is brilliant and that’s how we have been approaching our CMS projects and there’s a distinction that Sam said in that agile is splitting stories into small vertical slices which can be shipped at the end of the sprint. Whereas the process you talk about I think works much better for CMS projects, working in more horizontal slices see you’re building up the CMS website in layers of fidelity, starting at a prototype level and then building on top of that and iterating on top of that. I think that is the distinction really that is working more in horizontal layers and agile is working more in small vertical slices. I can definitely see in practice how that approach works better for those CMS projects which are content heavy.
Paul: Actually knew reach a point where you can almost switch from horizontal to vertical. Once you’ve got a structure of a website in place, you know the flow, the design pretty much, then it becomes more the development issue and a content population issue. Then you can switch to be vertical and deal with section after section. To begin with we started off doing this sprint zero and the runway approach but we kept feeling the need to revisit the design because it wasn’t quite right and we had to keep stepping back. I guess your sprint refinements would do that but looking at it horizontally just seems to work for us a little bit better.
Let’s move on then to our final question which is relating to how to present agile to clients stop we’ve already said that agile works better for some clients than others but with any client has encountered agile before, even if we think they are inappropriate clients we need to essentially introduce them to the idea of agile in whatever form it takes and explain it. Semi-clients are used to fixed price projects with well defined deliverable is, I’m interested how you guys have sold or introduced that agile methodology to clients in such a way that they still feel confident that they are going to get a deliverable within their budget? Sam, due to kick us off with this?
Sam: My answer to that is not sell agile. It sounds cheesy but it’s true as well that a lot of people going to a client meeting pre-sales or whoever they interact with, with agile being the only solution. I just fundamentally disagree with that so I just go in there and say not going to sell agile and just sell them the best delivery method for that project and for them. If I spotted that it was going to be the agile was the better way of doing things for them I would ask questions first. I would ask how the previous projects have gone with internal teams all with previous suppliers whatever it might be and in those answers sometimes you would get a little bit of leeway to bring in agile. If they say their products are too long always late or cost too much and always over budgets, constantly delivering the wrong functionality and so on and so on, the main thing I’m looking for here is to get them used to the idea of get them agreeable that changes needed. We don’t want a repeat of that. That then gives me a platform to suggest another type of solution which of course sounds waiting to get into the mechanics and there will be lots and lots of questions. I would never make it sound easier than a waterfall, I think that is a real big problem with that in our industry. Doing agile and using scrum which is what I’ve done most is not easy, it’s really hard and I think people over sell it a bit. They sell it as the silver bullet solution and it’s not so I would never say that. Really it is being prepared to answer any questions and concerns of they have, not just about the process but things like how this would work with your finance team, explaining about a proxy PO and all these things that could be used. Sometimes you would present case studies, ideally and is possible now with clients that have been with you for a number of years that have used waterfall with you now use agile, how they have found the difference. But if you say in a meeting room in a pre-sale or anything like that, they don’t trust the words of a previous client over yours no matter what when you’re trying to sell a new funky way of working. Those are just some of the ways that I’ve got people on board but I think the key is to not make it sound like it’s the be all and end all, is just another way of delivering work and has its own challenges as we talked about pros and cons earlier. Just be honest about it.
Paul: I want to ask Holly in a minute because she uses probably agile more often than any of us, I’m quite interested in one thing you said there Sam you talked about a proxy PO. Assume you mean a proxy purchase order? What is that?
Sam: No, product owner, a proxy product owner.
Paul: Oh I thought you were talking about the way it was funded. Holly, how do your clients have to get used to the way that you tend to work? How do you introduce it to them?
Holly: When I first started at White October and we started to do projects like this, they were normally on a time and materials basis. We found with these sort of projects the scope tends to increase as you work through the project. New stories are added and so projects were going over budget but they were legitimately going over budget in terms of the product owner deciding to add new stories to prioritise those stories. What we found a better way to present it to the clients and to work with clients to do a price per point. So basically what we do now is convert our clients budget to a points budget and we estimate our backlog normally after we start a project, we do an exercise called user story mapping which builds a project backlog and then we estimate that in story points and convert that to a point budget which is something the client can then use. That point then factors in everyone’s time on the team, design, development, AM and PM and its the amount of cost to the agency to deliver that point from in progress to done and the client only pays for that point when they sign it off in a adherence to their acceptance criteria which they work with the team to write.
Like Sam mentioned earlier, this works really well if the product owner and the client is very closely involved in the project but one of the demands like Brett said is that we tend to ask clients who want to work in this fashion for up to 2 days of their week to be dedicated to the product in the project team and some clients absolutely love that and they choose us because of that and some clients just don’t have a level of time, so we agree up front and like Sam says, ask the right question to find out if this is going to be the right way to deliver the project. But if the client can give you that and be involved in defining the definition of done at a feature level and then signing that off on the basis of what they decided would be the spec for that feature, and then we only invoice once they have signed it off. Then the client feels a lot more in control of their budget because they know they’ve got a point budget that can’t fluctuate or change and they can decide how to prioritise those things in accordance with that budget which helps them feel they are not going to go over budget unless points increase during the project, but then they are still in control if a point started off at a user story mapping phase at one point and then when we are talking about it in sprint planning and it grew to a three-point story, we would then say that the client and say that we’ve introduced a lot of complexity and me estimated it at the start of the project was based on doing XYZ. We’ve now increased the complexity of the story which has increased the estimate, do you want us to look at breaking that story down into two half point stories or reducing the complexity to bring your point budget back down? We found that really works well on clients and they respond to it very well at the start of projects we are starting to engage with clients, they feel quite comfortable with that as a metric for managing their projects.
Paul: Yes, that makes perfect sense.
Sam: Blown my mind here.
Paul: I’m sat here thinking wow. I think the thing I’m thinking is that ultimately if you are going to use agile you are saying one of two things to the client. You’re either saying I cannot guarantee that for whatever you want, we are going to be able to do that within price. You’ve got round that by saying the prices fixed but then the trade-off is that is that we can’t guarantee you that we will deliver you a specific thing within that amount of money. That still strikes me as a hard pill to swallow as a client, is essentially saying we can’t tell you how much it’s going to cost or we can’t tell you what we going to deliver within that cost. Brett, what is your experience of this?
Brett: I don’t really have that much experience in that realm to be honest with you but I’m with you. That’s always been my biggest concern, knowing how I, is a client I’m going to get at the end of the numbers that we’ve agreed to the number of points that we’ve agreed to, I going to be happy with what I get? That would make me the most nervous. As I was listening to Holly, I was taking notes and think it’s a really smart idea. I wonder if that also increases the amount of project management time on a project and I’m wondering if there’s a lot of handholding that you have to do educating you have to do when it comes to these projects and conversations with clients?
Holly: Yes definitely, I found that working on these sort of projects that my time is may be double or even triple than on other projects. I think checking meetings with the product owner, reviewing the backlog in addition to the other agile ceremonies, as an additional amount of face time of communication that you have to have with the client, to make sure that they are happy and I think as a client if I was on that side I would feel maybe there was more sense of pressure on me in terms of we always go back to the client and say, as a product owner, you are in control of the vision and the priorities of the project and I think if I was one of our clients, we support them a lot. At the end of the day they are making the decisions as to what is in or out of scope at each point. Making that decision playing on them, making sure that their budget doesn’t expand too much is some degree on their heads to contain it, to push back, does it fulfil one of our KPIs of the project? Can we launch about it? Can we hand crank it and is there a different way that we can deliver this without building the functionality. Asking the team to challenge the client, the team to push back on creating new stories and adding complexity until it is absolutely needed.
Paul: In essence what you are doing is you are moving away from selling deliverables as in a website or a web app or whatever, to selling skills and people and time, which is a very different mindset and is more like selling a lawyers time. They don’t sell results, they sell their time. Sam have you anything to add?
Sam: Just listening to the conversation is fascinating because to me it all boils down to trust. Sitting right around back to the beginning, one of the biggest differences I think between waterfall and agile is the level of trust required or forced and minimised. In waterfall you don’t as a client, need to be as trusting because it’s written down what you are going to get, how much is good cost and sometimes by when. Many clients will hold you to that so it removes the risk factor for the clients. I think when it comes to working in an agile way it doesn’t require trust just from the supplier or the client, whoever is doing it, the production teams, the managers of that company, everyone has to have that higher level of trust that everyone is going to do their best because the way it should be argued to the client is that yes, we can’t promise that we’re going to give you what you think you want now by a certain date by certain time, but we can guarantee for that price and by that time, using this process of prioritisation and constant collaboration we are going to give you the most value for that time and that budget. That’s a big sell and it’s really about getting the trust.
Let’s say they have a three month timeline and a budget that accommodates that. A client that knows that the supplier or agency is going to deliver the most valuable work in those three months which is the whole point really of working that way. It requires trust and evidence. It’s a big sell and if you get that trust I think you are onto a winner. It’s a mistake to think that a client should just think it sounds great or just trust you with no evidence.
Paul: Absolutely. That’s a really good point to wrap up on. It sums it up for me perfectly and it’s a winner for everybody concerned. It’s also a winner for the client if they get an agency they can trust and they know will put in the best effort they can possibly can in that time will stop it works out better for them as well. It’s all about the relationship as is everything we’ve talked about on this entire season. It’s all about relationships and getting those relationships to work.
Let’s quickly look at our final sponsor before we wrap up this week’s show. Our final sponsor is FreshBooks which is a super intuitive tool for making, creating and sending invoices in an extremely simple way. Using FreshBooks takes about 30 seconds to create and send an invoice which I think is time well spent in order to get paid. You can add your own logo, colour schemes and all that kind of stuff. The client can pay you online which can seriously improve how quickly you get paid – trust me on that. FreshBooks can also show you whether a client has looked at the invoice that you’ve emailed them, which I always think it’s a very telling little metric that they provide and you can send late payment reminders automatically to a client which means you are not spending all your time chasing down late payments. Also if it’s automated it doesn’t damage the relationship with the client in the same way. You can also use FreshBooks to set up a deposit. Is got a deposit feature so that when you first win a project you can streamline all of that initial deposit. They got loads of other extra features including cash flow tracking, time tracking but really the most important thing is that getting started with FreshBooks is extremely simple, even if you are not a numbers person. FreshBooks is offering a month of unrestricted use to all the listeners of the show and is totally free right now and you don’t even need to add a credit card to get going. To claim your free month go to FreshBooks.com/boagworld and enter boagworld UX show in there how did you hear about us section.
So, that’s it and this is the awkward part. Marcus usually does the joke now. He’s given me a joke to do. But to be honest my heart isn’t in it so I’m going to say the words because then I’ve done my bit but don’t expect any delivery as I think this whole joke thing is ridiculous and if I had my way we would stop it. But Marcus insists.
This is from Bob Salmon who said, ‘someone threw a bottle of omega three pills at me but it’s okay, I only got super-fish-oil injuries’.
See? That was the joke he picked out and you wonder why I don’t want to do jokes on the show.
Brett: It was a setup.
Paul: It isn’t mind, I swear to you he thought that was a good joke.
Sam: Is the way you tell them Paul.
Paul: The way I tell them? I tell them better than Marcus does!
Sam: There was definitely some kind of contempt about that delivery.
Paul: I will give you that, there was a level of contempt. Thank you guys so much for coming on the show, I really appreciated and it’s so great to hang out with you all. That’s it for this season. It’s been a really good one, talking about project management and management issues. One of the most popular seasons with ever done, interestingly Brett you have a claim to fame, I don’t with you knew this. Before this season when you came on and talked about project management issues, that was the most popular pod cast episode we’ve ever published!
Paul: I know! We’ve had Geoffrey Zeldman and really important amazing people on this show but no, nothing compared to you!
Sam: I’m not surprised Brett.
Brett: Well thank you. I am shocked and I’m going to do the happy dance now.
Paul: Obviously it was your personality the bought all the people listening but it shows how much people care about digital project management and what a big subject it is and it’s been great to be able to do a whole season dedicated to it. Thank you guys are participating in it and thank you for those of you who have listened to it, I hope you found it useful. Will be back on October 20th with a new season so there is a nice long break this time. But it will be good and it will be exciting and it will be panel based so speak to you then. Goodbye.