Welcome to this IBM podcast, Deployment and. Agile Projects, Collaborative Development and Operations.

Transcription

1 [ MUSIC ] MATHENY: Welcome to this IBM podcast, Deployment and Agile Projects, Collaborative Development and Operations. I'm Angelique Matheny with IBM. Businesses are looking for innovative ways to quickly develop and deploy revenue generating projects on time and under budget. As development and operations teams adopt Agile methodologies in order to quickly meet these business demands, there's an increased focus on improving visibility between the development and operations organizations. So today we welcome Scott Ambler, chief methodologist for Agile and lean, and he's going to share with us his view on development and operations, what could be done to minimize the impact to Agile projects and the value addressing development and operations challenges would offer Agile project teams and the business. Hi, Scott, welcome to the podcast. Thanks for joining us today. AMBLER: Hi, Angelique, how's it going? MATHENY: Scott, what are the challenges typically faced by Agile development teams as they begin to move releases into the test and production environments? -1-

2 AMBLER: Well, in many ways they're the exact same issue that non Agile teams face, although slightly different flavors. So, you know, the Agile teams are still going to have to answer basic questions like, do they have sufficient functionality to justify the cost of releasing the system into production? Is the release organization -- which might be the department team themselves -- are they ready to accept the solution? Are they ready to do any training and education for their end users, for their operations people, for their support people? Not all systems need that, of course, but some do, so you'd better be prepared. Have they communicated their release? Are they ready to go into end of lifecycle testing? The good news is that Agile teams do a lot more regression testing toward the lifecycle so an end result of that is they don't have to do as much end of lifecycle testing. So there's, you know, this is one of the differences. And they should also ask the question at some point, you know, is the system production ready? Is it going to work with the rest of the applications, the rest of the systems that are already in production? Because you don't...so your system might be very good, but if it behaves badly from the point of view of everything else that's already there, then -2-

3 it's not production ready. So the good news is that disciplined Agile teams have it a lot easier than undisciplined Agile teams, I guess you would say, or traditional teams. First and foremost, they do full regression testing, so they're doing the regression testing all the way through the lifecycle, often several times a day. At least daily but, you know, as I said, often several times a day, which is very good. And they fix the defects that they find. So they're producing higher quality. They're also doing something called continuous integration, which means that they are rebuilding the system several times a day. They are retesting it. They might be running static code analysis, dynamic code analysis, good stuff like that. So there's a much greater focus on quality. Another practice that Agile teams follow is something called executable specifications. The basic idea is that they write a single test before they write the source code that fulfills that test. And this is also called test driven development as well. So what's happening here is that because they're writing the test before they write their production code, they are actually not only validating the work as they go, but they're also specifying it as they go. This results in not -3-

4 only higher quality but in much greater stakeholder satisfaction because there's a much greater chance that they're actually building things the stakeholders want. MATHENY: So, Scott, how best could this gap between development and operations be closed so that these two organizations worked collaboratively rather than in silos? AMBLER: Yes. So this is a two-way street. So both the development team and the operations team need to choose to work with the other team more effectively. One approach that you want to do is build this collaboration right into your process. This is something that we've done with a process we have called discipline Agile delivery, which I've led the development of. Now, this is geared more towards developers, of course, but all the hooks for operations are there, too. So from a development point of view there's several critical things that you want to do. First of all, the development team needs to be enterprise aware. So what that means is they need to recognize that whatever work they're doing is only part of the overall organizational ecosystem. So they need to be leveraging the existing infrastructure wherever possible. -4-

5 So, yes, it's fun to [put] new platforms and new technologies, but this can often be a serious problem for the operations team because the operations people are the ones that need the run the system once it's in production. So if they're not ready for this new technology that the development team loves that they want to work with, then that's a very serious problem. So you need to negotiate these things before you start working with them. And to be fair, very often the operations teams are also very eager to retire some of their older technologies as well, so working together can make this much smoother. To be able to leverage the existing infrastructure, you've got to be able to find it. You've got to be able to know what it is. So you want things like asset repositories such as IBM Rational Asset Manager that can help you to find these assets that you want to leverage. You also want modeling tools such as IBM Rational System Architect that describes what the overall infrastructure is and more importantly probably, what the vision that you should be working towards will be. The development team should also be following organizational standards for configuration management or the way they access databases, for the way they create new databases. They're doing that, data naming conventions, UI conventions, -5-

