Shane Hastie von InfoQ interviewte Kent McDonald und Kupe Kupersmith an der Konferenz Agile 2014. Aus meiner Sicht zeigt dieses Interview einige Prinzipien von LOA - ohne aber direkt auf LOA oder SF als "Markennamen" Bezug zu nehmen, was ja auch in Ordnung ist...
Das Interview findet sich ==> HIER, samt dem Tramscript, welches ich hier zum einfacheren Lesen kopiert habe:
(Kent McDonald and Kupe Kupersmith are two of the principals of B2T training, with extensive experience in training and supporting business analysis and product ownership roles in organisations.)
Good day. This is Shane Hastie with InfoQ. We are here at Agile 2014 and I am talking to Kupe Kupersmith and Kent McDonald. Kupe, Kent, welcome. We know each other well, but it is probably worthwhile introducing yourselves for the audience, if you would be so kind. Kupe, can we start with you?
Kupe: Sure. I am Kupe, president of B2T Training. Kent is my business partner, along with Tina Joseph, who is not here at the conference with us, and I have been primarily in the BA Space for 15 plus years and a lot of software implementations over the years and now I have now kind of worked up to leading B2T Training as the president and excited to be here with you. Thank you.
Shane: Cool. OK.
Kent: My name is Kent McDonald, right now I am the VP of product development and Agile practice lead for B2T Training. So, a lot of working with developing curriculum, writing, doing a little bit of writing both from a training class perspective and also a book of which, hopefully, we are going to talk about a little bit later. I really enjoy helping people tell their stories and I also do a lot of BA Training. My background is business analysis, project management and quite a bit of involvement in the Agile Community over the past 10 years.
Shane: Indeed. You are both here at the Conference and you actually gave a talk on a lovely title – “Get the liars in the same room”. Please tell us about it.
Kent: The premise of the talk, it was actually targeted towards product owners who find themselves in the situation in which they have multiple stakeholders, who for whatever reason, do not necessarily always agree. So, we will be giving a couple techniques from a couple different places to help get the stakeholders’ alignment and get some sort of agreement as far as how we can lead the teams forward. We used a couple techniques. One of them was decision filters which came from friend and co-author from a previous book – Niel Nickolaisen – came up with that. Then we also talked about some improv techniques that help facilitate that conversation along and we used specifically the idea of “Yes, and”. Kupe can explain that a little bit more.
Kupe: I’ll go into the details that. One of the pieces of my background that I did not key on earlier was that I was an improv actor in Atlanta for years, in the ‘90s and realized that, at some point, I had to make a determination: do I keep doing improv acting and make about 50 dollars a week or do I continue in the system/ software development arena which paid a little better on the system side so I continued to do that but realized that improv was the thing that helped me be a better team player, helped me get over fear of failure. That is something we constantly have to do. So, when you are up against conflicting requirements and conflicting needs, you have to have positive conversations and improv is all about positive conversations and moving things forward.
Shane: So “Yes, and”
Kent: Yes, and. Good segue – you could be an improv actor yourself, Shane. Good. So, the concept of “Yes, and” – the mother of all rules in improv is no denying. So, you never deny. Never tell someone – whatever they say, you have to take it as reality and add on to that. The premise of improv is taking an idea and building upon that with the actors and coming up with a great big idea. So, do not deny along the way, kind of add on to it and make it bigger and broader. It helps creativity. So the concept of “yes, and” is saying “Yes, I accept what you are saying. It is reality. And now let me add something to it”. And the other actor would do the same back to you. So, for teams and business professionals and people, it is the conversations we have all the time. Somebody comes with an idea and if you say “No” all the time or “Yes, but let’s try this” you are denying them and what happens when you deny someone too much is that they get defensive, they stop adding comments. If you say “No” enough, it is like your kids or anybody, if you’re a manager and you say “No, no, no” to your employees day in and day out, finally they throw their hands up like “OK. Just tell me what you want me to do and I will do it”. That is not the conversation you want to have. So, trying to get the people in the audience today to get into that mindset of saying “yes” and really accepting so that they can constantly keep those creative juices flowing.
Shane: How do you manage then scope change, scope creep, things going out of control with “Yes, and. Yes, and. Yes, and”
Kupe: Yes. The one thing you do not want to do is, especially with stakeholders, is “Hey. Can we add this feature? Can we add this story” to say “Yes, keep on doing it”. So, it is basically you do not have to agree all the time, but it is about keeping the conversation flowing. So, if someone comes and says “Hey, we want to add this feature to this print” or “this story to this print”, one that wasn’t there. So, OK. To talk to me, you are not really using the “Yes, and” concept, we are using those words, but like “OK. I understand you want to add those features to the session. Let’s talk about it, help me understand where that story fits in with the other stories and we have a time box so which one of these other stories can come out? Is this one more important than the other ones or can it wait?” So, it is not always about agreeing, it is about asking questions and clarifying questions and keeping the conversation moving forward.
Kent: And the other technique we talked about in our session- it actually covers a lot about helping with scope creep is decision filters and what those effectively are, they are really straightforward questions that teams can use to decide “Do we include this, do we not? Leave it in, or take it out?” So, it is really helpful in planning, but certainly helpful throughout the way in the course of an iteration, if you are trying to make decisions: “well, if we do that, is it going to help us do this?” So, those decision filters are really straightforward, simple statements about what the overall goals of the efforts are. It helps the team remember that, it keeps it consistent and it encourages people to throw it up on the wall so it is there as a reminder. You can always reflect back to it and say “Does it make sense based on what we are trying to get accomplished?”
Shane: Great. So, just starting with the end in mind.
Kent: Starting with the end in mind. Yes.
Kupe: So what does success look like?
Kent: Well, I’ve had the opportunity to experience product ownership from a lot of different perspectives. I actually am one for some stuff related to the Agile Conference. So I get the experience of doing that and doing all the things I tell everyone else not to do. So, I am good at not following my own advice. But, then I also work with a lot of business analysts who are being put in the product owner role, not necessarily with all the decision-making authority that some people think that the product owner should have, but more as kind of that person that is facilitating the decision-making to happen and it is usually in the situations that we talked about in our session today where there is a lot of stakeholders that have a lot of vested interests but there is no one clear owner.
So, what you have to do then is to really have some form of coming up with those decisions so the teams themselves are not getting distracted by having multiple directions. They always know this is the one direction they are going and all of the messiness about coming up with that single direction then falls on the product owner’s shoulders. And I am seeing that happen a lot, especially in organizations transitioning now that are larger, I deal a lot in internal IT situations and there are several cases there that do not have one particular person that owns any given thing. It is a lot of different business units are impacted. So, you have a lot of that where you have the product owner is not the decision-maker, they are the ones that make sure that decision happen. So, that is certainly a big trend from that perspective in product ownership.
Kupe: Yes. I think the only thing to add that Kent’s the expert in this. I think what we realized in the product ownership space is the analysis skills that in a traditional environment were on the BA, within the sprint tying together what in a traditional team the BA was doing where maybe a BA now is rolling up into the program level and doing some work and when you have that product owner, whether it was a BA or someone from the business, they need those analysis skills where they are not documenting as much and having – it is not about the documentation piece of it, but those analysis skills that people have on the team that is falling on the product owner space now.
Shane: Kent, I know that you are writing a new book. I think it is called “Beyond Requirements”. So, tell us about it.
Kent: Right. The title is “Beyond Requirements: Analysis with an Agile Mind Set”. It is actually out on Amazon listed for Presale. So that is a little bit of pressure, subtle pressure, by the publisher. What it is focusing on is kind of what Kupe is talking about. It is that idea of applying analysis skills, analysis techniques, to an Agile setting, but then doing them in an Agile fashion. So, it is one part of it and the reason I used the title “Beyond Requirements” it is really placing the focus on it is the analysis activity that you are doing to build that shared understanding, figuring out what problems we are trying to solve, figure the right solutions out, aiming towards deciding what is the right thing to deliver - or do we need to deliver anything at all? So, a lot of what it is, is actually taking ideas from analysis, from traditional business analysis and saying, applying – here is how it works in an Agile setting - and then also bringing in ideas from other places.
So, incorporating some thoughts from Lean Start Up. For example: even though I am focusing on, again, the internal IT space, there are still some concepts there, especially the idea of a minimum viable product. So, certainly, they are not developing products per say, but instead encouraging to say “Focus on something that you are really trying to accomplish and what is the smallest bit of that that you can do, deliver to get start moving in the right direction, towards what your goals are”. So, it is a mixture of a little bit of theory and bringing in some ideas from other areas. I have five case studies baked into there, that kind of show how those ideas morphed together and the last part of the book is actually a set of techniques, varying techniques talking about what they are, how you would do them, why you use them, when you use them and giving some examples. So, it is a kind of a nice mixture of some theory and then a lot of practical application.
Kent: In December.
Shane: Gentlemen. Thank you very much for taking the time to talk to InfoQ today. It has been really good to catch up and enjoy the rest of the Conference.
Thanks, Shane, for having us.