By Michael A. Velez, Managing Director of Castellan Systems

Transcription

1 1 By Michael A. Velez, Managing Director of Castellan Systems Let me start by giving a little background of myself. I ve been in IT for over 40 years; I cut my first line of code in January 1978! All I wanted back then was to write computer software but at that time there was no natural progression path, at least where I worked, that allowed me to progress in seniority while remaining in a technical role. The more experienced I became the more management duties I was allocated. First as a technical team leader and eventually to project manager; stopping on the way as a support manager. In the end, I ended in Project Management for 2 thirds of my professional life so far. In that time, I have worked in over 100 projects with only 3 clear failed projects and 2 cancelled ones. So, I believe I m well placed to look at the argument between Agile and, what its proponents call, traditional project management as I ve looked at projects from all three sides. So, let s start. The proponents of Agile talk about it being an alternative to traditional Waterfall Project Management ; here is the first fallacy. Waterfall is not Project Management; it s a Product Development approach, technique or methodology but it s not Project Management. So, if Agile is an alternative to Waterfall, then Agile is not Project Management either and its use should not lead to the exclusion of proper Project Management processes. In 2001, according to Wikipedia, seventeen software developers met at a resort in Snowbird, Utah to discuss lightweight development methods, among others Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they published the Manifesto for Agile Software Development. Please pay attention to the statement above. seventeen software developers came up with this Agile concept; not a single Project Management professional among them. In this manifesto the very first sentence says We are uncovering better ways of developing software by doing it and helping others do it. So they were looking for a different way to build software, or the product, and not a different way of managing the project. Now let s look at what a project is. A project is a temporary endeavour designed to produce a unique product, service or result with a defined beginning and end (usually time-constrained, and often constrained by funding or staffing) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.

2 2 Project management is the practice of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time. There are three constraints or dimensions faced in every project: Scope, Time, and Cost. They are a part of every project and though they can be limiting, when properly managed they should not affect a successful project outcome. These are often characterised in the Project Management Triangle, shown on the left. So, a project is about delivering a Scope (What), within in a Timeframe or Schedule (When) for a specified Cost (How Much) to a required level of Quality. The software that Waterfall or Agile may produce will form all or just part of the What; Agile processes or frameworks address the approach to build this What but do little or nothing about When and How Much. They seem to assume that if you get a coordinated team of technologists and end-users working together in a very motivated arrangement that those other 2 dimensions will kind of happen; they know what they are doing! There appears to be little concern within the Agile world of managing costs. SCRUM, for example, only has 3 project roles: Product Owner, SCRUM Master and SCRUM Team. None of those roles covers any of the responsibilities for managing schedule and budget to any extend. SCRUM does have a mention of a budget being formulated and occasionally monitored by the Product Owner and SCRUM Master; but this budget is formulated when the Project Vision is defined and at that stage there is no chance of getting a realistic project costs forecast. This budget appears to be more like how much the client has available to spend. There is a real danger in this. If the budget is determined by the amount of money the client has available, they may not know that they can t afford to pay for the product they wish with the money they have until all or a significant portion of that budget has been spent. I ve worked in many projects that the client realised that they had no business case for what they wanted before any code has been cut and therefore the wasted expenditure is minimised. As I said earlier, the software being built may only form part of the What or scope of the project. So how is the rest of this scope supposed to be built? How is the coordination of these different delivery streams meant to be done? The answer is simple: Project Management processes through a Project Manager. What the Agile proponents call traditional Project Management does not actually specify that you first gather requirements, then design the product, then build it, followed by testing before deploying. That s the Product Development approach! Project Management is about ensuring that what needs to be done is done within the timeframe and budget agreed to. Simple! I worked on many projects where no software has been produced or modified; they have been about modifying a business process or executing a set of business processes that occur at a specific point in time. An example from a recent engagement would be generating the Annual Statements for all clients of a Financial Services organisation. The software