6 coding conventions -- all these good sorts of things which respect often set by some enterprise group, often the enterprise architects but your organization may vary. And the reason why this is important, not only does it make life a little bit easier for the development teams but it increases the consistency of what you create and that makes it a lot easier for the operations people. You should also recognize that your operations and support people are very important stakeholders. So it's not just about the business end user, the business customer, but it really is about all the stakeholders that you have to meet the needs of, and operations and support are very important stakeholders there. You should understand the release process and plan for it. Better yet, you should have a transition phase or release phase or deployment phase, whatever you want to call that, built right into your development process because release can actually be very, very difficult, and you want to make sure that you understand what the issues are and streamline that overall process. So you're going to have to invest a little bit of time understanding it and defining it in some cases. Practices, as I was talking about earlier, continuous -6-

7 integration, regression testing throughout the entire architecture. And this includes both the user interface and the database. So many Agile teams and some of the mainstream Agile teams will often focus on the app code, like the business code, which is great... But they often fall down, I guess you would say, when they're testing the user interface and they're testing the database and you need to have a fully tested system end to end. This also includes installation testing, too. I find a lot of teams will run into trouble on this because they're not installing their system on an automated manner in a continuous deployment manner on a regular basis, then they struggle with the overall installation process because they haven't really done it very often, haven't tested it, and as a result they run into trouble at release time. Including your operations and support staff in your iteration demos. So they might not go to all the iteration demos, but you should make you have sure that you've got a few people who understand the needs of operations attending some of the key demos that you hold at the end of each iteration so that way they're up to speed on what you're doing, they have a better understanding of when you're problem going to release in your production. -7-

8 Obviously you should be negotiating your release date as well. Many organizations have what's called a release window that you should be aiming for so there's certain points in the month, there's certain points in the week that you're allowed to release in your production. You might of blackout dates. So for example, many retail organizations won't let you release new production from October through January, because that's the peak time for many retail organizations, and they don't want to be taking the risk of introducing new systems that don't work very well or that their end users don't understand. So there's release blackout dates that you're simply not allowed to release into without very, very good reason. When it comes to practice like continuous deployment you have to automate as much as possible. It's not really an option there. So you should be considering tools like IBM Rational Built Forge or IBM Rational Automation Framework for WebSphere -- better called RAFW, I guess. And what these tools do is help you to deployment process, at least the technical aspects of the deployment effort. And that way it streamlines everything. And because it's all...it's tooled and it's open an accessible, your operations people can be actively involved with development of these build trips, of these deployment trips, I should -8-

9 say. And it will better reflect the realities of the operation environment. So this is an opportunity for greater collaboration. And obviously you should be trying to understand and address operations issues as early as possible. So, you know, designing your system to be secure from the very beginning, making sure that you can do your data backups and your system backups and have all that automated and tested and ready to go. These are all...you know, they're boring issues, I guess, from a development point of view, but these are absolutely critical from an operations point of view and they're very, very critical and very important. And if you don't have these things in place, you're not going to be allowed to release. Your system won't be production ready, and you're going to find at the end of what you believed was the end of your project you've still got several weeks or several months of work to do doing all this extra stuff that frankly you should have been thinking about a lot earlier. And I guess finally another couple interesting points. First, the development team should be adopting collaborative and open tooling such as from the Jazz platform tools like the Rational Team Concert. And these products are integrated, they're instrumented. -9-

10 So they not only allow you to...enable you to do your job for effectively but they provide real-time information via project dashboard to all your stakeholders, including your operation support people. In particular, your operations people are going to be very interested in the quality. They'll be very interested in your defect trends and they want to make sure that the defect trends are going down that you're actually addressing the bugs that you are finding. So this is going to be critical. You should also adopt tools that integrating in with the operations environment. This is the combination of Rational and Tivoli. And the basic idea is that they're these tools that support the development operations integration or collaboration, and it is possible and very desirable to do this. And finally, the development team should hold educational sessions with the ops team. So what will happen is many of the release processes are often geared for traditional environments. Many of your operations people used to be developers many years ago, and they probably followed a traditional lifecycle. So their expectations are off. They're used to the traditional teams which aren't doing this level of testing. -10-

