Agile Development with SDL Tridion

Last week I attended a seminar organized by Hinttech on Agile Tridion Development. The seminar and its participants discussed the use of Agile development methods when creating sites with SDL Tridion. Agile development is something more and more customers are asking for but then how does that fit into a Tridion project? Laurens Bonnema was on hand to give his view on Agile development and how it should and should not be used. Robert Quaedvlieg from SDL Tridion was also on hand to give a view on where Agile might fit into the SDL Tridion Implementation Methodology. The Implementation Methodology is essentially a SDL Tridion variant on the traditional Waterfall model. This is the traditional project methodology and lends itself very well to projects where we need to (or do) know what we are going to build up front. Agile tends towards situations where we do not know the requirements at the start. My aim here is not to explain Agile development – you need to read one of the many good books or even Wikipedia to get a good short explanation – However, I will lay down some very basic concepts so that the rest of this document is clear. Typically, you do not know the complete requirements up front and part of the Agile process is to define the requirements or backlog. These backlog items are organized into sprints and at the end of each sprint the development team has a working product (with the features worked on for that sprint). In theory that means you have something deliverable at the end of each sprint and, in my view more importantly, you are fully away of the progress you are making. There is more to it than that but the important factor is that the priority of development can be changed at anytime without having to go back and change a monolithic requirements document. At the end, you should have a product that is what you want at the time you want it. Rather than a product which you wanted when you made the requirements.

So how does a Tridion project fit into this?

Looking at any regular Tridion project, there are a number of things that look to fit well into an Agile process and others which do not. Some of the things that do not, I do not think every really could fit well into Agile development, probably because there is nothing to develop, more something to be worked upon. However, even those things can be injected with Agile juice to make them flow easily next to the sprints.

Ignoring the Tridion Implementation Methodology, I will outline some of the various parts of a Tridion project and whether or not I think you should approach them in an Agile (A), Semi-Agile (S) or Waterfall (W) way.

Organisational
Organisational aspects of a Tridion implementation are key to ensuring a successful project in the long term. Like any organizational structure it should focus on the long term and will be the foundation on which this and future projects are built.

What	How	Why
BluePrint Design	S	The BluePrint is the corner stone of any Tridion Implementation and is key when you move forward past the end of your project. As such it needs to be fully understood before it is laid down. That said, you can change it to some degree as you go forward, so once the initial design is set you can add to it providing you are prepared to accept the impact from doing so.
Security Design	S	Security is who has access to what and what they can do with it. It can be decided in the basic form up front, but after that it should be flexible to be changed and grown upon.
Business Processes and Organization	W	This is a question of understanding the business and how it operates (or wants to operate).
Support and Maintenance	W	Defining the support and maintenance processes tie into the Business Processes quite tightly.

Content Management
There are two parts to any CMS implementation, the creation of a Content Management environment and then the application to consume the content. In creating our Content Management environment we decide how we are going to manage content both functionally and structurally.

What	How	Why
Schema Development	A	Will change frequently during the development cycle
Template Development	A	Will change frequently during the development cycle
Folder/ Structure Group Setup	A	This supports the template and schema development
Application Development	A	Building Blocks are what makes the application. These will change frequently during the development cycle
Event System Development	A	Will change frequently during the development cycle
Workflow Development	A	We already will have decided something about our business processes in a waterfall model. Workflow will change frequently as we add more and more content types
Migration of other systems	S	Often a risk area, migration can be treated semi agile with ease. We know some requirements from the start, however, knowing all requirements can be very complex.

Content Consumption
Consuming the content is a very general topic; it can take any form from a simple .NET application to a MVC framework or webservice. The consuming application’s job is to take deployed content and present it to the user or another application. It is very much a technical coding exercise

What	How	Why
Deployment Extensions	A	Deployment Extensions, for example, a Google search integration, can easily be part of a sprint
Consuming Applications	A	Often the bulk of a development activity is here and this can easily be done in an Agile way

Infrastructural & Integrations
These sorts of activities tend to involve a large amount of people and a very rigid process model. It makes agile work in this area very difficult and you would generally meet stiff opposition.

What	How	Why
Infrastructure Design	W	Needs to take into account strict processes and design parameters. Often hardware cannot be purchased until a full design is in place.
Installation	W	This is an activity that can sometimes be done in sprints (e.g. hardware, OS, CMS, Modules etc), but that is more from practicalities than being designed to look like sprints
Configuration	S	Configuration of servers should be timed to be worked on post sprint. Configuration and setup adjustments from the sprint can be implemented directly so that the resulting product from a sprint can be put into production. To do this for every sprint would mean that the hardware & software installation should have been completed before the first sprint.
Integration Development	A	Most integrations are development activities and therefore can easily organized into sprints.

Additional Thoughts
Many standard engineering practices should be implemented that will help you in being agile. These practices stem from traditional development practices but are often overlooked. What is important in each sprint is that all the work you have done has broken nothing from any previous sprint, so structured testing can help you achieve this. Unit and UAT testing can both aid the development process and ensure a quality product. UAT testing can also ensure that the content management environment will work well for the content editors. Getting the editors in and letting them have a play early on might just ensure that they accept the application when the last sprint is complete.

Overall you need to use common sense (in this I very much agree with Laurens). Agile is not the way to solve all evils. Not only are some things just not possible to do Agile but some people cannot (yet) do agile.