Deborah Hartmann for InfoQ: I am here at Agile2007 with Hugh Ivory, a Director of the DSDM Consortium and the mentoring coach of the DSDM method. Good morning Hugh. Can you tell us a little bit about DSDM please?

DSDM is a framework for making Agile business change. The DSDM Consortium has been around since the mid '90s, and we are a not-for-profit organization, and we are responsible for the development of the method. The method is developed by practitioners from all types of organization. Back in 1994 the first version of the method was developed by the coming together of a group of people from a number of organizations, both corporate organizations and service organizations, like IBM, British Telecom in the UK and British Airways, very much an European and UK based method. We like to think of ourselves as the grandmother of the Agile methods, given that we have been around for the amount of time that we have, and that we have been developing the method. The big news from us at the DSDM Consortium this year at Agile 2007 is that we are now an open framework. If you have been afraid of doing a little investigation and trying to find out about DSDM, because of the closed membership model that we had in the past, then you need to look again. Because now we are opened, all the materials that we have built over the years are freely available for people to view and to use on our website: DSDM.org

I heard that there are changes that have been going on in the Consortium in the last 18 months or so. What have you been doing and why?

18 months ago we needed to open up the model. The reason we needed to go to an open model is obviously that if people can't see something, they can't find out how good it is, and they can't use it. The other big thing that we have done, now that we are opened, we need to make the information that we have more accessible and more understandable for people. We've reframed our method now and we have released our latest version which is called "DSDM Atern". And DSDM Atern is available on our website dsdm.org. We have this pocket book publication which is almost like the quick reference version of the method, which is also available for sale on our website.

Hugh, please tell us more about the changes that have been going on.

Obviously we are opened for 18 months now, and in April this year we released the latest version of the framework which is DSDM Atern. What we have done with DSDM Atern, we have always had a business focus in DSDM, but that business philosophy has been hidden a little bit in the method. What we have done with DSDM Atern is to take that business focus philosophy and bring it up front and center. We have also used the new release to show people how the method is structured, and again that would have been slightly difficult to see before. Our method is structured, we have that business focused philosophy, it is supported by a set of working principles, we have 8 principles, really specifically focused on delivering what the customer really wants, delivering it on time, making sure that we have real collaboration between all the people working in the team, that we continuously communicate with all the stake holders during the project. We have 8 principles which support that philosophy. People working in teams, if they work and live those principles, then that helps them to deliver the business value within the framework and within the change that they are working in. Supporting the philosophy and the principles we have four pillars: Practices, which is around the techniques that we use; People, which is to set and define roles and responsibilities for people working in the teams; Process, which is our defined framework or life cycle; and supporting that process, a set of Products which we expect to be delivered at various stages of the change.

Tell me more about your "pillar" of Process.

Ok, the pillar of process is our life cycle, effectively. What is different about our life cycle from some of the other Agile methodologies is that we do a piece of work up front in our feasibility and foundation stage. Our process runs from feasibility through foundation, and then into iterative engineering and exploration and finally deployment. So up front in the feasibility and foundation stages, we are setting a firm foundation, and this is one of the things that helps us to deliver business value. In setting firm foundations we are setting foundations around what the business objectives are and an entire business context for the project and the change. We are setting foundations that contain: business objectives, a business model, business architecture, an outline solution or technical architecture, and a set of outline business requirements. We also have a key product at the end of our foundation stage which is an outline plan. And that outline plan is a plan of the time boxes or ... perhaps in the Scrum terminology, that we would run during the design and development changes of the life cycle. Having come through that foundation stage, we can then get into a series of time boxes, iterative almost, in Scrum terminology they would be Sprints, iterative stages of further exploration around the requirements and engineering, testing and delivery of the solution. And again you can use Scrum at that stage, or you can use XP to actually do an exploration or further design and engineering, or traditionalists might use Use Cases as part of the design or exploration stage and then standard engineering practices.

