Per, can you tell us a little bit about yourself and what you're up to?

My name is Per Kroll and I am project leader for a product called Eclipse Process Framework, an open source project, and I also develop and manage for IBM's commercial methods, and that includes direction of our process and some enterprise methods. I'm also a book author and just had my second book published "Agility and Discipline Made Easy: Practices from OpenUP and RUP".

You are wearing a t-shirt that says the Eclipse Process Framework. Can you tell us a bit more about EPF, what is it?

EPF is an open source project, and it's about building a community in an open source environment, where we can collaborate around software practices. It also will produce and deliver some example practices or processes that can be used as a starting point for different organizations and project teams. And it also has some underlying infrastructure or tooling to help you create content and customize content. This infrastructure is extensible so you can build different extension tools on top of it.

What exactly can you do with the Process Framework?

As we develop this, people can download it and look at practices – whether they are best or not will depend on your context - but you can download the EPF and you will find guidance along techniques for capturing requirements, capturing architectures, how to do testing; so it will cover any relevant software development topic that you can use as a starting point and naturally you can then choose and pick: "these practices make sense to me and these do not," so you pick out a small subset that you may want to adopt and you can change it to make it your own.

It produces an HTML document describing the process?

That is correct. When you have decided what aspects of process patterns you want to adopt (and show in a life cycle, if you want one), the end result will be an HTML website, and that means that even though we use Eclipse based tools for producing and customizing practices, you will use your favorite HTML browser to actually look at it; and your end user, that is your consumer, will use just the browser.

How do you see this fitting into a typical project team, who will configure the subset and who will consume it?

I think we will see a number of different models. In some cases a project team may decide that we need to get some ideas on how to follow various iterative approaches, so we want to get some guidance and you can take EPF, download it, and look at what is available there. You'll probably like some of it, you'll probably have some ideas on how to improve it, so you can modify it as you go along. But it could be something the team decides to do. Another usage model would be when an organization says that "we would like to have some standard approaches for software development and build up a common language for communicating around software development".

Why do you need tools for this, why can't you use a wiki or read a book or talk to your friends?

That's a very good point. You should definitely talk to your friends, you should have coaching and training and so on; there are a lot of different ways of transferring knowledge and in the end if you want to adopt iterative development it's critical that you get that coaching from people that have done it before; it's harder to just read up on something and change your behavior. But we also think it is important to have a reference framework, a reference library that you can go back to and read up. For example, at Agile 2006 there have been tons of great presentations, but I would like to go in and read more details on a number of the topics. If we share a common knowledge base within my project team or my organization, we're building up a common vocabulary; common language and we can use these tools to capture our best practices. What we have today are some tools that allow you to pick out practices and publish an HTML website that will be like a reference library for my project or my organization.

What we are also working on is some wiki technology and if you have reasonably stable practices that have been proven to work for some time, you can list different process patterns the same: "for this type of situation this works well; for this situation this process pattern works well". Where our infrastructure is doing a good job today is where it captures those, allowing to express different variants when in this situation "it's almost like that but a little bit different," and you can publish an HTML website. Some practices are very hard to express because they emerge in best practices. How do you describe code smells? There are some things that you should do to avoid that code goes bad, but you might not be able to describe it succinctly today. If you have a wiki you can start to capture some of those thoughts and 3 to 6 months later we may have a lot of good ideas around. You can then harvest that and create some guidelines for how to write code to avoid that you get bad code. And then you can leverage the infrastructure to capture that guidance and describe when these guidelines make sense or not. Maybe some developers are not too keen on certain guidelines and what is used in the organization, and they can make comments and say that "this doesn't make sense for that reason", or they can say "I used this; it was really useful here is an example of what I have produced as an end result".

What processes are being captured now and who's doing it?

Since EPF is an open source initiative, whoever has good input can participate. We welcome anybody who wants to participate. We work like any other Eclipse project, anybody can propose a practice and then in the end it is the committer that decides what gets included. Now, EPF can support any type of process. We have currently started to work on, and gone pretty far on, a process called Open Unified Process or OpenUP, we have other teams working on capturing Scrum, XP, Agile Modeling, AgileUP; we have interest in capturing DSDM and so on. There is a broad variety of different processes that people are working on to capture. In the end what you need to do is to show that these practices make sense, with pair programming it's obvious as a well known practice, some people like it some don't but there's enough of an industry evidence that is useful for certain organizations, it absolutely makes sense to capture it. Other practices, if they are very dubious you need to convince the committers that they are somehow valid practices, that they at least make sense for certain audiences sometimes.

You mentioned that Scrum and XP and some other processes have been captured now, but what's in the tools today, what content is available right now to go read?

