IBM Podcast [ MUSIC ] Welcome to this IBM podcast, Agile in the Enterprise: Yes You Can. I'm Kimberly Gist with IBM. If you love the idea of applying Agile practices in your large enterprise but think you can't, think again. Richard Knaster has worked with Enterprise customers around the world implementing Agile methods. Richard Knaster is the IBM Rational Worldwide Practice Manager for Agile and CCM. He helps customers all over the world implement Agile methods, practices and tools. Richard is a member of IBM's USC Agile Leadership Team. He has over 20 years' experience in software development from practitioner to executive level. He is also a contributor to the PMI portfolio and program management standards and is an Agile planning and portfolio expert. Richard, welcome to the podcast and thank you for joining us today. Let's jump right into our first question. What would you say are the typical challenges that Agile teams face in the enterprise? Hi, Kimberly. Thanks for having me. That's a great question. A few of the challenges that Agile teams -1-
face when they're in enterprise is overcoming the fact that methodologies like Scrum were designed to work with small teams that are collocated. And in today's environments, most teams are neither small nor collocated, and they're typically working on very complex systems within a complex environment. And so therefore, it's difficult to adapt those practices and processes to be able to work in an environment in which people are working all over the world, they are geographically dispersed. Some people are working from their homes, some people are working in different cities, some people are working in different countries, and this makes it particularly challenging to do Agile software development. A very good point. Why would you say many customers feel that using Agile methods don't work or are less effective in the Enterprise? Right. So that comes up quite frequently. And when you are doing Agile in enterprise it's really an organizational transformation that needs to occur. And changing any process in enterprise is never an easy task, therefore it should come as no surprise that when you move from a traditional to an Agile approach it's a difficult thing to do. -2-
In fact moving to an Agile approach in enterprise, it's a multi-year effort. It's a major paradigm shift that involves changing your organization's culture, beliefs, governance, HR policies, titles, funding and more. And it's no wonder why many executives appear to be skeptical or resistant to Agile. If your Agile team tries to adopt a development approach unilateral within Enterprise without the support of top management, you may make things somewhat better but you won't realize the full benefits or potential, and the team may end up very frustrated and not satisfied with the outcome. It is also likely that without an Agile champion from the top, that the Agile adoption will not stick as people return to their old behaviors. A great point there about the Agile champion. So what are some of the myths surrounding Agile in the Enterprise? Yes. So a few of the myths are that that Agile can't scale; that it can only be used on small teams that are collocated. Many people think that Agile should be piloted on an insignificant project, but I find that this really doesn't help. You should pilot an Agile project on the most important project you have so that your A players -3-
are involved, and in this way, the project can't fail because you've got your best players on the team. If you pilot with a very insignificant project and it works people then would say, well, that was an insignificant project and therefore it doesn't prove anything. And if you fail, people point to the failure of the process. Another big myth is that people believe Agile means ad hoc and undisciplined -- that just using Scrum or XP processes alone can scale, or that people can piecemeal Agile practices on their own, or that Agile development stops at engineering. And finally, that alignment with the enterprise is not required. Well, that was interesting, Richard. So for our next question, just based on the elements that you just laid out, why is it...or rather, tell me about why piecemealing practices is not the best route to go. Right. The problem is not with using different practices together; it's that most organizations don't have a methodologist on their team. And therefore, they try to implement practices in part and others in whole and things don't really fit together. They don't really understand what makes Agile work and -4-
therefore they may not do a daily meeting, or do release planning, or cut out something else in the process that's a very important element of Scrum to work. And then they add in other elements which add a lot of bureaucracy. So it really takes a highly skilled person or persons to understand how different Agile methodologies can be blended together. So IBM has a new process framework that we call Discipline Agile Delivery, which is a hybrid process. And we take practices from Scrum, XP, DSDM, RUP and others, and we've learned which practices can be combined, which practices can be incrementally added over time to be successful. Great, Richard. So earlier when you were discussing the myths, you talked about how Agile development stopping at engineering doesn't necessarily work. What would you say is the importance of other groups being involved in the Agile development process? Right. So it takes much more than the development team to be successful with Agile. We need the business involved. We need the business to prioritize the most valuable work for the team to work on. We need HR to be involved so that people are evaluated differently. We want to drive the behavior of that, the work of the team -5-
that's being successful. And if we want to measure team performance as opposed to individual performance, funding of projects needs to be different than in the past. If we can incrementally fund projects instead of funding the entire project, that means we can kill them if they're not being successful. And we can kill them after one or two iterations if it's not the right thing to do. So if we don't change the rest of the enterprise then we won't change the behavior of how the Agile development team works. We'll just be using our same waterfall processes and the team will be doing their construction in an Agile manner and it won't provide the most benefits. So again, Richard, great point. So now that we've been through some of the myths and some of the typical challenges, how do successful teams in the enterprise get started with Agile? Well, I think the first thing that's important is that you should have an Agile executive champion who is going to drive the organizational change. And this person needs to maintain an organizational impediment log -- so, recording the things that are getting in the way of doing Agile development. This could be the way in which projects are funded, this -6-
could be the fact that teams are very matrix instead of having dedicated Agile teams. So these are hard things that the teams themselves can't solve; they need an executive to help them get through that. Another important thing is that when adoption is done that everyone on the team agrees to work a certain way and that they agree to adopt a certain set of practices. And really, at first, until you understand Agile you should be following the framework and doing all of the practices that are prescribed, not trying to piecemeal the practices as we discussed before. Then another important thing is to find the right set of pilot projects to do, not necessarily to prove that Agile works but to understand how Agile will be adopted in your organization. Many projects believe that their first project should be a very conservative one without much visibility, one that doesn't require the key players. The thinking is understandable: if that project were to fail then there's low risk to the business. So it fails, no big deal. The problem with that attitude is that it will likely lead to the failure of your organizational transformation, especially if the project should indeed fail. Instead, pick a project that must succeed. Pick a critical -7-
project, and put your best players on it -- because when the brightest minds are involved the risk of that project failing is much lower. Even if there's reduced uncertainty about what's being delivered, the Agile techniques are going to help reduce that uncertainty much earlier in the project lifecycle than a traditional project. So even though you're adopting new behaviors and practices, your chances of success on that project are going to be much higher. Your chances of successful Agile adoption is going to be much higher because you've just proven that Agile works on a critical project. And finally is that your stakeholders need to have a trust in the process. So they need to change the management style, that they no longer need to be telling the team what to do but to give the team a problem to solve and not micro manage the team. Guide the teams, but let the team decide on how to do the work. I like the term, "trust but verify," so it's important that the team doesn't shortcut important things like doing regular milestone reviews, which is best done at the end of an iteration to demo the work they've done as a permanent way to mark progress. Too often when teams move to Agile methods they are still -8-
reporting to management using the old, traditional ways of status reporting and reporting against the conformance to the plan instead of adjusting as the team learns new things. So it's important that there's verification through regular inspection of the progress and adapting to things that they learn, but again, it's important that the organization adopt new ways of how the Agile teams report progress -- that it's based on the completion of real work. Not just the completion of tasks, but actually the actual value that they're bringing with their software. And lastly, bringing human resources into the picture. You will find that there's a lot of fear in the organization when you begin adopting Agile. You may hear things like, I'm a project manager and we're adopting Scrum, but Scrum doesn't talk about project managers. What's my role, because there isn't a business analyst role on an Agile team; there's a project owner. So it appears everyone on that team is called a developer, and as a practitioner you might say to yourself, there's no path for me for upward mobility because now we're a flat organization. How am I going to get to the next level? How am I going to get more money if I'm always going to be a developer and now there are fewer levels of hierarchy? -9-
And that's why it's so important that the HR department become involved in Agile transitions and help management determine the best way to reward people not based on individual performance but based on performance as a team. And those are really the key things that I believe that need to be done when you are adopting Agile. Maybe one last item is I'm a big believer that you use Agile methods to do an organizational change effort like adopting Agile itself and that you begin using the tools, the Rational Team Concert, to adopt Agile. So right from the get go, you can draw the visibility and transparency that's required in an enterprise because an executive just can't come down and attend daily meetings to get progress. They need to see this visibility, they need to see that progress is being made in their projects, and that best comes from using a tool like Rational Team Concert or others so they can see that progress. Well, great. Thanks, Richard. That was a great discussion on Agile, other potential challenges, debunking some of the myths and definitely some suggestions for how to make a project using Agile methods successful. Thank you for your expertise and your time today. Thank you, Kimberly. It was my pleasure. -10-
That was Richard Knaster, IBM Rational Worldwide Practice Manager for Agile and CCM with an interesting overview of Agile in the Enterprise: Yes You Can. To hear this specific podcast or to browse additional topics check out our Rational Talks to You podcast page at www.ibm.com/rational/podcasts. This has been an IBM podcast. I'm your moderator Kimberly Gist. Thank you for listening, and we hope that you will choose to keep tuning in as Rational Talks to You. IBM Podcast [ MUSIC ] [END OF SEGMENT] -11-