Recently I have researched a bit on how to make a SOA project succeed - and much importantly: Why SOA projects fail. Given that the best way to make speed is to avoid making errors uncovered by others a Google search for "SOA Antipattern" reveals all kinds of goodies.
There are a lot of repeated do's and don'ts around many of which are quite obvious. For one: "Don't dive into a SOA project with a Big Bang refactoring of all your infrastructure". Agile chapter 1, page 1 (perhaps page 2): Don't do big refactorings at all. There is no such thing as a big refactoring if you have committed to the agile way of doing software development.
But: There is one argument which isn't quite so obvious and can be counter-argued with theoretically. The argument goes that the owner of a SOA business case should be a business executive in the area that the SOA service should be serving. Why is that? Well: For one: It commits the business to take responsibility for the IT they want, a.k.a: Having the business own it's own IT business cases stops having IT delivering good, stable and reliable products which doesn't solve any problems.
Having experienced a bit of problems lately in our Scrum process I came to think that there are a few similarities between the two. You need the business present on a daily basis taking responsibility of the development of the product you are about to deliver. The key elements which are critical for the Product Owners to be mentally involved in a Scrum team are (in my opinion):
- Force the Product Owner to come to your Daily Scrum. No excuses - they must show up and listen to what you have to say. They might not understand everything but the team needs the Product Owner present to ask questions and for guidance.
- Speak their language. Never say "This feature sucks because it requires me to make serious changes to moduly Y and X" but "That sounds like a neat feature- and it will unfortunately take X days and hours to implement". They don't understand technical complexity but the PO has a deep respect for "Return on Investment" which means the time spent on a single feature by the development team.
- Make them test every time you commit something to the mainline /staging environment. No excuses. If the PO haven't tested an implementation the PO can't say it is Done and your team haven't improven the velocity of the sprint.
By following these steps you know that the Product Owner knows what's going on and can be held responsible for - well - IT projects that doesn't solve any problems in the business domain ;o)
The best way to ensure that the PO does in fact adopt to these few guidelines is to not let the IT departement drive the Scrum process. It can't be stressed enough. Any kind of process change and mindset change must ideally come from the Dark Knight of Evil, a.k.a the president of your organization. If i.e. SCRUM is only implemented within the IT departement you never get the Product Owners to adopt your philosophy because the live in a different world with a different mindset than yours. That mindset might not leave room for i.e. half an hour of testing when the Scrum Team says something needs to be tested. It is probably not because the Product Owner doesn't know or can't see the value of testing - but if the Product Owner is being overruled and assigned other priorities by his/her boss the SCRUM process fails because the team is unable to show progress to the rest of the business.
It's all a matter of prioritizing time - the SCRUM team and the Product owner needs to have the same priorities and only the Dark Knight of Evil mentioned above can reassure that the priorities are the same for various Product Owners and the various development teams within an organization. That's why the biggest antipattern in my opinion when implementing SCRUM in an organization is to let a single departement drive the mindset change through. It'll never be a good experience for all parts and inevitably the SCRUM process will be questioned again and again.
Opslag
