Mike: Welcome to today's webinar, "Nine Rules for Agile Project Success." I'm Mike Jones, your host. Today's session is the second in a series of webinars on IT productivity. Today, we'll focus on using Agile processes to develop custom applications. Our first webinar in the series featured John Rhymer of Forrester Research where he shared his insights into a new class of application development environment that Forrester calls the new productivity platforms. You can actually download the full Forrester report from outsystems.com, if you'd like to learn more. For today's session we've asked Jeff Newlin who's GM of OutSystems North America to share nine key rules for enterprise Agile success. These rules are based on experience gained by OutSystems' own professional services team as they have helped customers implement Agile practices in their enterprise. IT shops. Hi, Jeff.
Jeff: Good morning, Mike.
Mike: To keep us honest, we've also invited Dave Thomas who's the CEO of Bedarra Research and the managing director of Object Mentor, which is a company that specializes in the training and deployment of Agile and object oriented software development methodologies. By the way, Dave was also founding director of Agile Alliance. Welcome, Dave
Dave: Good morning.
Mike: So now that we've got everyone assembled, we're going to pass controls over to Jeff and we'll begin the show. Ladies and gentlemen, Jeff Newlin.
Jeff: Hey, thanks a lot, Mike, and it's really great to be on the panel today with you and with Dave. I think we've got some really good points to share on the nine rules for Agile. One of the things to start with before we delve into what the rules are is some ideas around why Agile came about. That really evolved because of the failure of big IT projects. Although no one sets out to fail, too often these larger IT enterprise projects don't achieve the success that the business or the IT team had hoped they would. This is due to lots of reasons. Not really clear on what you're trying to create in the first place. Although businesses are really excited and fired up as the project starts, they lose momentum and participation over the life of the project. At times, there's really not a formal process in how you're going about the project. The opposite can occur as well where you've got way too much process and you're focused more on the project and the process itself and not so much on the outcome, which is building great applications. Lack of scope control is one of the most common. Although, commonly it's thought of that IT spends most of the time saying no to the users as what they can't have, a lot of times in the desire to accommodate what the business is trying to accomplish what the user's need to scope continues to spin out of control. Things do happen, the world changes. If you think about a project that is going to last for several months, potentially even to more than a year the business can change, the world can change. Key drivers, priorities, MMA, lots of stuff can occur over the length of a large complex IT project. The poor architecture. Architectural changes can occur, you just do the design incorrectly from the outset and without the ability to flexibly change the architecture as you move forward towards production, it can cause long-term delay. There are other unforeseen surprises that can occur. Integrations that weren't expected. Integrations that were too complex. are some of the more common ones that it can cause. And size. Simply just too big to succeed. Commonly heard in the U.S. financial market places "too big to fail." But too big to succeed, was the team too big, the scope too large, too many integrations, too many stakeholders, cooks in the kitchen. It just gets out of control from the size perspective. What that leads to, there's been several studies that you can look at over time. But they all come back to the same percentages on these large IT projects. About 25% of them succeed in the eyes of the business and IT. About 25% of them fail. They're not on time, they're not on budget, or they're not delivering the business value that was set out to be. And then there's about 50% that you can term as challenged. They drift in between the two as to whether or not they were kind of a success, or kind of a failure. Most of the projects really don't end up doing what you want them to do, which is deliver a great application to serve the business.
Mike: We've all heard about these IT project failures for a long time, and I thought that this would be a good place to interject and ask Dave to share some of his insights as someone who spends a considerable amount of time consulting with heads of IT departments. So, Dave, are you still seeing this desire for big application development projects and seeing them fail?
Dave: I think that there are always ambitious things that organizations try to do and the counts report on all these issues. There's good news in it in the sense that the percentages of success are higher that basically shows that most of the failures are still in big projects and definitely, I think, the big driver for things like Agile, is to try and take bit sized chunks. The secret to delivering a big project is to deliver a lot of small ones.
Mike: All right.
Jeff: Thanks, Dave. What is discussed in Dave's comments, too, Agile came about in order to help get into these bite sized chunks and provide a better way that you can deliver value via these applications to the business. When we take a look at the series that we're involved in, the first one focused on how high productivity platforms can help in delivering systems faster and more on target. When you combine these high productivity platforms with an Agile approach, it helps you to do a number of things. Closing the scope, the idea behind these platforms is that you can make changes more quickly, you can be more flexible and you can keep the scope open a little bit longer because the tool will help you change things in a timeframe that you wouldn't be able to using traditional coding methods. It can also help you overcome a poor architecture, similar to keeping the scope open. If you're using a good productivity platform, it's going to help you to avoid making poor architectural decisions in the first place. If they do occur the tools are usually nimble enough to help you make those changes. The tools actually help you overcome the concept of the world changing. The projects Agile with these tools really help you do projects much faster and can compress the time of a typical project. Even with Agile in the standard methods with high productivity, it can be two to four times faster if not more. Also, these platforms help you communicate and to keep the team size small to keep the change in communication much more direct. So when you see Agile with the high productivity platforms, you really have a much higher degree of success.
Mike: So hold on a second, Jeff. If I remember correctly, the Agile manifesto states "individuals and interactions over processes and tools." So I thought we'd ask Dave as an early Agile practitioner what are you seeing in enterprise IT shops? Are they adopting productivity tools, and can they really help overcome some of these key challenges that Jeff just highlighted?
Dave: Well, clearly it is an important thing to have persons understand the basic practices like driving XP and so on. But in order to really get transparent in the organization, to make it an efficient Lean software organization, you have to actually look at your tool chain. Basically, Lean was originally developed modernizing your factory. What you're really talking about doing with Agile is streamlining your software factory or your software development. It's very, very important if you want to support things like changing to suit the customer best practices like aggressive refactoring or GED test driven development, you really can't do this with tools. The technology makes a big difference. Most of the Agile practices came out of technologies, for example, like Smalltalk, and then got applied to Java, C#. The reality is that at lift time we're doing something in Smalltalk and Ruby is a lot different than lift time if we're doing it in C# and much less different than doing it in C++. So the tool change is very, very important to enabling people to be responsive to customer's needs. If you get very deep in the kind of system tools, like Java and C#, once you've got a fairly substantial code base, it's pretty hard to be responsive to the customer if you're working at a very low level. So even though the basic tools provided by the manager selecting IDs and so on are helpful, the reality is that you really need tools beyond that both at the front end and at the back end to automate testing and delivery. So it's true that the practices are really important and the first thing, but like anything else once you've trained everybody in the plant, you have to be able to put some new technology in there to stream behind the plant.
Mike: All right.
Jeff: Great points, Dave. Yeah, thanks so much. All the pieces have to come together. The approach you're taking, the team that's involved, and then the tools that you have to be successful. But believe it or not with the great tool chain, as Dave discussed, and with the adoption of Agile methods, Agile projects can fail and they do fail. The remainder of the discussion today is to talk about nine rules that OutSystems has learned over the ten plus years we've been developing applications using high productivity tools and Agile methods. So the rules that we're going to be discussing are based on almost 1,000 projects that we've completed. Over time we've had our successes and our failures, and we've learned a lot. We think that these nine rules can be very helpful so that you don't encounter the same challenges that we have had and learned over these years. I cheated a little bit and before we jump into rule one, there's actually rule zero. It's almost so fundamental that you don't have to call it out. But if you don't mention it, it can still lose sight of the whole premise behind the customer collaboration that's so important within Agile. You need to be one team. You need to avoid the us versus them. The way that we have approached this over time is stepping away from some traditional approaches that are done within Agile and looking at an ideal team that's two-headed. What we mean by that is you've got members of the team that are responsible for the overall engagement and success, overseeing how the project is going to meet the needs of the business, bringing the value that wants to be done. Then there's also the delivery team, which is, if you think about it, the traditional IT side of the project. So really important within our world are two roles called engagement managers and delivery managers. An engagement manager is really part project manager, part business analyst. And a lot of times part mediator and referee to try to keep everybody working toward the common goal of working software and a great application. The delivery team, lead by deliver manager, the DM, is what we would look at as the real Scrum master and not only are they there to make sure that you're moving forward and you're addressing the backlog and you're getting the releases complete and then also be able to lead and be able to guide the team and work through difficult situations that are going to occur. Another thing that we think is important is rather than building a team where everyone is equal in skill and capability, which you hear with Agile approaches at times, we think it's important that you have the team built with senior and more junior members of the team. The senior members can mentor, they can help the team come along and it will help you evolve your organization in how you approach and deliver your projects. When we look at it, we just don't think that one Scrum master is really enough. It takes this two-headed team approach in order to make an Agile project successful. As we look at the rules, we'll start with rule number one, is to have a vision for the application. It's important that everyone is seeing the same thing. If you can look at that, I don't know how many of you see a challenge and how many of you see two faces opposed to one another. But the idea is that you need to create a common vision for the application and the project. We've been successful by creating something we call a vision document. The goal of that document is to describe why you're doing that application. From a business perspective, you'd think that IT gets what you're doing. Understands what the ultimate goal is of the application or the system. But too often that isn't the case. The vision document helps everyone understand whether you're trying to make more money, save money, compliance issues, approach a new market, launch a new product, whatever that might be. Everyone needs to know what the ultimate goal is and why you're doing it. The vision document also helps us define who is going to use it. We define those in user profiles. By understanding who is going to use it in those profiles, you really start to get a sense of the prioritization of the features and capabilities that the system is going to need to have. It's also good upfront to document what are the top 10, 15, 20 most important user stories and use those to help you determine what those profiles are for the users. Then we create a glossary. We pull all those together, key terms, meanings, so that everyone remains on the same page. Further into the project you can even start to require that things that are being built as features or put into the user interface have to be defined in the glossary before they're allowed to be brought out into the application itself. So the ultimate goal behind the vision is to make sure you know where you're headed and help you make sure that you're going to deliver a great app when you're done. Rule number two, enforcing business participation. We look at this as really the golden rule, and it's almost like rule zero, well, of course, you need to have business participation to have a successful project or a successful application. But it's how the business engages that's so important and really enforcing and requiring that participation and making sure it doesn't lag over the life of the project. One way to do that is to help to remove the IT buffers. Too often, IT will decide they want to speak for the users during the project. They're the hub of all the systems and all the things that help a business operate at times they take liberties and want to speak on behalf of the users. It's very important that you get the users involved. Once they're involved, you can't let them go. You can't let the users decide, "Well, I'm too busy to attend the sprints." Or "I'm too busy to participate in the analysis session." Or "I'm too busy to really complete good user stories that we need to have in place." You really need to have the tone set early in the project that the business users need to remain engaged, even if you have to do it to emphasize escalation to management should that not be happening. The other thing is even when they are engaged at times those that are engaged are not empowered to make the decisions. They don't feel comfortable making decisions. They've never been put into a situation where they've had to make decisions that are going to influence how an application actually is built and actually is going to be deployed. So you have to make sure that they understand that they are truly empowered and then reinforce that by accepting and moving forward with the decisions the team makes. The last one is one of the golden rules of the businesses. Too often the real business users aren't brought in. It may be the manager of the user or at time the manager's manager of the users because the business team has too much to do to participate in these sessions, participate in these projects. You really can lose the true essence of how the application's really going to work if you don't bring in those true business users that you're defining thorough the profiles.
Mike: So, yeah, we all know business participation's critical for success, but I'm wondering if Dave has any insights and experience on what really goes wrong here and what to do if the business won't engage.
Dave: I think the key thing is making the actual portfolio, the backlog, visible to the business, so the business actually can prioritize it. One of the challenges is, I mean, the Scrum master is one thing to keep the team rolling, but having a strong product owner team or delivery team is really critical and they need to be able to work in terms of the vocabulary and the understanding of the business and produce artifacts that the business can understand what's being delivered. The business also needs to ensure that they provide acceptance criteria, which basically speak to what value they're expecting to see and whether or not the developers have delivered that. So I think the key thing here is really the simple word, tangibility. Often the level of discourse inside the teams gets quite technical. So that's really why it's important to have a delivery team that's working closely with the business and have active BAs that are helping the business articulate their needs in business terms to stay involved. Also having demonstrations at the end of every sprint is very useful because that's where the business can get a sense of, "Oh hey, here's what's actually been done."
Jeff: That was a great voice, Dave. And as I go into the next set of rules within the discussion, we'll see how that business participation really occurs live within the project. The idea when you're going through your end of the project, you have to understand how to negotiate scope creep and the idea that more and more things need to be put into the application. This is a graph that depicts the various groupings of features that exist within a typical application. Once again, various studies have been done on this. I thought it was interesting; if you look at the pieces that are in red, you might think those are the unnecessary or the seldom used aspects within an application. But really what it is is those are the most used, or most often used parts of an application. So in a classic paratel rule evolves here in that 80 percent of the features or capabilities in an application are sometimes rarely or never even used. They get in there, they're built, somebody wanted them, somebody thought they were important. It's something that's used once or twice a year. But it's not really the focus and the 20 percent, which is always or often used is what has to get focused on. So the key learning from this is to really build the features that you need. I know that sounds pretty basic, but it's amazing how often that does not occur. So if you think about a project, you start up the original scope, you've gone to your analysis sessions, you understand what it is. There's a common vision, business is engaged, and you start grouping the application requirements. You have your always or often, I call those the must haves, the next grouping in yellow are the nice to haves, and then there's another group that are in gray. They'd be nice to have, but I really don't need to have them now, or I can do without them for the next release. You start to understand what the full scope is, and the goal there, of course, is fulfilling the vision. Then the team begins to prioritize the skill. Then you start to say, "OK, what is must have, what is like to have, and what really is going to be rarely or ever need?" And then in Agile projects, you're going to do a time box scope. So the idea is that you can take those prioritized projects and build them into the sprint stage which is discussing and going after and building the requirements. The whole time you're focused on building working software. Not doing detailed comprehensive analysis. So the users are seeing in real time what it is the application's going to do for them. As you move through the sprints, it really starts to evolve, solidify, and emerge on what the real priorities are because they might not be the same priorities when you started out. And you may learn some things along the way, and quite often you do. So somewhere along the way whether it's between sprint two and three, a new set of features evolve. As users really start to see and experience the application, the real features and capabilities start to surface. So what do you do with these new features? You've got to change scope. That's where it starts to get challenging because if you know you're conducting a good Agile project, you've got a time box for the entire release of the application. So there's only so much time that you have available to you. So you really have to work hard to prioritize. Certain things that may have been a nice to have, that a user may have been expecting and figured you'd probably get to, those now fall off the sides and they're out into an area that are called "dropped from this release." and it's going to have to be considered for a future release. As you might guess, this is where that engagement manager, this is where the business stakeholders and the IT start to get at one another. This is really tough. You've got to reprioritize, you've got to make hard decisions and you need maturity from everyone that's involved. Just because it was your favorite feature that you kind of figured was going to come into play, it may not be a feature that's going to be rated highly by everybody on the team. You get a lot of stress, you're probably finding these things out as the project is moving through its stages and you can start to see the final release out there. So you've got to be very careful not to go back and break that rule number zero where you start to build this us versus them and it becomes adversarial. Everyone still needs to focus on what the ultimate goal is which is building a highly usable application and to remain reasonable as you go through this process.
Mike: So, Jeff, the graphics is an interesting way to depict the process of really what sprint planning and requirements and negotiation as you go through your sprint iterations as you're doing an Agile project. But it's interesting that what I think probably must happen is that you end up with a very Lean piece of application software because you really only deliver the most important requirements and you delay all the lower level or less important stuff to the end and lots of times you know the end never gets done. I was wondering, Dave, if you can help us and shed some light. Because I'm sort of curious if this is from a Lean concept or is really just pure Agile and Scrum?
Dave: The real thinking that drives this is really Lean. Scrum, essentially is a simple set of practices for how the development team works. It's great, but the real thinking of Lean is basically focus on value, eliminate waste, and provide transparency since transparency enables everyone to see what's going on. One of the other things that's really key is managing flow. So Scrum really helps the dev team do that. But Lean is sort of the overall guiding concept for this. So managers and executives familiar with Lean principles they apply very much to the software process than anything else. In particular, one of the biggest problems is that organizations don't know what the capacity of their software team is, so they end up with all sorts of project management and resource management fund fights because they're trying to put too much through their development plant. So often, you'll find that a company that might be looking at 200 projects and complain they'd like to do 300 is actually better off building 50 key features that are based on value and having a much smaller thing. So managing your capacity right from the front end and portfolio management of projects is really important. So stressing that, and the key thing here is basically letting the customers decide what the value is. Often the requirements come into the process without any value statement. There's a statement that says "mandatory, optional," whatever it is. But the reality in the software business is only the number ones actually get done and some of the number twos. So people really need to put business value on these, otherwise you find out during the envisioning portion that when you're prototyping this you realize, "This thing is going to cost us $10 million to build and it's going to deliver us $30 million in value. Is that really the ROI that we expect?" At which point you might even want to shoot the whole project and say "Look, forget about delivering the features here. We've got another project in the portfolios. It's going to be 100, or 1,000 to 1 return. We should actually move our key resources to that and not even proceed with the project." So it applies at the whole level of portfolio. So it's really Lean thinking, Scrum's a great practice. XP, TDDD, these are great practices. But they're primarily in the development side. The key thing for business people is to actually use the Lean thinking.
Mike: All right.
Jeff: Very good. Dave, you've got a couple of points that we're going to cover in some of the upcoming rules as well. One of those is you're talking about building the number ones, and maybe the number twos if you get into it. One of the goals in overcoming the challenge I talked about early on is building the smallest possible system. That's not meant to say that you're going to build something that's so small that it might not be relevant and it's easy to do. You want to focus on getting those ones and twos done. The classic way of looking at it is you can't have a big bang, it's not going to work. That's where the size really comes into play on these large projects. There's an exponential risk to the predictability of success on the project. The more you begin to add into it, even with the initial scope, you can be too big. So you've got to take care, to make sure you've not designed the initial application you want to build is too big and then to start to pare it back. One of the ways you can do that is to focus on releasing one major functional area. That's what the release is about. Releasing an application to support one product line instead of all product lines, one country instead of all countries. It lets you build it into a small piece that's representative of the overall application capabilities, but don't try to build every application use case or scenario. For those of you who have used function points in order to understand the size of an application, about 2,500 function points seem to be the limit you want to have for a release. High productivity tools can help you handle more complexity, and more function points throughout a release, but 2,500 seems to be about the range most experts will agree on. What happens is every time you add about 500 or so function points of functionalities or capabilities into a release, each of those adds becomes compounding and exponential once you get that predictability in the risk. So make sure you know what it is you want to do, focus on what has to be delivered, and then deliver it. Take the other things and move out into a future release. Rule number five: Remove the adoption pains. Once again having that vision of what the application's going to do, assuming everyone has got that common vision, the goal that you have is to really satisfy the users. You want to build working software that adds value to the business. Some ways that we found that you can do that is to watch out for issues that the trainers are finding. An easy rule of thumb there within this one is if it's too hard to explain, or too hard to teach, it's probably going to be too hard to use. So get the feedback from those who are going to have to train on the application to help you understand whether or not you're really building a useable app. The other one is first impressions count. Times when you focus on the ones and the twos and you implement those and you don't have defects, and you resolve all of those, but you stop when it comes to saying, "What's one more mouse click? What's one more drop down? What's wrong with having 30 or 40 things in that drop down?" And you miss the point that although the application is defect free and meeting the overall goals, a lot of annoying things can go in that will really affect the success of the project when it comes down to truly satisfied users. So usability is very important. Once you've gotten the key that's useable, you've removed the annoyances, the next one to focus on is speed. And it's speed of the application itself as it runs and performs. There are various metrics that you can use. We like to say that we want average response time to be less than a second. Common tasks should be less than 200 milliseconds. Really focusing down to actually how the application is performing and how the application is going to run. Bringing both the good looks, pretty and fast, is really going to help with the acceptance and make this a good project.
Mike: So, Jeff, this notion that speed and a great user experience are paramount to application adoption is important and this idea of using your trainers to help assess the problem, and no training, I think, would be an ideal goal. But I thought it would be interesting to ask Dave his opinion on the notion of Agile and the impact development tooling can have on both good architecture addressing that need for speed and on the great usability aspect and the need for the seeds of learning. So, Dave, you think tools can help with architecture and UX?
Dave: I think the key thing about a good tool is it lets you fail fast. Doing things by hand means it's basically a long way to something that you don't like. So the faster you can place something in the hands of customers the better. In many cases that's greatly helped by having tools that let you build your UI out, interact with the UI, also tools that let you run a simple transaction from end to end so you can measure timing. One of the classic problems is, along with testing at the back end of the process at the bottom of the waterfall in the dirty water, is the test team and the performance team. So it's very important to take not only the usability requirements in terms of, "Hey, this looks and feels good and it's really simple" but also the performance requirements or the internationalization requirements which often get left out so it's easy to be able to deploy an application globally. So you want to be able to make sure that we understand these and we can basically deploy this. When we deploy our prototype out to the web that our colleagues out in Asia-Pacific or Europe are able to use it in their world as well because global deployment is very, very important.
Jeff: It is, as you look at it. Thanks a lot, Dave. As you look at that one of the things that starts to come into play with the next couple of rules that we'll talk about that you mentioned is the success of the rollout in testing. It was also a point that Mike made regarding testing. In order to get this great user experience, you're going to need to really start thinking about how you're going to roll it out and start preparing for early rollouts and involving the teams that are going to be doing the release management and so forth to get it down and also getting your QA and your testing involved early into the project. That's going to really help you understand what truly are the core features and how you're going to be working through those. Another thing that gets overlooked a bit when you think about how you're going to do the testing is what are the functions the applications are tested? Which ones are user experience? Which ones are batch and how you're going to go and develop testing strategies around each of those? Sometimes, you can overlook some of those batch or engine centric tasks and they don't get fully tested out because everyone's more involved in wanting to see the look and the feel in the application that's evolving and some of the things that are behind the scenes can get neglected. So you need to get the QA team focused on both of those early in. Ultimately, when it comes down to the testing and training, the goal is that the application's almost-self evident when someone starts to use it. As we look at building great UX, the ultimate goal of ours when it's all done is that it's as if you downloaded an iPhone app or a Droid app and you don't read the user requirements, you don't go to a training class on how to use those applications. We want to bring that same philosophy to how applications are getting built. So the user experience is so good, it's so well tested and well designed that it's just apparent upon login on how the application can be used.
Mike: So, Jeff, before you roll forward, it's interesting that you should use that analogy. We had a question from Kim in the audience. She was curious if what we've been talking about can also be applied to building mobile applications. So, guys, does this make sense for mobile just like it does a business web app?
Dave: Absolutely. Couldn't build mobile applications any other way, I don't think.
Jeff: I agree, Dave. I think it's one of the things that, too often, is thought of is that mobile is so different in how you want to architect an application. It's an extension of the glass and where the users are going to be and how they need to use the application. So building mobile in a vacuum is going to create more problems than thinking about how to build it in an integrated batch as we talked about it. It's also where the high productivity tools can come into play. Helping to streamline building that universal application, helping to streamline how easy it is to expose core business functionality to multiple types of interfaces whether it be a smart phone, a tablet, or the actual screens that are going to be used at the desktop level.
Jeff: Exactly, exactly. Make it as easy as possible on that delivery. While we're on the topic on training, we had an interesting question posed by James. I thought it was when you focus on... if it's too hard to teach, and if it's too hard to use, you start to sell yourself short and sell the user short. What we're trying to imply there is not that we're saying you shouldn't tackle difficult things or build applications that can tackle difficult business processes. By saying that if it's too hard to teach, it may be too hard to use is really not saying everything needs to be simple. But that if you are going to have to use it and it is going to be complex you need to focus even more on making sure that it is as intuitive as possible. Because we all know the applications we build, they're not all based upon very simple create, re-update, delete and move on. There can be some very complex work flows and processes that go into an application that need to be understood and taught. So I thought I made a really good point and hope that was an interesting response to that point. Number eight as we're moving down through eight and nine is start integrations early. That might sound pretty basic and kind of goes in line with some of the other things we've talked about preparing early and thinking ahead what you're going to do. Too often, when it comes to doing integrations the team might make some assumptions. The folks that own those other applications to which you have to integrate, who own those integration points are going to have the same priorities to assist you as you have on your project. You might think that just because you're moving fast, they're going to move fast, too, and that they're as motivated as an Agile team is to be delivering these great applications. So you can really get some surprises in your application if you get down too late into the process and then you start thinking about what the integrations are. You say, "Well, I know there's integrations into this system. I know how it's done." But until you really start to tackle it, you don't know what's going to happen. You might find out some surprises if you don't start early enough. So it can be anything from needing additional approvals in order to have an application access another application. There may be slight changes that need to occur in order to enable an application to integrate with yours. You might discover that you need something new that you didn't even know about because of some claims or assumptions that were made. And then, even if all those go well, you might find out too late that the APIs or the integration points are too slow and it starts to destroy that idea that we have on great user experience which is the application needs to be fast and responsive. If you want to look for the areas where you're probably going to have those issues is going to be around your integrations, points where you don't have any control. So getting to those early and understanding them early is really going to help you avoid surprises and some chances of late to project learnings and failures.
Mike: So, Jeff, we all know that for just about every enterprise IT project we have to do some integrations and I was wondering if, Dave, if you've stumbled on any additional techniques from your experience that could give some advice for addressing the integration challenge.
Dave: Basically, you can think of the application in some sense as touching two interfaces. One's the customer, but the other's actually all the systems this has to integrate with. Both of those need to be done up front. Key thing we always do in what we call an envisioning activity is we'll try and make sure that we can use the APIs or talk to the databases that are there so we can actually do the basic tasks. Lots of people have this really great interactive applications, but it turns out they have to talk to something that's over a slow communication link or something like that so the whole assumptions about what can be delivered can't be delivered using their current technologies. So the key thing is basically to write simple apps that'll let you approximate the end to end behavior of the system. That's going to show you, "Oh, gee, this thing is missing." The other thing is cross education. Often the classic problem is the mobile- ites really only care about the mobile stuff and the Java guys only care about the Java guys and the Java stuff, and the mainframe guys, and so on. So you've got these technology towers. The key thing is basically doing cross training and having different skills on the team so that very early on people can actually say, "Hey, yeah we've actually talked to Oracle or DB2, we've talked to J2 Estack, we've got that piece working." So all of those things are known really before the development team really starts moving into development, you've got all the key pieces there. The UI works, the interfaces essentially work. Very, very important you do those. There's also some techniques called mocking, and so on, and TDDs that let you approximate this if you can't touch the real system. But right now there's even techniques for actually testing live a transactional real time feed. So there's a lot of techniques, we're doing this now, so they should be really done up front at the time of the UI design. Same imperil. That's why we call it envisioning. Both technical exploration, and user exploration.
Jeff: Good comments, Dave. Thank you. The rule number nine is, as we're wrapping the nine rules, is overcoming release phobia. If you think about what Agile's doing in the premises is build these smaller applications, release the applications as early as possible to the business so they can start to gain that value, build smaller applications, do multiple releases as opposed to one big bang, you want to do multiple releases. Well, when you start to think about multiple releases, or a release in general, that really can start to bring up some fears and worries by those that are actually responsible because releases are hard. They're big, they're ugly, they involve lots of people and time. What can start to emerge for the depiction here is the concept of the lizard brain. The lizard brain, if you think of that prehistoric part of your brain that is worried about everything. It's that piece that's those primordial emotions, the fear and rage and uncomfortableness of a situation. In a release a lot of those things start to come out. "What if it doesn't work? What if it doesn't get done in time? What if we didn't check everything?" In the desire that is to slow down, do more checks, do more release testing and you've got to work to get the whole organization to overcome that. Because if you're adopting Agile and if you're adopting high productivity tools, you're going to go much faster than you ever have in building applications for the business. You've got to really help that team that's doing the releases and doing that release management, kind of resist that voice in their head that's telling them to, "Slow down, think more about this, let's test some more, and test some more, and test some more." With the right approaches and high productivity tools even when the releases are coming fast and furious every three or four months, maybe. The ability to, if there is a problem, to react to that quickly and not have it be as calamitous as it may have been under past more traditional release scenarios.
Mike: All right, so Jeff, that leads us to one last question for Dave. This notion of releaease phobia. Is it real? What are you seeing companies do to overcome this challenge of releasing more often?
Dave: The best practice today is actually continuous delivery. That is basically in the financial markets people are actually delivering continuously, but the best practice often is to be able to release on a monthly basis or bi-weekly. This is very common. The key thing it requires is to have the developers and the operations team integrated. This is in the Agile world, something that is now very, very important and successful called DevOps. DevOps basically allows you to deploy continuously. This is only enabled because you have a continuous test environment. This is a significant investment in many cases. Particularly for lower level tools it makes it much more challenging. If you have higher level tools, typically they'll involve some sort of continuous deployment and test capability. But it's absolutely essential to be able to do this because often in many environments things are getting very, very complicated and even all the testing in the world nothing beats testing and running it in the live environment. So the best practice today actually involves running in the live environment and actually taking it up or taking it down to do components by actually monitoring and so on. So the automated tools for DevOps are very, very important, and clearly this is easier to do in some of the more modern cloud based environments than it is in an older enterprise stack which is basically the parameters. Its' easier to do everything in a new environment. But even in very conservative environments where there's established legacy systems from mainframe to large Oracle databases and so on, these practices are increasingly being used so people can actually do more live deployments.
Mike: All right. So, I think the lizard brains are already working out there a little bit. I've got one comment that says, "Testing in the wild." So it's a brave new world and overcoming release phobia is certainly one of the big challenges that we're all going to face as we continue to wade into the world of Agile and rapid delivery processes. So, guys, we're almost out of time. I wanted to remind you that we've got one more webinar in this series. It will talk about, and specifically address this concept of release phobia. So I want to thank Jeff and Dave for their interaction and discussion today. I hope these nine rules, you found insightful. Some that you can put in practice right away and, of course, others are going to take some time figure out how to implement and manage. If you're interested in the Forrester white paper, you can get it off our website and look for an invitation to our final webinar addressing release phobia. Thank you, guys, very, very much. This concludes our webinar.