11 They aren't doing the same level of producing, the same level of quality as the Agile teams are. So what will happen is you'll have these very onerous and long release processes that are geared for these lower quality products the traditional teams are typically producing. And as a result, you'll have these processes inflicted upon you. The Agile teams need to educate the ops teams as to what to expect. Now, in the other direction, from our operations point of view, the operations people need to be prepared to be involved with the dev teams. So it's easy to say that the operations people should be invited to demos, but they should actually attend them and provide feedback. They need to be flexible. So the Agile teams work differently than the traditional teams. You know, one size does not at all, so the operations teams will often be supporting Agile project teams and iterative teams and traditional teams, sometimes even ad hoc teams. So they need to be flexible enough to work in different ways with these different types of projects. And that's okay, but it can be difficult. It should be as easy as possible for the development teams to work with the operations people. The operations people can and should bring real value to the development team, should help them -11-

12 streamline what they're trying to do to make it as easy as possible to release. We are seeing this in production in the marketplace, which is a good thing. The operations people should be adopting tools that integrate with the development environment. So this is a two-way street. So, you know, products like IBM Maximo and some of the other IBM Tivoli products should be looked at seriously with that. One of the challenges, I've seen a lot of organizations, that they buy point specific tools from various vendors. And they're all good tools. And they'll adopt open source point specific tools, but they'll work on whatever those topics are very well, but they don't integrate with each other. So as a result, they can really harm the overall dev ops experience and make it very difficult to collaborate. So this is something that you need to be looking at the bigger picture when you're purchasing your tools and trying to figure out how you're going to work together with them. Another very critical issue is that the operations team, support team should make it as easy as possible to communicate their defect report, their incident report, their enhancement request back to the development team. And this also requires integrative tooling. And the reason why is the development team should be addressing those defects -12-

13 and fulfilling those enhancement requests. So they need to find out about them. The development team should be treating them as new incoming changing requirements so as the development team is building the new release of a system, they should be expecting new ideas coming in from the existing users of the previous releases. So this is a key observation. And this is also something we've built right into discipline Agile delivery. We've made it an explicit part of that process because it's such a common need. And finally, you know, the operations team should also be holding educational sessions with the development team. Many developers don't understand what really happens in operations and what the issues are, what the concerns are. And if they had a better understanding of that, it would probably change some of their practices and be doing work that actually reflects the overall reality of the organization. In the lean community, we call this optimizing the whole: looking the at the bigger picture and making sure what you do fits into the overall picture. So there's a lot of opportunities for both development teams and operations teams to work together. But it's going to -13-

14 require behavioral changes on both sides of the fence. And maybe some process changes and obviously some tooling changes. So, there's great opportunities if you choose to take them. MATHENY: Scott, if these opportunities are taken, like you just mentioned, if this development and operations gap was decreased or even closed, what would the measurable value be to Agile projects and their business stakeholders? AMBLER: That's a great question. So we're actually seeing some of this in some of our customers. There are several very critical advantages to this sort of an approach. First of all, I think the obvious one is quicker time to value or quicker time to market. And because we're streamlining the development effort, because we're reducing the effort it takes to release through automation and through better processes and improved behaviors I guess you would say, we're actually seeing development teams get their solutions into production quicker. That then in turn enables them to increase the return on investment both through lower opportunity costs but also through lower development costs, through this greater automation, through better collaboration. -14-

15 We're also seeing increased consistency in quality, particularly when it comes to many of the operations issues that we see such as security, such as availability, being able to run 24/7, good stuff like that. And because the operations people are becoming clear and important stakeholders to these development teams, they communicate their issues to the development teams and the dev teams address them. This leads to greater quality. And finally, we're definitely seeing increased stakeholder satisfaction where the operations people are becoming a lot less frustrated with the development people. But we're also more importantly seeing better business stakeholder satisfaction because the systems are running more smoothly, or they're coming out quicker and they're actually addressing the overall needs of the organization better. So there's a lot of value here. Yes, it can be a bit of a challenge to do some of these things I've been talking about, but it's definitely worthwhile. And IBM is definitely interested in helping our customers to achieve this. MATHENY: Scott, as always, thank you so much for sharing your time today. This is great stuff. We really appreciate it. -15-

16 AMBLER: Okay. Thank you. It was my pleasure. MATHENY: That was Rational's Scott Ambler talking about deployment and Agile projects, collaborative development and operations. To share this podcast with your colleagues or if you're interested in more podcasts like this one, check out the Rational Talks To You Podcast Page at We'll post a link on this page so you can learn more about IBM's collaborative development and operation solutions. This has been an IBM podcast. I'm Angelique Matheny. Thanks for listening. Keep tuning in as Rational Talks To You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -16-