That's interesting. I know we talked about wrapping XP with Scrum because they are complementary, are you suggesting that DSDM adds additional practices or focus beyond what Scrum provides?

We believe that DSDM provides a really strong business wrapper for either Scrum or XP. The version 4.2 of the method, which was the release previous to DSDM Atern, was actually a combination of DSDM and XP. So running DSDM around the business modeling and the governance parts of the project and the project management, and then using XP in those iterative boxes where you are actually doing exploration and engineering. I am not hugely familiar with Scrum but my understanding of Sprints is that our time boxes in those explorations and engineering stages are like Sprints. We don't prescribe that you have a particular length of time to do any iteration, rather we allow the prioritization of the business functionality to determine the size of a time box. And over the duration of a project, in a six month project, we could potentially run seven or eight time boxes. Again, depending on the need and what we need to deliver in particular times.

You brought some materials with you, something that looks like a quick reference and a diagram. Do you want to show us the diagram?

What I have been trying to explain in terms of our life cycle: at the top part of our life cycle we have the business foundation, the orange piece that is here at the top. The exploration and engineering phases are shown here, like iterative cycles of design and engineering. Obviously depending on how you work you might do some design on some features and then engineer them, and deploy or release them or you might do an exploration and engineering as part of delivering a particular feature. So you can run these two parts of the life cycle in any sequence that you like. You can run as many of them as you wish before you deploy anything and it depends on what really works on your project.

Thanks, so you talked about what you called the pillar of Process, and you had three other "pillars".

The three other pillars are... well the key one that I would like to talk about is the pillar of People, which is a lot of responsibilities that we define. It is one of the other things that help us to deliver that business value. We are focused on assuring that the business retain responsibility for the work that we are doing within the project and that's reflected in the roles. So we have a specific role for a business sponsor and we define what the responsibilities for the business sponsor are. In organizations that I have worked in, there are various ways in which people do governance, from ... committees etc. In DSDM we are very focused to say that there must be one person who is responsible for delivering the benefit and that's our Business Sponsor. We also have the role of Business Visionary. The Business Visionary is the person in the team who is the sponsor's change agent, the person who is responsible for guiding the team in terms of where the business needs to go and how this change needs to affect the target audience or the target business.

The Business Visionary has a very important role. We also have the role of the Business Ambassador. If we are running a project which is delivering a number of streams and we may have a single Business Aisionary who is responsible for ensuring that the teams running each of those streams understand what the business vision is, however in each of those teams we have looked to have a role called a Business Ambassador. The Business Ambassador is almost a subject matter expert for the business, but more than just lending their expertise to the project we look for them to be committed, and very difficult to have the right person committed for all the time, so we look for them to commit at least a percentage of their time. They become a formal member of the team, and their role is not just to bring business knowledge and expertise but also to bring an understanding of what is going on in the project back to their stakeholders in the real world where they work. And that helps us with our principle of continuous communication. We have a number of other business roles, one that we call Business Advisor which would be for situations where the Business Ambassador can't do it all, or doesn't know it all and needs some help from people within their organization, that's the Business Advisor. We've had those roles since the early days of DSDM to help us to drive at the business value.

I find these business roles interesting. I see in your diagram here they are marked in orange: Business Sponsor, Business Visionary, Business Ambassador, Business Advisor. Are these new in this revised version of DSDM?

Those roles have always been part of the framework and methodology. What we've done with the terms is we have made them clearer I think. We have also added a further role, which we call the Business Analyst role and we have taken a lot of feedback from people over the years and from practical experience we know it is a role that is important and the person that helps that collaboration between business people and technical people. We have been very careful about the way we defined this analyst role. We want the Business Analyst to be almost like the third point of a triangle between the business and IT people; we haven't designed that role to be a barrier between business and IT, or to be an excuse for the business not to be fully involved in the project. An Atern Business Analyst will be working collaboratively and will be facilitating a conversation as opposed to be the barrier between two people having a conversation. And again, through the use of rich communication methods: modeling etc. That's a new role in Atern.