EPF was launched in February 2006 and we will do the first release September 30th,. So we are still working on the first release. Right now we have content capture for Open Unified process, which is an open source version of unified process, with a lot of influences from Scrum, and that content is being matured and will be released on September 30th with version 1.0. That is the only content available at this stage. A number of organizations are working on the XP, Scrum and so on, but are still working on producing something that can be contributed, or going through the legal procedures. We are very close now, probably only a few weeks away from having an XP process captured which was done by ObjectMentor.

Tell us more about OpenUP. Why do we need an open source version of RUP?

It is actually not just an open source version of RUP, what we are doing is take a fresh perspective. How would we capture it, if we are going to start it from scratch, how can we capture a really good iterative Agile process. And the process that we are trying to capture is consistent with, for example, Rational Unified Process. We are taking a fresh perspective at looking at how we can best describe that process. We have a number of ideas and learning from other processes. Let me take an example: a few years ago when I read the Scrum book I said "Wow. This is the best description I have ever read of RUP's iterative process". I wondered what made him able to describe very succinctly a really good iterative process. There were some things they did in Scrum that made him better, succinct, articulating how you prioritize things to go in with an iteration. In Open Unified Process we are looking at other processes, how they are described, and if they have any concepts then in this case the concept becomes our backlog which we refer to in Open Unified Processes as work item list, and we added that, which allows us to describe an iterative approach in a better way than we have been able to do before. We are still experimenting and learning what are the best approaches, over the next few months you will see a lot of improvements on the website; I'm sure we will learn more and get better ways of describing a process.

What are the key aspects of OpenUP?

OpenUP is consistent with the Agile manifesto, looking at how to best implement the Agile manifesto and other key principles we have seen characterize successful projects. We are focusing on 3 key areas: the areas of how to capture intent from stakeholders, and capture requirements and vision and so on; we are focusing on how to do the day to day development; and we are focusing on how to manage iterative development. Those are 3 sub-processes that we make sure that, even though they are succinct sub-processes, they are always integrated in a whole. And one of the things that makes them integrate in a whole, is the collaboration layer. The process made collaboration a first-class citizen where we describe for each of the sub processes how the entire team needs to collaborate to successfully work with stakeholders and capture stakeholder requirements, doing the right prioritization, to create requirements that are validated and so on. It's a fresh perspective on how to express a process that will hopefully make sure that people get the essence of the process. We are not trying to invent a new process; it's trying to find a better way of describing processes that work really well.

Trying to document all the OpenUP sounds like a lot of work. Why shouldn't IMB open source RUP itself, the intellectual property, or did they do that?

Open sourced, contributed, about 15% of what is in RUP, but rather than just take out 15% and make that into the starting point for OpenUP, we open sourced the material contributed to Eclipse, but we are actually using that as source material and rewriting it from scratch. But 15% of the IP of RUP has been contributed to EPF. Also we contributed a lot of the tooling technology we have for our commercial method product, to get the underlying infrastructure to be able to improve and publish and document practices.

How is OpenUP different from RUP?

OpenUP differs from RUP in a number of ways. One important thing is that the streamlined or basic version of OpenUP, which we call OpenUP Basic, must have no more than 200 pages of content. This forces us to be very selective in terms of what we include and do not include. The other thing is that we want to make sure that we do a really good job to capture the essence of the Unified Process, the iterative nature of the process and the collaborative nature of the process. We really focus on describing collaborative practices, making sure that people understand iterative development. And we have a 3rd area which is to look at what other processes are out there, such as Scrum which we can learn from, and incorporate new ideas from other sources; we have a number of good ideas to come up already. We are taking a fresh new perspective, writing the process from bottom up to make sure that we do the best job possible to describe an iterative process we are typically following in our projects.

The focus on iterative development, is that in reaction to people's conceptions that RUP is a waterfall?

It's a funny conception that people have, if you are looking at RUP as always having been very iterative. Unfortunately some people seem to think it's not iterative, but it's always been extremely iterative. At the beginning it has said that this is an iterative approach, and it has its roots in iterative development that we started within the '80s and have evolved. We wanted at first to publish and document books around iterative development with Grady Booch and other people doing that. So we were always taking a lead on how to transform companies to iterative development. Unfortunately too many organizations want to say that they use RUP, but they have no desire to change their approach from the waterfall to anything else, so they use RUP but they do waterfall development, and they may use some of the artifacts, but they don't follow the spirit of RUP.

What is the relation between OpenUP and EPF? Is OpenUP only founded in EPF or is it a separate initiative?

OpenUP is only found in EPF but EPF will contain other processes also so any process can be hosted in EPF. XP, Scrum and so on, and also some thoughts around producing a consolidated Agile framework.

Jim Highsmith and Mike Cohn have been talking about a consolidated Agile framework. What is that about?

We wanted to discuss what EPF could mean for the Agile community, and Jim Highsmith and Mike Cohn have played around with the idea of creating a more consolidated Agile framework. This is still only in its infancy but also some thoughts around that you can leverage EPF as a vehicle for doing that. And the benefit with EPF is that it's open source so it's neutral, no company controls it, it is a transparent development process, anybody can contribute. So it has a lot of benefits with doing this within an open source organization. And also Eclipse gives a lot of credibility to whatever you put into EPF; Eclipse is known for producing high quality stuff.

