What about other methodologies and processes?

Over the years I have worked with many methodologies and processes and to be honest none of them are inherently bad. I have taken plenty of things from for example ITIL, Scrum and Kanban that I think is very good and that I see people feel that it add value to the way they work.

If we are being brutally honest here, then it does not really matter what methodology or process you want to use. The work is always the same. I know every organization always claim to be "unique" and that they need adaptation to whatever they implement, but I say that is a load of crap. The uniqueness has nothing to do with the work that need to be done, only how you choose to do the work. Ritualizing things does not change the work however, it just makes it more complicated.

It does not matter if you put decision points or gates in your process, as long as you understand that those are not part of the work, it is just a manifestation of your lack of control that you try to satisfy. A lack of control that comes from weak work processes and a proxy based organization where you have managers with for the sole purpose or controlling and relay information.

At the end of the day the work is still the same, regardless of your rituals.

 

Since all methodologies and processes are rituals of some sort you can use any of them in your organization. As long as you understand what the rituals add in terms of value and the cost, then you will be fine. Almost all methodologies and processes are about control and clarity. Make sure you focus on the clarity bit and find other ways to ensure trust in your organization.

You can also mix methodologies to have for example an ITIL based version for the business side and an Agile based version for the IT side. In fact, you can even have a mix of Kanban and Scrum side by side with Waterfall or RUP in the IT side and you will be just fine. As long as the connection between business and IT are solid with good portfolio management and requirement management, you can get away with most combinations.

When you consider methodologies and processes it is a tip from me to make sure that you place the control based versions, like ITSM and Waterfall on the business side and the clarity based ones, like Scrum and Kanban, on the IT side. That is because of the need those two areas usually have. You should also make sure that that need are set up as a requirement in the other direction. So business will require data from IT to be able to control and IT require information from business to create clarity.

 

The processes in his book is based on this need and I will do my best to describe the different parts of the process without the rituals and instead call it for what it is. This way you can place any methodology on to of it and see how it fit to the daily work that you actually do.