Disciplined Agile Delivery - Part one

So here I am. Back again from the United States sitting at my desk at home watching the rain and still wearing off my jetlag. Still all excited from the IBM Innovate conference. Loads of nice presentations and people.

The thing which keeps me thinking about is the disciplined agile delivery book which Scott Ambler and Mark Lines wrote. The book describes a framework for software development.  Or, better said, a framework for getting solutions out the door by software departments. So why am I all excited about it?

Framework instead of methodology

So other methodologies like RUP are really big and advocate a certain process rather in depth although they say you need adjust the process to your environment. Methodologies like Scrum make you adopt a narrow process which suppose to be a kernel on which you grow your own process. It’s small and makes you alter it to your environment right away. Discipled Agile Delivery (DAD) is somewhat different. It doesn’t impose a process rather strictly. It’s describing a somewhat combined view. It captures the best parts of a number of methodologies and techniques and tells which are great to combine. It also gives lists of options from which you can create your own process. So you can create your own process. This makes it usable for a large scale of organizations. But not immediately. They still need to pick their parts and create a process. Or maybe better said, pick the parts, evaluate the parts and adjust/improve accordingly.

Terminology

So what is about calling things daily stand-up meeting, sprint and scrum master. I always had a feeling by using those words people tend to think it’s something completely new, although the daily meeting to coordinate and synchronize the team members is nothing more than a daily coordination meeting. The terminology used by DAD is just some more down to earth I guess.

The problem of big organizations

So the bigger the organization, the more specialized departments and people are gonna be? You will get a enterprise architecture department with people in it whereas in smaller organizations this maybe was the responsibility of a senior software engineer. DAD does not ignore the big organizations but describes lots of possibilities to get the people and team more integrated in the rest of the organization and tells us it’s very important to get integrated with the organization to get the job done.

Talk in goals instead of deliverables

So instead of telling we need to create a document containing X it just tells us to make sure you target the goal. So spreading the vision and reaching agreement on it is something you can sometimes just do by pulling all stakeholder in a room and do a two hour envisioning session. In small endeavors this is the best process.

Just some small things which I love about the book. It feels more practical and down to earth 🙂

Expect some more blog posts about it…