3 3 was already in existence; all we had to do was to validate the data for correctness, test the execution of the process to determine a timetable for execution and then execute that timetable. Another concern I have with Agile is the rather disregard for the contract. The impression given is that Agile works in an environment where there are no commercial realities. The client will come up with the money to pay for each sprint whenever the costs of that sprint are determined. In a real commercial environment where the client is external to the delivery organisation, there will always be a contract in place that establishes the scope, timeframe and budget and the delivery organisation needs to manage the project with in those parameters. Doesn t that sound familiar? Is that what Project Management is all about? It isn t Waterfall or Agile; they are just concerned with building the scope or product (or part of it). Another statement is the Manifesto for Agile Software Development is that they value Customer collaboration over contract negotiation. Of course, as software developers they shouldn t need to worry about contract negotiation but that doesn t mean that there is no contract and that there are no such constraints that need to be managed. A client needs to make a business case to get the funding to proceed with a project. In this business case they look at the costs and benefits, or Cost Benefit Analysis (CBA), to see if the expenditure is justifiable. The client wants to get a return for their investment. I had a project that once we costed it, following completion of the requirements phase, the client realised that the costs were far greater than the benefits they were expecting. The project got cancelled after spending just a few thousand dollars rather than a few tens or hundred or millions of dollars. To put all of this into perspective, let s look at a real-life example that we may all had faced, building a house. Can a house be built using Agile? Can a project to build a house be managed exclusively by Agile with no traditional Project Management involved? Traditionally if you are going to build a house you get a builder to draw up a design or blueprint and produce a detailed costing so that you can go to your bank and get a loan to pay for the house. But can this be done another way? The Agile way? I guess if we were to build a house the Agile way it would mean essentially build one room at a time. The builder will design and cost a room; you will then take that estimate to your bank and ask the nice bank manager for a loan to build that one room. Once the room has been completed, you and your family could move into that room while the builder moves to build the second room. The process is then repeated for that room and subsequent rooms until the whole house has been completed. But in the real world how practical is this approach? You wouldn t know the total cost of your new house until the builder begins the last room; could you actually afford this house? How would your bank manager react if you go to asking for a loan room by room? Would he be happy to accommodate you or would he laugh in your face and show you where the door is reminding you not to let it hit you on the way out? Wouldn t there be concerns as to decisions being made in the early sprints that will affect or even make impossible building

4 4 subsequent rooms? Could these decisions, made in isolation, lead to increase costs in the end? Not too far from where I live there is a famous "half house"; obviously this was built using an Agile approach and they ran out of budget half way. All of these are valid questions which raise concerns with an Agile approach especially if no real Project Management processes are applied. Now let me give you an example from my own experiences. I was working for a large multi-national IT Services company delivering projects to a Steelworks in Australia. This particular project involved build about 120 production report generating modules. They were meant to replace some reports coded some years earlier using PL/I, SAS and even COBOL; as well as that, there was a large number of such reports built by the endusers using tools like Microsoft Excel and Access. Combined they used over 300 business rules generated using data on the production database. This look perfect for an Agile approach and while we didn t officially call it that, that s the approach that we chose. We selected the top 10 priority reports (user stories) and the business rules that were required to build them. We completed a very high-level design and then progressed into effectively sprints to delivered each report. The idea was simple: build a report, put into production and move to the next one. The problem that we encountered was that as we were in effect designing each business rule on the fly, we couldn t nail the Product Owner into an agreed algorithm. Some seemed to change on a daily basis. By the time I left that organisation a year later, we believed we were close to deploying that first report after 3 months of coding; even though one of the business rules had been coded 20 times or more at that stage. A year later I ran into my old Tech Lead at a family function (his cousin is married to one of my nephews); he told me that they had finally implemented that first report, 3 months after I left, but it wasn t officially in production. It was in some sort of parallel state with the Product Owner still continuing to change business rules on a weekly basis. I think we can all predict how this ended; the project got cancelled after 2 years, lots of dollars spent and only one report sort of delivered. Agile projects can fail to deliver just as easily as Waterfall projects. This agility can add another dimension for failure. Another fallacy that the Agile proponents make about traditional Project Management is to do with the volume of documentation produced. Once again this is not a requirement of Project Management but of Product Development. Project Management will work happily alongside a product delivery approach no matter how much product delivery documentation it produces. The need for the documentation is a requirement of the Product Development approach so that information is passed on about what s being built and how it s being built. But if you have a team working in close quarters in small sprints, then the level of written documentation doesn t need to be excessive. That is until you consider what happens after deployment. The development team will build, test and deploy the system; they may even look after it for a warranty period. But then they would want to handed over to a support team and move on to the next project. So, let s try and understand what a Support Team is and does. A Support Team is a group of professionals that make sure that the lights are on and keep working. They keep the system running (lights on) and functioning as required (keep working); they also make enhancements, improvements and repairs (change to new types of light bulbs). But how can they do this? They need to know lots of stuff about the product: what it s meant to do, how it s meant to do it, how it was built and, most importantly, how to test it to prove that it s actually doing that. Usually these Support Team members haven t had or had very minimal