How can EPF make Agile mainstream?

Agile development is growing in popularity, and as you make Agile development more and more popular big companies, as they adopt new approaches to something, are looking for certain things. They are looking for some level of stability, that what they adopt seams like it's validated, and I think that Eclipse gives a stamp of credibility, to whatever is in Eclipse. Because the process that Eclipse follows to develop products ensures that the Eclipse capabilities are mature, well tested and proven. Eclipse by itself gives credibility; if you have well documented Agile practices in EPF, that becomes more of a safe thing for large organizations to adopt.

Also within EPF we have more authority organizations working, very big companies like IBM, Telelogic, Bearing Point, Cap Gemini; and down to very small companies, and companies well known in the Agile community: ObjectMentor, Ivar Jacobsen International, Chris Armstrong Consulting, Number Six and so on, and these companies give credibility to the effort. I also think that if a large company adopts best practices, they need to make sure that their projects can be audited. At least some companies care; if they don't care today, they will probably care in 3 years, with Sarbanes-Oxley. It will be required by those companies that there is something documented on how they will develop software, that can be audited. This is something that EPF provides; it doesn't change how you develop software, but provides you with documentation on how to develop software. The last crucial reason why EPF can help making Agile mainstream is that when you roll out Agile practices to a large volume of people, you need to transfer tons of knowledge. And that knowledge needs to be transferred through training, it needs to be transferred through coaching, but we need to complement that with other means. And that's a great way of leveraging written-down knowledge to try to transfer the knowledge to a large volume of people.

Let's say a company chooses its own subset of best practices and they want to add their own to it and generate one consistent documentation knowledge base. Is that possible with EPF?

Yes, it is and that's what we would expect people to do. A lot of bright people are involved putting in practices in EPF, but in the end it's an adaptive organization, I want to make those practices my own. Some of them I might use out of the box, some of them I want to change, and some of them I want to write from scratch, perhaps we do testing really well so I use my own test practices. EPF allows you to do all of that. If I use, for example, Open Unified Process as my baseline and then change it, with the EPF tooling I would express my changes as a "change set." When a new version of OpenUP comes out, I can just pour those changes to a new version of OpenUP so I can benefit from all the new stuff without having to rewrite my changes.

So, what is so "Eclipse" about this process framework? It sounds like something pretty independent.

That's a good point. The practices you capture in EPF can be for any type of environment, for any type of project. So you can capture best practices for .NET development using EPF. The only thing that is "Eclipse" about it is that the actual environment - for documenting and modifying and configuring, choosing what best practices to adopt - is built on Eclipse tooling. But once you have chosen what practices to adopt you will then publish something to HTML and then you can use it with whatever is your favorite development environment.

The fact that it's Eclipse is an implementation detail, and a marketing thing

Right, well I wouldn't necessarily call it a marketing thing but I think Eclipse has a very powerful ecosystem and that's what we want to ride on because the practices are only as good as the community developing them; the reason Eclipse is popular is because it's good, and it's good because it's a very strong development community making sure that it's good, and it's a rather demanding user community that helps us making Eclipse products good. It's a self feeding system where we want to leverage the Eclipse ecosystem to capture the best possible practices, which will then be used by the broader community.

Where is EPF most needed? It sounds like small teams can easily just generate their own process and in fact might not need to document it because they are small teams. Where does a process framework like EPF become essential?

I think it's essential for any team to agree on how to develop software and they may choose to use EPF or not, but let's look at the alternatives. I can read for example one of my books, or one Kent Beck's books, or one of Jim Highsmith's books, and we can have everybody in the team to read a book, and then we have a discussion on what aspects we want to adopt and then we somehow write down how we should develop software, we'll make it up as we go. But in the end we all need to have the same reference materials, maybe read the same books and have a discussion about how to develop software. It's just another way for you to agree on how to develop software and the benefit here is that it is configurable and if you can add stuff by using a book it's a little bit hard to rewrite chapter 5 because you don't have access to the source file, and it's hard to take out different chapters. When you start to merge different books they don't fit because they are written in different styles. Here we have a consistent style so all the pieces of content typically fit together.

And EPF gives you an additional vehicle to define a joint set of practices. For example you say "well let's try out this unified process", you can download – instead of the tooling you can download just the website - you get an out-of-the-box website, and you see if it makes sense. If you think it makes sense as it is you can use it as a starting point and then just say "well we want to do this differently," you document the things you want to do as an OpenUP. After a while you notice that we really have some things that we want to change about it, and then you choose to download the EPF composer, which is a tool, and you just select some of the things you want to use and not use and then you generate a new website. And you have something, again, a little bit closer to how you develop software. But again you always need to discuss and agree on what makes sense or doesn't.