I spent couple years working with business-IT issues. Help development teams to understand customers’ needs in order to work more effectively.
I am truly convinced that keys to the software craftsmanship are linguistic skills, so have wrote the book on the subject in Polish.
Currently I am working on Conversation Patterns for Software Professionals which are techniques for having quality conversations with stakeholders.
I am blogging at http://mbartyzel.blogspot.com and tweeting @MichalBartyzel.
1h - Slides+Speech
We have created lots of tools which are intended to structure fuzzy or unclear business needs. We have created use cases, user stories, acceptance test and so forth.
Although the tools above were designed to improve collaboration with customers , we use them to hide ourselves from business people. Instead of talking to an individual we tend to complete the forms.
The issue motivated me to start working on Conversation Patterns for Software Professionals, which are techniques for having better conversations with stakeholders and drilling their real needs. The Patterns makes soft skills more technical guy-friendly and easier to apply.
I do believe that quality of answers you get attests to quality of questions you have asked. So, which of the following questions will give the most valuable informations?:
'Do you want to add new items to the backlog?' 'What of new items you want to add to the backlog?' 'What of new features you're going to use next week?' Not sure? Join this presentation and verify questions you use to ask.
- Learn that writing User Stories, Use Cases, Acceptance Tests and so forth are NOT a goal of business-IT collaboration
- Learn that one may write full-featured US, UC or AT and don't understand stakeholder needs at all
- Learn that all tools above are intended to have better conversation
- Learn that 'a stakeholder needs' is very strict term and it might be one of: 'expected benefit' or 'problem to be solved'
- Learn how to visualise a conversation flow as a Conversation Structure
- Learn how to drill an 'expected benefit' when a stakeholder gives a 'problem to be solved' and opposite
- Learn how to make a practical use of above by working with User Stories driven by stakeholder needs