 This talk is an autopsy of a failed agile project actually it's an autopsy of about three separate failed agile projects The subtitle to this is death of a thousand cuts because that's how project dies There is no murder weapon. There is no gun smoking gun beside the corpse saying that's what killed the project or very Rarely anyway, what it is is systemic ongoing failure Failure in project governance failure throughout the entire thing so What I'd like to do first is just point out one thing hands up who here uses Twitter Excellent who here is using Twitter in this conference lovely if you prefix Your tweets with it at e-laborn or at least put it somewhere in the tweet It will appear at the bottom of the slides. I will try and use that as a reference To if to make sure that I'm on topic. Okay, so feel free to tweet away So a little bit about who I am and why I'm here talking to you So first of all my background once long ago was a software developer All right web-based systems PHP Python lots of fun my passion out of that is open source So I should do a lot of stuff in the open source community, but I haven't done that for a number of years from there I moved into project management and I'm talking prints to traditional waterfall project management, which From my experience didn't work particularly well from there. I discovered scrum now From there. I discovered that agile is a lot more than scrum scrum doesn't work alone discovered test-driven development discovered XP discovered feature-driven design discovered dsdm RUP so kept working in that space From there I started teaching. I Still actually run training courses in agile and I do agile coaching Available for hire if anyone is interested from there. I actually became a senior executive in a number of organizations direct level and VP level and P level at in the Australian government And a few private sector organizations, which was great fun You get lots of authority you get to do lots of interesting things and from there I learned a lot about how business operates how executives think about projects Which is actually part of what we're going to talk about today in terms of failure because a lot of the failure in a project Is actually from the executive So now I'm doing consulting primarily agile governance and agile business intelligence in a large part so Let's introduce our victim Our victim Mr. A project okay died. Oh the one I've got at the moment was about starting about 2010 Lasted for about nine months cause of death as with all things systemic failure Okay All projects fail Let's introduce our little person And I've just realized one thing that I've turned wireless off on my Laptop, so that's not going to update so I'm actually going to get rid of it. I apologize The wireless here has been very sporadic at best. There we go So Here's our victim Okay, mr. A project I'm going to focus on five different causes of failure Okay, we're going to look at the customer we're going to look at Planning or iteration zero sprint zero We're going to look at the team So the team as a cause of failure We're going to look at infrastructure The supporting infrastructure of the project and your development and test environments I'm going to be using examples with all of these So before we actually get into it. I want to actually give you a little bit of context there was a study done in 2009 I'm sure there's been one done recently, but that's the one that I used when I did this talk that said 68% of Waterfall this was talking prints to specifically projects failed on one of three criteria Quality in terms of features delivered Budget was it delivered under budget and time was it delivered within a time frame that? They said they would so under those three criteria projects failed The same study then looked at agile and looked at agile failure rates on those same three criteria Understanding that yes, okay agile features change and they're developed So but there is still a quality control at the end of a project project still ends even an agile project doesn't last forever, so Did it deliver what the customer wanted? did it Deliver in a time frame the customer was happy for and did it deliver within the budget the customer's happy for paying and under those three criteria 47% of agile projects failed. This was in this study. I think there are they Examined I think it was a hundred or thereabouts agile projects 47% failed now Those are statistics you don't hear bandied about agile of course agile it always works It never fails which is ridiculous as I'm sure we all know I'd like to actually have a little poll in this audience who here Has run an agile project in the past that has failed Couple of you excellent. All right based on the three criteria. I gave you who here and I just Has missed one of those criteria the customer wasn't happy with features Custom it went longer than the customer wanted or it went over the customer's budget Few more hands good. All right, so my definition of failure is of those three criteria Other people will have different definitions. That's semantics and not really relevant so Let's get into the autopsy of this or of these projects The first is the failure of the customer Okay, why and how Can the customer be? instrumental in the non-delivery of what the customer wants now this seems a little bit Contradictory because we're writing a project for a customer. Okay, the cuss. We're doing what the customer wants So how can they be the cause of failure? Well some symptoms lack of engagement the customer not really Understanding what it means to be agile for them They may come from a traditional project background where they give you a scoping document, which may be a hundred pages long But that then turns around and says well actually no you give us five pages and you deal with us every single day Every single week you tell us what you want what changes you want But if they're not going to engage in that level then your project is at risk lack of subject matter experts Okay, so in projects where you have specific domain knowledge Which is required the customer has that domain knowledge and you don't If they're not going to provide people to give you the information. Well, that's going to cause problems Last one is poorly managed expectations and this is a little bit more nebulous in terms of well how can we map how can we measure this as a cause of failure and Because it's qualitative not quantitative in nature. It can be difficult, but it's something that you're going to have to do with With expectations management It is critical that your customer knows What they're getting who here was in the cross-cultural Distributed teams talk earlier today Couple of you. There was a very interesting point that Lena raised in that talk, which was about Communication and making sure that That direct and indirect communication making sure that When you say something to a to the customer that the customer understands What you mean Exactly what will be delivered so their expectations are within the frame of reference If you say, oh, this might be done by Thursday Okay What's the customer going to expect the customer is probably going to expect? Oh, it'll what they said was it'll be done by Thursday Not well it might be done or it might not be done. So it's managing those customer expectations, which is quite difficult So let's actually look at a real case study In 2009 Sorry, I apologize in 2010. I was brought into the Department of Immigration within Australia This is an Australian federal government department to work on a large agile rollout as in rolling out the agile methodology within various various Business sections within that department. This was a great opportunity. There was Executive support The executive said we want agile we want to be more customer focused. That's great We had developer support the developers went look we've failed so many times with this traditional method We want to try something new they like the idea of self-empowered teams. They liked the idea of Being able to deliver small increments rather than spending six months to deliver something that maybe No one uses so we had all that going for us. But what we didn't have was a customer The senior executive who was in charge of this turned around and went Evan We need to run a pilot agile project fair enough. I can understand that here's the project that you're going to do That's the first mistake. Here's the project that you're going to do they He had identified a Whole a gap in business need fair enough, but what he hadn't done is talked to the business owner of That information of those needs. He hadn't talked to them to say well actually hang on a second if I'm gonna do some work for these people. I'm gonna deliver what they want. Maybe better ask them what they want so We had the first meeting with this customer who had only been told two days beforehand that oh We were going to do a project for them. I hadn't given it any thought they didn't really care one way or another They were happy with what they had they they went look what we've got this ad hoc system that gives us all the information I look I suppose you can replace that system with a new one using the enterprise architecture Which okay well that was our project replace legacy systems nothing wrong with that project But the customer wasn't engaged the customer didn't care We tried to get the customer to come into the organization on a so come into the project team or at least nominate a representative a product owner and Eventually after about two weeks. We got them to nominate someone who could dedicate Two hours a week two hours a week as a product owner. It's like okay Well, can we is there someone else who has more so no look? We're really busy. It's a busy time You're just gonna have to work with what you've got. Okay. Okay fine. Let's try try and work in this situation now This was like warning bells have been ringing in my head at this point for the last couple of weeks How like how do we fix this but no it's an exciting opportunity go try and get this working and I didn't do what I should have done. I Should have said no I Should have turned around and said this project is not going to work What I did and unfortunately this is one of my particular personal flaws is I went look let's try and accommodate you Let's try and work with you To give you something it may not be perfect But look, I'm sure we can do something In the end this project this project went on for what we're talking six months or thereabouts got to about the middle of so sorry towards about September October 2010 and Of our these are two week iterations six months of two week iterations So 12 iterations or thereabouts So in those 12 iterations we had released exactly twice No one is shocked by this This is horrible You should be releasing every duration or at least every duration that you possibly can but we released twice And the major cause of this was lack of customer engagement. The customer didn't care They didn't turn up to half the reviews Okay, when we said look you've got to user acceptance testing of this It sat on that in there in there in their backlog for another two iterations So in the end they would have three iterations worth of work to fix our put together You use your acceptance test and then deploy and then we would deploy it. It was rubbish The project will go into fail I am Raghu Indra. Yeah, why do blame agile when you have such a customer? I'm not blaming agile. I'm not saying that Every single cause of failure that I'm going to talk about today Will cause a waterfall project to fail or it will cause a agile project to fail agile is not at fault I'm not blaming agile and please don't think I am These are pitfalls to watch for these issues and concerns that will cause an agile any project but in our context an agile project to fail and lack of customer engagement, let me go back Sorry lack of customer engagement is actually Particularly bad in an agile context Because doesn't in a waterfall project as long as they're there to write the scoping documents or to sign off on the scoping documents at the Beginning of that six-month process doesn't really matter that much if they're there the entire time Like okay, sure. It's nice for them to go. Yes, this milestone is complete But it doesn't and the end it doesn't destroy the project the agile project Failed and I will use that word Absolutely the agile project failed because the customer was not engaged. So this was a specifically agile a Problem to us. This problem is specific to an agile project Okay, but like once again lack of customer engagement in and of a self is not an agile problem. It could be a problem for any project Principles were not followed the way it should have been followed because one of the key principles in agile is customer engagement absolutely, so it's one of the Missing implementations which actually fails a project. Yeah, absolutely, and okay another show of hands who here has implemented agile Exactly as it's meant to be implemented by the book Yeah, exactly That's my point that is exactly my point the because the customer engagement was not there Okay, we had our agile project was doomed to failure. Yeah Just to share our experience It was an enhanced project developed by an enterprise and It was so-called an agile project and I was Kind of a stakeholder in that project and That project didn't release for two years I mean it was not lack of customer engagement, but I mean it was an enhanced project and that project didn't release for two years Absolutely. All right, so let's actually then look at prevention. How do we what are the warning signs of this? Okay, so first of all ask yourself. Do you have the right to product owner? Okay, is your product owner willing to give you 10 hours a week That's just a ballpark figure 10 hours a week a quarter of their working time To work with you on this project help develop the product backlog Help to review and look at the work that the teams have delivered If your product owner is not giving you that time. Well, well, you don't have the right one Ask for a different product owner train the product owner into their Into their role make them understand what they need to do to deliver Well, which actually means the next one customer and product owner training. Sorry. Yes That is actually true the team Sorry What he said was not about the number of hours. It's being available when the team needs them, which is actually absolutely true Two hours is not enough no matter how much the team is going to need them more than that Just developing the product backlog alone is quite a substantial task for the product owner Customer and product owner training if the customer is unaware of their responsibilities Then don't start the project Customer and product owner training should be done first Not done three months into the project when you can when you have the budget for the training It should be one of the before the project starts make sure they understand their responsibilities Actually surprisingly, that's what I do more often than not Internal customers. Yes, you can order them or the boss can say you must go do this training But if you're an agile shop if you're saying look we are going to do this wonderful project for you You're going to be in control of the delivery. However You need to understand what your responsibilities for this up. You're going to pay us half a million dollars to develop something well, surely you can afford half a day to come and learn what you need to do to make sure that delivers right and Quite often that's exactly what I'm doing I'm brought into an organization to coach their product owner to coach their customer in well and we're talking external ones here to say Okay, this is what you have to do Okay, now you're you have the incorrect definition of a customer there. Those are users Okay Yes, they're paying so Here's a question the iPhone who is the customer assuming the iPhone was developed agile II which it wasn't but who is the customer for that? And it's not you there's not you guys who own iPhones. You are not the customer in an agile sense It was probably Steve Jobs to be honest I don't know who in a in Apple would have been considered that customer But somebody is considered has the ownership the responsibility for that and in a retail Context it's generally an internal product owner or product manager Or a program sponsor or some sort of internal resource So yeah customers retail customers are users not customers This is a good list, but I thought it's very important Yeah The first group that needs to be trained in agile is a senior management because without their cooperation in agile Nothing can even start so that is the first group that needs to be trained in agile And that is when after that the customer engagement the product owner training the scum master training start The first group that needs to be trained is the senior management Senior management because that is where most of the agile projects fail because they continue to have the control and command situation senior as having been CTO and having been a director of business intelligence and all sorts of fancy titles which sound much more impressive than they actually usually are Absolutely senior executive Rubbish when it comes to actually understanding what they need to do and I'll actually be talking about that when I talk about the team I'll talk about the senior the role of the senior the senior executive in that regard Now I wouldn't necessarily say senior executive need to be trained first It depends on the context in which you're in Generally, however in an organization which is doing agile The senior executive have to have bought have bought into the agile process before you ever go to a customer So yes, they would normally get trained first, but we're talking out It's outside the scope of the project per se. It's sort of at a higher level Any other question? Oh the last one. Sorry for a go on clear expectations. This goes to what? Leni was talking about early earlier. Sorry, which was make sure when you say We will deliver X that that's what you're going to deliver one thing that I do recommend is have a Line in your product backlog Or sorry in your iteration backlog. So these are the five stories that we've assigned to this product backlog We're going to draw a line about halfway through and say these are the ones we guarantee Or as best as you possibly can in any sort of project that we will deliver in these two weeks these last three Might we will get to them if we can you can watch the progress on the burn down chart But we do not guarantee that we will deliver everything in that iteration backlog And just drawing that line through that iteration backlog. It changes the mindset of the customer So instead you're saying here's the iteration backlog that we will deliver to Here's two iteration backlogs the one that we will deliver and the one that would deliver it if we have time And then just that little those little things about making it very very clear to the customer in terms of what you're going to deliver is It makes all the difference. It really really does Anyone have any questions about customer? Yes Sorry, I missed that so you get Yep, no, so what he asked is the customer is not going to be happy if you slit that backlog is that what you're saying Because the customer is not going to he's not going to get everything But the fact of the matter is the customer may not get everything it is better There's a saying that I always use with my customer under promise over deliver if you over promise and under deliver then you're going to be considered Non-functioning or at worst non-functioning at best incompetent Okay at doing what you do But if you under promise and say we're going to deliver this but actually deliver just a little bit more The customer said hey these guys are wonderful. They're guns like they're doing more than they said they they're doing it better and there's heaps of engineering jokes about doing exactly that but It's the customer will be happier With clarity and clear expectations. They might they may not be happier specifically when you tell them They may actually go. Oh, that's a bit disappointing. I was hoping you could do everything But overall the customer is going to be much much happier with your delivery then if you say oh we can do everything But actually on but the do four out of five stories That's exactly it choosing to make them unhappy now rather than very very unhappy later I mean, it's it's always not so negotiable right? I mean the customers would want you to do something sometimes and It's it's not always in either in the real world so always not so simple as you know I'll do this and this is not I'll do the customer will say that this is what I want you to do Yep, what do you do then I? Describe to my customers. I describe a project or sorry the team as a pipeline And I generally have a whiteboard and I just pull this up and just say look the width of the pipeline is the size of the team We can push through we'll pack this pipeline with work. This is our product backlog You say like if you add something to the front of that list some is going to fall off the end You don't you can't have everything and that's part of that customer training The customer has to understand that when you say like and the beauty of that the beauty of agile is you've got evidence to back You up you've got this wonderful thing called velocity and burn down charts that you can say historically This is how much we can do you can? Tell you'll take your business elsewhere as much as you like if we don't deliver all of this that you ask for But the fact of the matter is all evidence Says this is how much we can do and we cannot do more unless you're willing to pay us more so we can hire more staff Sometimes they'll do that actually sometimes it will say well actually this is so critical bring on a couple more staff for the next five iterations and That can actually work, but you've got to get that Understanding up front to the customer in terms of you can't have everything that you want the customer is not always right You try and give them what they want, but they can't have everything Offshore teams or anything like that what should be delivered, right? Absolutely. Well the product owner is that has it hasn't when the product owner is not the customer They're a representative of the customer. Okay, then they're an interesting situation because the product owner in that regards is Close is more is closer aligned to the team than they are to the customer. There's this some concept that we have of Switching sides a product owner a customer gives you a product owner to say these are this is my Represented to the project, but after a couple of iterations The product owner becomes the teams representative to the customer and and that's actually I think quite important to that the product The product owner is your voice to the customer to manage those expectations And then that's the beauty of a product Absolutely and in fact that goes exactly to the point I was making earlier. Sorry if you didn't hear saying it's all about trust relationship building that trust relationship with the customer But going back to the point which you asked and that is that Undepromising over delivering if you say we can do everything and do and do less than you promise that managing expectations You don't build trust you lose trust so Customer these this is one source of failure and I have had more than one project that has failed Because the customer wasn't engaged or was unhappy with what was delivered because there was not good communication so number two Symptom or not the symptoms. Yeah symptom number two cause number two iteration zero Okay, sprint zero if you if you're a scrum person So so before I just start rambling on everyone here understands what iteration or sprints zero is and what it's for Yep so One of the things that sells agile is this concept of Quick to market you just start now. There is a methodology that doesn't fit under magile under ad under agile Which says just start hacking Don't bother with anything just start writing something eventually you'll get what the customer wants First of all, that's not strictly speaking agile If an organization Does agile because they don't want to do documentation then they're not doing agile properly Once again a lot of the time that I spend with organizations is train them out of bad agile habits So documentation is your friend in agile, but the point is not to do over documentation so one of the flaws in an agile project that That will cause or can cause it to fail and once again. Yes, this will work just as well for non agile projects as well is Not doing a good or proper iteration zero Not planning out the scope or the scale of this project Three symptoms one competing efforts between Strategic and customer work. What do I mean by that? Let's give you an example Another situation I was working with an organization building up there. Once again, this was a business intelligence Agile project quite large. There were about 30 people on the teams teams. So we broke that into four teams and overall look things on Paper were great. We had the right makeup of people. We had good ETL is interface designers and developers this is business objects data architects and analysts SQL people who could write the database schemas and Build the data warehouse. So we had the right mix of people We had the customer the customer was fully on board They gave us the subject matter expects to understand the data is brilliant But what we didn't have was a framework There's Business intelligence and data warehousing is one of those tricky things where you optimize the design for speed Absolutely, you have redundant data Any of you who here knows SQL and database design yep third normal form. Yeah, throw it out the window Data warehouse design nothing to do it like that. It's designed for speed. So this is all great. But when you have Almost a petabyte of data fine, you're going to be able to put it somewhere and What they didn't have was any concept of any Enterprise level structure or schema in which to start So we had a customer What one of the business areas the business intelligence the customers 10 it tends to be internal So they said look we need these series of reports for an annual report the annual report is due in in I think it was like three or four months It wasn't onerous. It was a good project, but the teams had to spend half their time Building the strategic assets rather than delivering to the customer So without that iteration zero plan and the problem is and the problem is we didn't identify Upfront iteration zero was great. We went all right. This is what we'll do is we'll build these schemas and we'll put this populace This information there, but not none developers stopped and said well hang on a second or actually We kind of need to build this stuff first before we can deliver anything the customer wants and Unfortunately, what that meant was those four months that we were meant to deliver something to the customer We delivered nothing to the customer because we were still struggling with the baseline systems Once again a failed agile project poorly defined project scope The customer needs to have an understanding of the end goal the end state it can change Absolutely, it can change But as a project team you need to understand. Well, what are we working towards? I have no idea what that was Is half their funds on selling more? Anyway, um, what was I saying? I've completely lost my train of thought. That's the problem with mobile phones. I lose your train of thought Scope project scope Customer needs to have a clearly defined project scope. They need to know where the project is going to end otherwise, you're just gonna the Work that you do at the beginning may not Be conducive to the work that you'll do at the end a lot of this comes down to that framework again If you're building web-based systems, okay, if you know that they're going to if you know that they want at the end of the day E-commerce as part of their project and this is a actually a real example that this is a project that succeeded If you know they need E-commerce then you can actually build the frameworks and the security in up front Okay, you can build that into the framework that you're delivering into the designs you're building up front Whereas if they don't tell you that this is the end goal and you build something which is designed to just handle a much smaller scope Then well your design is going to be wrong. Now. Yes, we have this wonderful thing called refactoring. We can rebuild and refactoring is a great thing, but You still want to have Enough of a design enough of a concept of what's going to be delivered at the very very end So that you can actually build it in the right direction Is my point The last one is having no success criteria Now success criteria are a concept out of the more traditional project management methodologies In fact the term success criteria comes out of PMBock okay, so success criteria are The criteria for success funny kind of makes perfect sense, but what they are is a set of statements or descriptions of this project Will succeed will deliver what I wanted to deliver if it does this this and this Now once again success criteria can change But if you do not define them up front if you do not say in iteration zero Sorry, if you do not say in iteration zero What those success criteria are? How do you know when to stop? How do you know when you're done? Okay, we have this concept in agile of the definition of done what is done When people say that that what they're talking about stories But what I'm talking about is project when is a project done? Give us a definition of done for the project Needs to be done in any direction zero. Otherwise the project is just going to ramble much like my talk Prevention so how do we actually stop this from occurring? Okay, first of all ensure the framework is available early. Okay, if you're building a web-based system decide okay, we're going to go Drupal or we're going to do Joomla if we're building iPhone apps, okay, are we going to use a particular framework? We're going to build it from scratch business intelligence. Okay, let's design our master data management structure That's going to store this information Okay, are we going to have a service enterprise a service oriented architecture or we're just going to do it ad hoc How is how is this all going to fit together if you have this? Not necessarily built not sorry like completely there but you have the concept of how the architecture and Those frameworks are going to hang together then you're going to be in a much better position down the track I'm not saying you can't make wrong decisions. Absolutely. Sometimes you'll make wrong decisions But if you at least make that attempt you'll be Better off more often than not does that make sense? Yep You want to have a clearly defined end state. Okay, these are this This is this success criteria What is done? and lastly and This is something that People don't always do in a Russian zero which is odd because if you're doing agile or scrum by the book You're meant to and that is put a lot of detail into iterations one and two in iteration zero I've worked in organizations who they'll fin finish iteration zero Okay, and they'll have the product backlog, but it'll all be in low detail And so when it comes time to do iteration one and two then the customers frantically putting in the detail into the first few stories, but What we want is in iteration zero to have a plan A plan that says you we're going to develop these stories. These are the screens. These are the fields This is what should look like. This is what should do and this is what you'll deliver at the end You need to have that plan out front okay, so Any questions about this one? Yes? Yeah, absolutely so For those of you didn't hear Why would you build a framework out front? It's not traceable And adds minimal business value So two things there one is if you don't need a framework, you wouldn't build it Okay, I don't believe that you should use frameworks just because they're there You would use them if they are appropriate to the end state the end goal Okay, secondly, however is if you decide you did need something like a framework then Or some sort of architecture behind the system You would not build the entire framework in iterations one two and three and deliver nothing to the customer You would only deliver those parts of the framework that were relevant to delivery So you still do front-to-back design and delivery, but you need to understand that there may be a framework Under it that will need to be iteratively expanded upon Yeah Architecture design is different design is for a story But architecture is for the whole program. I'm talking like a couple of A4 pages which Yeah, so you you need to know what you're gonna be building from an architectural perspective And we're not talking design in terms of down to the nuts and bolts What we're saying is a couple of A4 pages that describe how everything's gonna talk together and how there's gonna be interface between elements That we're talking half a day's work, and that's agile Okay, the other thing however is a lot of organizations use off-the-shelf frameworks Which can often actually bootstrap a project beyond that point as well Or you've pre-developed an in-house framework that you reuse and reuse Which happens actually more often than not building a framework from scratch for a project You'd have to really sit back and go the investment in this framework for this project is going to be this amount of man hours T-shirt size ballpark figures, whatever you want to do Is it actually going to is that going to give value to the customer the framework will never give value? But the savings that a framework can give will give secondary value by making things faster So that's why you'd always as you wouldn't necessarily use a framework if it was not necessary absolutely, so Yeah, how can you even think of if I have to build a trading system How can you build it in pieces? Okay It and I'm not saying that you know you you can't but you're yes You're an entire mindset of what you called an iteration to to be able to bring anything to life Would would be much bigger than few days or weeks, right? The I've done a lot of work in the financial industry as well and the financial firms I've worked with tend to have a pre-existing Frameworks or architecture that all their fight their fight their financial management software sits upon Generally, it's completely customized like Goldman Sachs has completely weird and customized one That they've built entirely from scratch and it just boggles the mind the amount of effort of money that they've spent on this But the point is they hooking new components in because these are built to be modular does not add Significant and we're talking a couple of hours per iteration rather than a couple of days per duration It does not add Significantly more time to development than if they were just doing it from scratch Now so without the framework behind it the advantage however is then down the track once they're three six twelve months down the track new stories are Significantly faster bolt-on then if they did you want to say something? Yeah, so yeah, I'll move on and we can have a conversation afterwards So the team Where can the team fall over now sadly and I have to admit the team is generally where projects fail Hey, the teams wonderful things. We try and empower them. We're trying to make them so that they're all powerful All knowing and can do everything but often doesn't work in practice. So what about symptoms? So we're still talking our autopsy so One of the causes of death the team. What are the symptoms? First of all, who here works on projects which are chronically understaffed Yes, lovely everybody That's a risk absolutely that's a risk okay There was a project that I was working on I actually know sorry go to the second one missing specific skills as a project I was working on and there was a An organizational chart for this project We needed these types of people went to market for as many as we could that the project didn't have recruit to them, but there was one skill set interface designer that we could not fill and Generally most customers what do they see they see the interface and so we we had all these horrible mock-up This is a web-based system and I tell you a lot of web developers really aren't very good at designing things so we had these horrible mock-ups that we've done they ended up going into production or at least deployed to the customer for review and and final acceptance that we could not make any better because the skills were not available within the team and This the customer went no, this looks horrible. I do not want to accept this. I will not accept this Functionally it did everything the customer wanted it to do. It was functionally perfect Okay, it passed the Continuous integration environment or the unit tests were written the documentation was we had technical rights We had documentation which is amazing for an IT project in and of itself but what we didn't have was a good interface designer who could actually make it look good and that is what the customer wanted and So this project we actually the project itself didn't actually fail because we actually did eventually get Interfaces designer actually had to subcontract to another firm to actually do the interface design They weren't agile. So it was all a bit of a pain But we did eventually manage to get that those interface designs put on and bolted on top of the whole project but this was a significant risk to delivery and Something that you need to understand Well, do I have all the skills to deliver what the customer wants and you can't tell the customer? We're ready to go unless you have all the skills and enough people to deliver Competing priorities now. This is a tough one. Especially when your project is internal so in your teams your staff Who whose staff spend 100% of their working time on the project and? Who's staff spends are 80% of the time on the working project and then 20% of their time doing maintenance or Working on other systems doing business plan. So I doing business tenders Trying to get the next contract that sort of thing okay, quite a lot of organizations unfortunately have these split priorities and Those can detract unless your plan unless your plan as in the iteration plan goes well This guy here Joe well, he's going to be working on this project 50% of the time for the next two weeks because he's Going to go and write a tender unless you're good enough to actually go well actually hang on a second look You're now spending a lot more than 50% of the time on this tender. Yes, it's important But we told the customer we're going to deliver these her features and you're holding up the rest of the team You've got to keep those competing priorities under control and sometimes it's not possible sometimes yes That's more important. Sometimes people go off sick and you can't deliver But that's where the whole under promising over delivering comes in you don't tell them you can do everything you tell them you can do This is guaranteed and this is possible So if someone does get sick or gets pulled off to write a tender. Well, okay, we still deliver enough for the customers happy Low team morale Now there's a saying which I use a lot which is success breeds success Okay, if you have a successful team you have a happy team you have a team that is content with what they're doing What you don't have is if you have a team that is failing just making sure my time is on the stop if you have a team that is failing then That team is going to have low morale and you and that unfortunately is going to drag the rest of the project down with it The project may be going perfectly, but they've just had these issues that they're trying to deal with in terms of previous projects And okay. Yes, so this one's going fine, but unless you can actually build it up. It's not going to work So prevention first of all recruit for an agile team don't need to recruit He's a software developer great go. Well, you're a software developer, but can you work in an agile environment? Yes, no The answer is no don't hire them. So your recruitment strategy changes from do they have the skills? To do they have the skills and do that the personality? Focus on the developing the team in viral empowerment the team needs to be empowered to do the work and if your teams aren't then well a you're not agile and be it's gonna fail and If you have features that if you have missing skills in your team Then tell the customer or we can't do that for you. Don't say oh look we'll make an attempt at a interface Say look we're gonna focus for the next two iterations on Back-end infrastructure the administration screens. Yes, it's low on your priority list But we don't have the skills to do what you what's on the top of your priority list So actually work with the customer engage with the customer to go. These are the skills. This is what we can do well for you The rest of it. Yes, it's high priority and we'll get to it as soon as we possibly can Infrastructure and the last two I can get through fairly quickly because they're fairly they're very similar okay underlying underdeveloped baseline Architecture already spoken a lot about that so I won't go into detail Missing documentation. Oh, this is a pain that I'm sure all of us have felt quite often. Okay, if you're underlying infrastructure That does not have to the sufficient information to actually if your teams to deliver then you're in trouble Unstable upstream systems and data This is important in things like business intelligence Any sort of server-based environment if you're if what is if what your project is sits on or Utilizes is unstable Then you are compromising your delivery You'll tell the customer. Oh, we'll give you this information or we'll build you this functionality but for no fault of your own an upstream System or an upstream information Causes you to fail that delivery. Does the customer care that it was the upstream system? No, the customer cares that you didn't deliver what you said you would So you need to make sure those upstream systems are stable. I won't this is all fairly straightforward stuff So I'll go to that last one dev and test environments so Who here has a wonderful development environment and a wonderful test environment that does everything that they wanted to do I Nobody what a surprise I Gen I tend to recommend that developers control their own development environment I've worked in organizations where the developers is like, this is your dev environment. This is what you work on The developers look I prefer this idea over eclipse or I prefer to write my To do profiling using this tool let them actually Build their own dev environment Okay, give them that control Like wise testing Automated testing unit J units is not necessarily always enough okay, look at all made profiling tools look at debuggers and Things that check for memory leaks beyond just your J unit and cruise control So actually build up the framework of tech your test suite framework beyond just what you may have now and That will help you identify Issues all right in a business intelligence context. I'll use this as an example because this was just last year as in literally in December we deployed a system we had a 10 percent test environment with 10 percent of the production data size worked fine we could run the reports and Produce the features of the customer wanted in about a third of a second. We push that to production Thinking oh, it'll take like maybe well, let's scale it out. Oh, it'll take maybe two three seconds. That's acceptable No, it took 30 minutes and That was unacceptable the customer didn't want that it actually brought the whole system Growing to a halt while I was trying to process this data. We thought well hang on No, this doesn't make sense, but it does it was it was an end to the four I think complexity problem in terms of like really really exponentially difficult as data got big so It exponentially got Slower so we if we had had proper profiling tools. We could have actually picked that up earlier Okay, now. This wasn't a failed project. This was a failed iteration But still the customer wasn't very happy with us the senior executive weren't happy with us So it was something that we had to move on all right I've just answered those same questions So I had to run through the last bit in a bit quickly. I got logged down in a couple of questions So well, you're looking for personality and I can't tell you the answer to that what you need I don't mean you want to recruit someone who has done agile before that. That's not the right approach But you need to go does this person have the ability to cope with change? do they have the ability to work in a collaborative environment with the team I currently have and Will change from team to team you'll have one team that has a set of personality traits and a second team with a different So personality traits you're actually going to you're recruiting for a team not for a Project and that's them. I can't give you an answer to that because It's up to you Anyone else someone over No, all right. Thank you very much If anyone has any questions They can email me. I'll put the link to these slides up on Twitter and wherever else I can find to upload them Otherwise feel free to email me or come and talk to me afterwards. Thank you. Thank you very much