5 5 involvement in the project. It s the documentation that they are provided by the Development Team that helps them get the knowledge they need. While the Development Team may do some handover presentations, the Support team may not need to touch the new product for some time and therefore the information verbally provided may be a distant memory. Now let me give you two examples from my personal experience. The first one involves a project I was managing while working on those projects for that Steelworks that I mentioned earlier. We were building a large amount of new functionality to a set of existing systems. One of them had been built about 10 years earlier and all of the developers had long left the organisation. The current supporter was the 6 th person assigned this role over the years; but as the system seemed to work flawlessly, he hadn t had any need to even look at the code. But now we wanted to make changes and we couldn t find any documentation or anyone that knew anything about the system. In the end this supporter had to seat with the key end-user and effectively reverse engineer the system to workout the business rules. Then and only then could we proceed to make our changes. As you can imagine, this added considerable costs to the project. The second example is more recent. About three years ago I was handed over a project by another project manager who was going on leave for several weeks. Most of the work had been completed and all I needed to manage was the deployment, warranty and handover. This seemed fairly clear and simple, it wasn t. While we did encounter some issues during the first 2 tasks, handover was the biggest headache. Out of a team of about 15 developers that had worked on the project, within 3 weeks of deployment 12 had left the organisation. The other 3 and I were left with the issue of handover. Obviously, the Support Manager and team wanted detailed documentation to be able to support this very complex system. I was lucky that some of the departing team members had completed their documentation; but unfortunately, the other 3 had to fill in the gaps the best that they could. I spent a considerable amount of time searching through file servers for any document that could help us. In the end handover lasted longer that the actual warranty period. So, the moral of this story is that while documentation may be useful during the development of any product, it s invaluable afterwards. But this is something that software developers don t see; they find it hard to see beyond their noses. It s all about what s important to them. They find it hard to see the big picture. It is only after you have had to function in the different sides of product delivery that you can appreciate why things are indeed required. Remember. I was and still am a software developer and have suffered from this type of blindness. Another area that concerns me about Agile is its limitations of application. To me it seems best suited to internal projects using funny money or with clients who have little or no limitations on funding; they need to be flexible as the total costs of the project may not be known until close to the end. Also, it seems to be better suited to a green field site. This business of building a bit and then delivering, works well if there is nothing already there. This can better be explained by another

6 6 example from my past; this was my first failed project but by that stage I had been working on projects for almost 15 years. We were working on a project to replace a large existing system; this was back when I was working on these Steelworks projects. Since the system was to manage a production line with multiple stations and the client had budgeting limitations, it seemed perfect for building station by station using the annual funding available to the client. The only problem was that there was an existing system and the production line still needed to function during this staged migration. You see, to deploy the functionality for the first station we needed to also build all of this other supporting functionality that by itself gave the client nothing but without it made the first stage useless. Therefore, the first stage was larger than what we would had liked. Also, this first station in the new system needed to talk to the second station on the old system; this meant building throw-away functionality just to make stage 1 work. When we then proceeded to build station 2 we had to throw away this additional functionality and build new throw-away functionality so that the new station 2 could talk to station 3, and so on. In the end the amount of software that was needed to be built was practically double at more than twice the total cost. After spending $2.5M the project was cancelled and nothing was put into operation. I had left the project before completion of the first station; I had been warning the client that this approach wasn t going to work and all I had achieved was to ruin my credibility with them. So, I voluntarily stepped aside to let someone else with a more positive mind set take over. At the time it put a black mark against my name which was quickly removed when the whole thing went belly-up for the reasons I had been highlighting all along. My reputation was cleaned up even more when I ran into one of the end-users and told me that may be what I had been warning them about for so long was correct. Just a shame they had to pay such an expensive price to learn what it was so obvious to me in the early stages. For myself, I ended up taking 2 years off Project Management and went back to coding just to recover from the experience. Agile proponents also quote statistics about poor delivery with traditional Waterfall Project Management. I ve already spoken of the error in this terminology. Yes Waterfall, a Product Development approach and not Project Management, can fail to deliver a successful product. But that can happen under any approach as I highlighted earlier in an example from my past. I have managed many projects in my professional life; well over 100. In most cases we either used Waterfall or some iterative hybrid model. I ve only had 3 clear failed projects, which I think it s a great statistic. I m not highlighting myself as some sort of Project guru that never fails; in fact, many of the other Project Managers that I ve worked with have had similar results because they applied strong Project Management principles and processes. So, I don t know who they ve been talking to about these statistics; it hasn t been me or my colleagues. I whole heartedly agree with them that Agile can best deliver in a changing environment; but I think I have also shown that this changing environment can lead to total failure due to costs and schedule overblow leading to invalidating the whole business case that kicked off the project in the first place. It s interesting to note that the term business case appears only once in the entire 379 pages of The Guide to the SCRUM Body of Knowledge. In the Third Edition it can be found at the bottom of page 70 where it states Business justification for a project is typically analysed and confirmed by the Product Owner. It is documented and presented in the form of a project Business Case prior to Initiate phase But unfortunately, at that stage the cost of the proposed solution is not known and therefore a proper Cost/Benefit analysis cannot be performed properly. There is more to justifying whether a project should be approved than that derived from a technical solution. There have been many instances in my professional life, especially while I was working in the Financial Services industry, that fixing something by manual work-arounds provided a better business case than writing a technical/software solution. The cost of the latter where far greater than the cost of the former.

