1. Very briefly would you mind introducing yourselves?
Ellen Gottesdiener: I guess I will start. Thanks for having us here, we really appreciate it. My name is Ellen Gottesdiener and I am the founder and president of EBG Consulting and what we do is basically help organizations, enable them to create better products and better teams. A lot of our focus is on helping stakeholders collaborate, so business and technical teams collaborate to get their requirement needs defined and to decide and to build the right product at the right time. We have been doing this for many years and we basically are working in three practice areas. We work directly with teams, we also do coaching and mentoring and we do training.
So these practice areas integrate together, so we are always learning from our onsite engagements and pulling that into our training work. The spirit or mission of what we do is around is helping those diverse stakeholders collaborate and defining the right thing. We're here at the Agile conference and a lot of the focus has always been on the product and the software, but it is really important to make sure we are building the right thing, so that has been a key focus area for us.
Mary Gorman: You forgot to mention the books.
Ellen Gottesdiener: Yes. I've written a couple of books. "Requirements by Collaboration" is the first book I wrote and it is about getting those diverse stakeholders together and to collaborate defining their needs. It's both about the head and the heart, doing that work in a purposeful way. The second book I wrote is "The Software Requirements Memory Jogger" which is everything you wanted to know about the software requirements you were afraid to ask. That's became very popular to a lot of people as a "go to" guide.
2. Every business analyst I know has one.
Ellen Gottesdiener: I am very proud of that because I really wanted to build something really practical and I'll share with you something that Mary and I were working on in that same vein.
Mary Gorman: I am Mary Gorman. I work with Ellen at EBG Consulting; I have been working with you for five years now. I have a background starting as a programmer many, many moons ago and I have been doing requirements work, requirements analysis coaching, mentoring, product engineer for 20 some years. I have got a real passion around helping folks understand how they can use a variety of skills and techniques in a collaborative way, which is very aligned with Ellen's focus in defining those product needs. We speak at conferences such as this and we'll tell you a little about our session yesterday which was very interesting, very diverse.
I also have been very involved with the IIBA [International Institute of Business Analysis] Body of Knowledge and helped in creating 2.0 and all of that is integrated with that community. What I find exciting here at the Agile conference, is to try to network more with a team aspect, where the team will together understand those product needs. Somehow being able to talk with a lot of the developers and testers who are looking for ways to try to better understand and better collaborate. That is a great opportunity to talk with those folks.
Ellen Gottesdiener: Another thing that we have been doing is doing more writing and we'll talk about some of the things that we've published lately around games and simulations, which is something that we have always done for many years as a part of our training and engagements. Mary has written a really great article on that, maybe you want to mention, maybe is a good time to mention that.
Mary Gorman: Early in August it was published in StickyMinds.com about using games to learn as well as to do the work. That was 800 or 1000 words. In addition, what we tried to do is to link that to the Agile Manifesto and Agile practices to talk about how we can do this more effectively. It has been fun. Actually, tomorrow, in Open Jam, we are running the game "Backlog is in the eye of the beholder." It was fun to create it and it's been really exciting to watch how people are using this type of learning, these types of games, to be able to grasp some pretty challenging concepts.
Ellen Gottesdiener: You created that game at the Agile Bazaar Games Conference.
Mary Gorman: In May 2010 you ran that open space facility.
Ellen Gottesdiener: Yes, I facilitated the open space, which was the full day, the last day. That was a three day event, I believe. One of the key things that happened there was that this group Mary and Mike Sahota got together with some other folks and worked a full day in designing this game and testing it. It was amazing to watch the process, the actual generative process they went through.
4. Either client engagements or the investigation, call it research that you have been doing?
Ellen Gottesdiener: Speaking of the way we like to do, our practice work to ourselves to always retrospect our engagements and build retrospection into the engagement, at the beginning of the engagement. We are seeing a lot in terms of transformation with Agile, a lot of variety. We work with traditional teams and Agile teams, and everything in between. The adaptation strategies that different take is quite interesting. A lot of our clients are medium and large size clients. Much of Agile when we observe in terms of practices around requirements, a lot of Agile is a really change management, is a major organization change management activity.
It may take place at the team, or organization, or product level, your product company. Addressing those change issues are just as important (we observed) as also helping people with skills whether they have them already or whether they need them, analysis skills, to leverage those skills, because they don't go away. One of the observations I might make is that there is some art and science in calibrating your practices with Agile. Some things you have to kind of have a retrospective attitude and an inspect-and-adapt attitude and try this and make sure to reflect. In many of our engagements we try to bring that practice to our clients so that we can leave the engagement.
Mary Gorman: We had a recent situation, where there was a team that had been very successful in building product using Agile. They have been doing it for about five years and they were very good at that. What they weren't as good with is trying to be able to clearly identify the requirements. So working with these folks and trying to integrate, getting away from the titles, who has a particular title and that means they are qualified to do something. Really focusing on what the work was that had to be done, and the work was to be able to slice the stories to a size that would be appropriate for the development team and their very short timeframe.
That was sort of like people tossing the ball over the wall – "That's what you're supposed to do. o, that's what you're supposed to do." Working in concert with those folks the product owner, some analysts, some testers, some developers, and to leave the titles outside the door and to work in a clinic fashion that we would be able to help in a collaborative way to get to that right size story. We have seen that happen, it is a pattern. Trying to help organizations to be able to take that, it doesn't matter what hat you wear or what the name on hat is, but together being able to elicit and analyze and to find those at just enough level of detail, just when they need it. Seeing that over the years has almost required us to be able to say "How can we summarize this? How can we share this?" That was a recent article that we wrote.
Ellen Gottesdiener: Right. Slicing is the feature issue of better software in the July/August on "Slicing Requirements for Agile Success". We talked about a strategy that is basically the meta-pattern is expand and contract with a decision maker product owner customer, making decisions on options for the requirements all along the way, doing this in a collaborative way.
Mary Gorman: The options to mention, it's been really powerful and I love Chris Matts' work on that. The ability to be able to share with the business, actually not share is the correct word, it's really more to allow the business to quickly understand what their options are, prioritize them, narrow it down, move on and it's the fact that they are able to be heard, they are able to be able to share with the development team. This is a higher priority option for me. The development team coming in and saying "If you want that higher priority option, maybe a different user role is a higher priority option." Here are the implications for the technical perspective.
They are able to have those conversations much earlier and it is the pre-work that would be done, part of the work ahead that would not stall them. One of the teams, they had a chronic problem, where they just could not finish the work. It was always work-in-progress, and they got carried on from one iteration to another. Then, using this options approach was a way for them to break through. In a group, they reached that consensus, both from the business value perspective as well as what the technical implications were.
Ellen Gottesdiener: I think another pattern that we see a lot too, is that in organization's transitioning to Agile, they focus very much on "What we are going to deliver now in this iteration or release" - what we call the "now view". And that is good and appropriate, because the team needs to learn how to engineer the product, collaborate with the costumer, do the start up work and get into a flow. But then, usually after three or four iterations, if they are using a time box approach versus a Kanban approach, in either case after some time they get a pattern of delivery, then they are starting thinking higher level value.
Then they are thinking of what's coming up doing a little more release planning, what we call a preview, and then the big view, the product road-map view - "What's the big picture?" We may have done a little bit of that in a lightweight manner, a vision, these are the features that are high level. But once they get in flow this becomes much more important than the collaboration with the product owner, the product management, business customer community becomes really important. We've come up with using good practices, a bunch of tools, techniques, models that you use at those different levels of granularity - big view, preview, now view.
You continually iterate and refine those and adapt those practices to the domain as well, which is another pattern. You have to pick the right tool. I'm doing the talk on Thursday "Beyond user stories" and finding missing links in the product backlog, not everything is a user story or needs to be in the form of a user story to express the product needs. This pattern of the big view, preview and now view is another one that we have found in our practice.
Mary Gorman: I am hearing echoes of this in the halls and I have been talking with people here at the conference that it's not just the user story alone. We tried to use the color semantic. We'll do things like we would say the story might be green, there is this action that has to take place, but there are other supporting elements to it, like what data is necessary for that story. A big topic that I heard it three times in the last two days was about business rules. What rules would be enforced into that story? What data is needed for the story, for the rules?
These things have to really go together. So we talk about people using Technicolor glasses to look at a story, to be able to think about what are these other dimensions and that leads to another dimension. For years we talked about conditions, pre-imposed conditions. What's the pre condition for a story, what's the post condition for a story? That, in turn, led us to creating this talk that we did in June at the conference, and yesterday mastering dependencies in the backlog.
Ellen Gottesdiener: We are not talking only about planning-related things, we are talking about what it is you're building: product dependencies, requirements dependencies and just being explicit and mindful of what those are. Because there is a balance between what you want to deliver, which is value-based, what you are going to release to the market and the sequence of development, which is often going to be based on the natural order of building the data that you need, is a pre-condition having that data, or the state of that data, for doing some work.
There is this tension that we have that we should be very explicit about between delivery according to value. "You may have to do some work around so you are going to incur some debt and rework, so you have this balance." We want to be mindful about that and have explicit conversations as a team, because business people really need to make techno-business decisions about what to build when. These are very approachable techniques to facilitate that conversation.
Mary Gorman: I was curious yesterday morning, when we started this three and a half hour invited session. We were really honored to be invited, to speak about dependencies and we decided that we wanted to try to poll this group, 70-plus people in the room, standing on hallways. So we gave them materials and we asked them to know, what do they think, what's a dependency. I was curious, I was looking at them last night and there were very few about the product dependencies, there were a lot of things that people considered their project dependencies and one team is dependent on another.
But from a requirement's perspective, it was whether it we didn't give them enough time to identify these. I'm not sure that a lot of people are really focused or familiar what they need to be able to recognize these dependencies whether it's at the big view, there are these dependencies or the preview we often find them much later when we're trying to develop and then it is like "Oh, my gosh! We have these dependencies on the next round system, we weren't aware of." Or "We have this dependency that we don't own that data. Then we have to fabricate that data."
It was six – seven exercises that we put people through in three and a half hours to try to explore at an appropriate level of detail. These were pretty fast and furious, like in five minutes we were exploring what these dependencies are. But being able to do that and to use that for the planning and for development and delivery, we got some really good feedback.
Ellen Gottesdiener: Most people today are talking about usage, the sequence of doing the work, as in a process map or user story map, and these are very powerful mechanisms, but we also need to calibrate that with the value, which is the delivery dependencies and the development dependencies. That gives you a more holistic view of what it is you are going to build when, which is really important.
Ellen Gottesdiener: I don't know that there is a lot of adjustment that needs to be made to the disciplines of Agile per se. One of the things that I have worked with, we had a lot of clients that are in regulated industries, whether it's pharmacy, insurance, financial services big time, etc. One of the things that they have done, they characteristically tend to be risk averse, because they don't want to have the risk of having a violation and there are some legitimate risks in terms of human life and so forth as well as financials that we know exist. As a way to compensate for that, there is a lot of bureaucracy, a lot of paperwork and documentation so that you have this full traceability.
There is all this infrastructure that's been built around protecting the organization from its' revenue, from violations. A lot of that, not all of it, but some of that is the value of that is questionable. It's not very Lean the documentation, so there is one big myth that you don't do documentation with Agile, which of course is not true. What we found, one of the things, and Mary I think can talk about a recent engagement that you have. But in general a sort of a meta-pattern is that when the teams work with the recipients of the materials, whether it's traceability reports, or tests, or whatever depending on industry needs to be done to prove that you do both verify and validate, that you built what you said you were going to build and what you built was the right thing.
When you work with those recipients, to find out what is that they really need, what is that we really have to prove? The slimmest type of verification is to have a test and a very lightweight requirement along with the test. What we found is that we can spike out that process, what is it that we are trying to test, what we need to build first and then calibrate that. Is this enough? And then add from there as needed. Just collaborating with the validators, collaborating with people who are the recipients of that documentation and traceability, I think is key and that should be done very early on. So we test our process for being validated, that's a meta-pattern that we have observed.
Mary Gorman: Recently we had an engagement with a client and they were using Agile to continue expanding, extending a particular product. Their challenge had been that they focused a lot of their energy on using Agile to analyze and build the software. But what they hadn't done was extended their Agile framework if you will, or their approach to Agile to include how they would actually document that they were compliant with these regulations. They had this very awkward situation where they would take all of their requirements, even the story cards, and translate them into their old legacy way of defining requirements, all to satisfy this existing infrastructure they had built.
It was great that they had done as much as they had, but they stopped short. They needed to have thought about the implications of their work to the point where they were not taking a very un-Agile way to satisfy that regulation. So, again, looking at the bigger picture, understanding the implications, what would be the minimal need for a regulator? They had what they perceived from 10 years ago, and they never, for whatever reason, had not taken the opportunity to question "Is that still absolutely necessary?"
Ellen Gottesdiener: Looking at the whole value stream of delivery it is really important, because the documentation needs to be looked at as something that potentially has value. And the team while doing its work, has a lot of documentation, or whiteboarding, or Arlo [Belshee] calls that the detective's whiteboard, low fidelity things that are work-in-progress documentation, pretty low value. Then, for collaborating with other teams that are using off shore, on shore or doing the handovers, that hand over documentation has a little bit more value, but we really have to take the consumer's view, what is that they need and then product documentation (and a lot of regulatory documentation falls into that category) has higher value.
We have to take careful attention and it's got its own requirements. The other part of that pattern is that those could be stories, let's say in the backlog building what's needed for validation, for regulatory compliance, or as you build the product, the "doneness" criteria around regulations are built as you go. There are advantages and disadvantages. With teams that are regulated we basically look at those two meta-patterns' pluses and minuses, and which way we're going to try it and run a spike and try it. We try to make it really practical and straightforward.
6. You've touched a lot on the analysis activities, you haven't mentioned analysts.
Ellen Gottesdiener: I am going to give that one to Mary.
Mary Gorman: This has been a mantra for me for many years when I started as a programmer and back in the day we were programmer-analyst, so you programmed first and then you analyze, I guess that was that thought.
Ellen Gottesdiener: I was an analyst programmer.
Mary Gorman: It was a number of years ago, let's put it that way. The idea was as a group, this is before Agile, but as a group we all had some shared responsibilities in it. So the finger-pointing "You're the tester and it failed because of you or you are the analyst." I think even the name struck me when the IIBA started -- International Institute of Business Analysis. And then, when you think about the certified business analysis professional, there is no analyst in either of those two names. For us, to be able to consider what is the work that needs to be done and what are the disciplines and techniques and competences needed, you going to get a variety of people to bring those skills to the table.
Especially in the Agile world I think is important for us to understand that someone with certain skills could play the role as a developer, or tester, are doing analysis work, and some of those skills, especially the analysis aspect, belong to the product owner, or customer. We all do ourselves a favor if we can evolve past the roles. The challenge of course is that many organizations compensate people based on a title. There is that that has to be balanced with it.
Ellen Gottesdiener: I stand on the shoulders of people like Mary, actually, who worked on the building of the BA Body of knowledge, to begin with, and Mary was chair of the elicitation work and chose very instrumental transitioning the versions from 1.6 to 2.0. What we have become involved in and you as well Shane, is an extension to that body of knowledge, an Agile extension because it can be interpreted, although it could be implied to be a sort of traditional waterfall approach. What we are trying to do is answer the question to analysts, or to project managers or leads, and there is a lot of overlap in those roles in today's world.
How do we do analysis in an Agile way? Whether there are disciplines that we need to inculcate into the Agile practices, serving both the existing traditional analyst, as well as the Agile analyst, and trying to take an Agile approach to building this. We're a global group of volunteers, which certainly has its' own challenges and we were doing our best – at this point it's a challenge. We are trying not to repeat some of the difficulties from the other efforts and we were talking earlier about this, that before starting I wanted us to do a retrospective.
A retrospective of some other people who had been there, maybe the PMBOK [Project Management Body of Knowledge], the project manager of Body of Knowledge Agile effort, what their process went through, but also building the BOK in this distributed community. We did a retrospective, I interviewed Mary as one of the core team members, and than Mary volunteered to go and interview all the folks that have been involved and pull those lessons in. We're trying to pay attention to those as we go and we have a ways to go in terms of focusing on that and drinking our own champagne or prosecco (as my preference) instead of saying "eating your own dog food" in using being Agile about writing about this, about the extension.
8. And the early draft of that extension is available?
Ellen Gottesdiener: There is the introduction, I believe it's currently available and what we have been doing is going through the knowledge areas when we realized that what we really need to do is to focus on the techniques and how they thread through the different knowledge areas. So we are doing a sort of reboot right now to really focus on what are the key techniques and where would you use them and where are the new ones that are not in the body of knowledge. Doing analysis is art and science. The science part of what are the techniques and what are the meta-patterns for doing these techniques and where would you use those. That's where we need to be moving next as a team building the extension.
9. Is there anything you would you like to tell the world before we wrap up?
Ellen Gottesdiener: We should mention that we are collaborating on a major writing effort. We are writing a book and the book is currently untitled, but it is on exploring product needs, so that you build the right product and we are trying to use Agile to build the book. So our process is Agile. Our content is about the multidimensional techniques that we use in building the product, different views that we want to take. We have a couple of personas that we're focused on in terms of readers. Mary, do you want to add anything?
Mary Gorman: We really want to capitalize on the fact that from an Agile perspective, most people are not going to read your book from start to finish. We would like to leverage the idea of having a ready reference guide, which is the current "Software Requirements Memory Jogger." This would be very focused, someone could have it at the desk, flip through it, be able to target a particular technique that they need to be able to do, have integrated examples. Talking to many analysts they have certain skills, they want to be able to leverage those and move to the next level. This is not going to be a comprehensive, everything that you ever needed to know about every single technique, it's going to have the expectation that you would have certain skills, if you don't we point you where to get them. It is going to be Lean and mean.
Ellen Gottesdiener: And left brain and right brain will be tapped into.
Mary Gorman: One of the things that we hear from folks whether it is here in conference or working with our clients engagements, it's like: "We need some tool that we can use that will help us to just get moving, get us some traction and have a consistent way of communicating this." We got to the point that we heard often enough and said "We ought to do it."
Ellen Gottesdiener: Right.