Becoming Riders of Paradox

ThoughtWorks Live 2011Last week I had the pleasure of attending ThoughtWorks Live 2011 in London’s St Martin’s Lane hotel. The conference, entitled Continuous Delivery: Push the button, was a showcase of ThoughtWorks thinking on how to become truly agile through the implementation of Continuous Delivery and Continuous Deployment.

Among the speakers were heavyweights such as Martin Fowler, ThoughtWorks Chief Scientist & Roy Singham, ThoughtWorks Founder & Chairman – positioning ThoughtWorks as not only global experts but as global educators, both practically and aspirationally.

Riding Paradox

Paradox Horse
"Paradox" by Michael Bergt

A real favourite for me was a presentation given by ThoughtWorks Studio’s Managing Director, Cyndi Mitchell on Adaptive Leadership: Accelerating enterprise agility, based on Jim Highsmith’s whitepaper of the same name. In the presentation Cyndi discussed a number of challenges that leaders face in being adaptive. The real eureka moment for me, in both the presentation and the whitepaper, was the concept of Riding Paradox. We were encouraged to be ‘And’ rather than ‘Or’ leaders, inclusive of elements from multiple methodologies that can add value and work together for the benefit of the project. No one methodology has it 100% right and we should look to take aspects of different practices and thinking and incorporate them more. A quote from Rotman summed it up well “Integrative Thinking is the ability to constructively face the tensions of opposing models, and instead of choosing one at the expense of the other, generating a creative resolution of the tension in the form of a new model that contains elements of the both models, but is superior to each“.

Highsmith discusses in his whitepaper “The paradox horse seems always to be going in opposite directions at the same time. Furthermore, the leader is exposed, drawn by the traditional norms of many organizations in which it’s OK to be wrong, but not OK to be uncertain“.

As a Business Analyst I often find myself in a similar position, for two reasons. Firstly, due to the nature of my role I report into my Managing Director for the purpose of sales targets and planning, while reporting into my Technical Director for the purpose of scoping and quality assurance. It can often feel like attempting to serve two masters, serving two areas of the business who sometimes have opposing expectations.

Secondly, clients can sometimes be prescriptive about the methodology that their software project should use. This is rarely based on thoughtful consideration of stakeholder needs, rather that the client has heard a buzz word or has used that methodology on a previous project and feels safe with it. As an example, I have had clients come to me and say “We want to use Prince2”, for no other reason then a third-party advisor has suggested it would ‘be best’. This leads to lengthy planning and scoping phases of work up-front which the client is happy with. However, once the project moves into production the development team opt to take an agile approach to the job, breaking down my long specification into chapters – renaming them iterations and delivering little and often.Watch Full Movie Online Streaming Online and Download

At the same conference one of the speakers, Dave West from Forrester, coined the phrase “Water-Scrum-Fall” that perfectly describes this idea that scoping happens, the development team run off with an agile approach and then the final mile of the project reverts back to a very formalised sign-off process.

I’m excited by what I’ve heard at the conference and challenged to implement changes in my working practice. Lets hope I can attempt to ride paradox without falling off!

Rotman. (n.d.). Integrative Thinking. Retrieved from Rotman Business School [online]. Available from: http://www.rotman.utoronto.ca/integrativethinking/definition.htm

Highsmith, Jim. 2011. Adaptive Leadership: Accelerating enterprise agility [online]. Available from: http://www.thoughtworks.com/articles/adaptive-leadership-accelerating-enterprise-agility

Image from: Jim Highsmith: “And” Leadership.

Stakeholder Interviews

This week I have been revisiting the topic of Stakeholder Interviews, in the hope to refresh my own thoughts on the subject. I’ve found some great resources that I would like to share along with a number of hints and tips that I have from my own experience of undertaking Stakeholder Interviews. I should note that this post is not intended to be a definitive list of potential questions, more a guide to those who wish to understand how to undertake Stakeholder Interviews.

Firstly, what is a Stakeholder Interview? Well – I couldn’t find a book definition to reference, so I have made one up:

An interview between a Business Analyst/Project Manager and pre-identified stakeholders of an organisation or department, for the purpose of understanding a current system and/or eliciting requirements for a new system.

Like many interviews that you will have taken part in, either in seeking employment or helping in market research, they follow what is known as a structured interview style.

Bryman & Bell (2003) describe the purpose of the structured business research interview as being “for the interviewer to elicit from the interviewee or respondent, as he or she is frequently called in survey research, all manner of information: interviewees’ own behavior or that of others, attitudes, norms, beliefs and values.

So now that we know what a Stakeholder Interview is, how do we undertake one? Thanks to Brad Botz over at BA Mastery, I came across a great podcast that he put together on the same topic. Brad suggests breaking down your questions in the following way:

Function
– How do you use this software? What are some examples of what you do regularly? Which actions do you perform the most?
Frequency
– How often do you perform these tasks?
Preferences
– What do you like best about the software?
Problems
– What problems do you run in to on a regular basis?
Expertise
– What are the tips and tricks that you have learnt? Are there any workarounds that you have discovered to make the tasks easier?
Miscellaneous
– Have I missed anything? Is there anything that you would like to show me?

It is important when to stay on topic with this last set of questions. Try not to allow the stakeholder to deviate from the original purpose of the interview and remain positive about the system, even if their own concerns or experiences are negative. It’s also to remember to let the stakeholder follow the course that they wish to take throughout the interview. While it is appropriate for the interviewer to help guide the respondent, encouraging them down a particular route is not appropriate and should be avoided where possible.

In Summary

Advantages:

  • If you build a rapport you are going to get much more acceptance of the project, not just through the interview but throughout the life cycle of the project
  • Its easy to conduct interviews – easy to extend them if they overrun and easy to record their findings

Disadvantage

  • It can be difficult to obtain consensus if there are many stakeholder
  • Follow up questions are heavily reliant on the interviewers experience of the interview process and their understanding of the domain they are working in
  • You may lead someone accidentally

Bryman, A. and Bell, E., 2003. Business Research Methods. New York: Open University Press.
Clash Of Clans Cheat And Hack Tool