7 7 Let s be clear, I m not anti-agile. I have used it in the past and in fact we use our own version of it at Castellan Systems. What I m anti is the idea that if you re using Agile or any of its frameworks like SCRUM, Project Management is superfluous. The actual fact is that Project Management is the only reason why Agile actually works. It s the fact that a Project Manager is looking after all of the contractual, reporting, budgeting, timeframe and issues that it allows the team to concentrate on simply writing software. I have seen recently Agile being applied to projects by others; but in every single case there was a Project Manager managing the project following traditional Project Management processes. In most cases the Project Manager was also the SCRUM Master but not because the SCRUM Master was allocated the project management tasks; but because the Project Manager was a qualified SCRUM Master and he knew how to balance the two disciplines. In those instances, the projects were well managed while delivering their newly built software in an Agile manner; all other items in the scope were delivered in a traditional manner. In the end you couldn t really tell what was delivered agilely and what was delivered traditionally ; Project Management made sure that no matter what the delivery approach was, they were delivered according to the contract requirements. And in the end, that s what a project is all about: delivering the specified scope within the agreed timeframe and budget for the required quality. The main argument in support of Agile by Agile proponents is that Agile can be flexible and doesn t lock clients into a set of requirements that may change as their business changes or is impacted by their environment. That s true but it also opens the door for cost and time blow-outs due to scope creep or failure to deliver key requirements due to the consumption of the available budget in the earlier stages due to these changing requirements due to what is known in the industry as scope creep. If you are working under a set of contractual arrangements, this can be a very distinct possibility and scope creep can kill your project and yours and your organisation s reputation. The client has asked their Management for a budget to deliver the project; their whole business case is based around this budget; otherwise the business case may fall apart. While the end-user that your team is working with may love this ability to change if they get it wrong, the person in their organisation that is responsible to their Management for the project won t. Have you ever had to go back to Management and ask for more money because you didn t understand your requirements to start with and you keep changing them? I had to do it twice in that failed project at the Steelworks that I mentioned earlier; it wasn t fun. In conclusion, there is a place for the Waterfall and Agile Product Development approaches or models in projects. It all depends on what you are building. Would you really build a house or a new car or even Microsoft Word using Agile? You may use some of the Agile concepts but in the end, it would be a Big Bang release. Can you imagine if Microsoft s first release of Word would only have a few of its features? Wouldn t that just be WordPad? But for all of their advantages and disadvantages, neither Waterfall or Agile are Project Management. So if you have anyone use the expression traditional Waterfall Project Management, it s a giant red flag telling you that that person knows nothing really about Project Management.

8 8 So, let me leave you with this thought... This article was first published in in March Its author is Castellan Systems Managing Director who has 40 years experience in the IT industry working for several large, multi-national corporations. He has worked on or managed well over 100 projects and he can count the failures with the fingers of one hand.