Sure. I'm based out of Des Moines, Iowa. I have several years of experience working in a lot of financial services industries, a little bit of automotive and most of that time has been spent doing stuff focused around “are the teams we're working with building the right thing”?. So early now, it was business analysis and project management. For the last few years, it's been more focused around product ownership.
So focusing a lot on helping teams figure that out and even doing a little bit of it myself with the Agile Alliance in some of the systems that we use for running the conference and providing resources out to the community.
2. In fact, that's one of the case studies in your new book, isn't it?
That is one of the case studies in the new book, "Beyond Requirements: Analysis with an Agile Mindset." I talk about the process of rebuilding the commission or the conference submission system and the maintaining it going forward for the last couple of years.
3. Oh, maintaining. Why do we need requirements for maintaining a product?
Actually, in some respects, it's probably been more interesting to be maintaining it than to building it in the first place because we're, as with most projects and most products even, it's a matter of figuring out what can we fit into the small constrained box that we have available to us every year?
So the approach I've been using is, I kind of referred to it as the movie phone estimating approach. It's really more based on starting with a budget and then going forward and using that to determine how much can we get in there? I refer to it as movie phone estimating refers to a Seinfeld episode where Kramer was acting as the movie phone guy and he would always say, "So tell me what movie you'd like to hear?"
So it's a matter of perspective saying, "Tell me what your budget is and then we'll figure out what are the things we can fit in there," as opposed to even going the route of estimating things.
Not necessarily. I think it's important, especially if you have the "building the right thing" mindset. You start off by saying, "What is it that we're trying to accomplish? What are you trying to solve? What outcome are we trying to get?" Then it is important to understand, "What constraints to we have to work within?"
Then you have a choice, you can find out, "Are we going to be able to produce the output we need to to get to that outcome within those constraints” or do we have to start having discussions about, “Can we adjust the constraints any?"
With the submission system, mostly what I've done is that I'm living with the constraints we've being given and we're going to figure out how to make it work. So what that often leads to sometimes is we get some functionality developed. There's other things that we might do menial for one year and think, "We'll catch it the next year," or we'll determine, "You know what, this is no longer a problem. We can focus on something else”.
Shane: You mentioned the name of the book, Beyond Requirements: Analysis with an Agile Mindset.
Yes.
5. What's different about analysis with Agile?
So the thing is, kind of the crux of the book is, and again, I mentioned I have a background in business analysis and a variety of other things as well. One of the main ideas behind the book is that analysis techniques that people have been using on software projects for several years are still relevant.
The thing that changes is when you do those techniques, to what extent do you use them and who do you it with? So it's taking a much more collaborative approach to it. Doing just enough that you need in order to build a shared understanding of a variety of things, starting off with your stakeholders. Then understanding the context in which you're working and then figuring out what need or needs are we trying to satisfy?
Coming up with some solutions for those and finding a way to describe them that everybody that's working on that effort understands jointly. Then figuring out, "Is there anything we need to do to persist information about that solution?" So down the road, if we have to make changes to it, we know we have a good place to start.
6. But we don’t write any documents in Agile?
Oh, certainly, we do. But the thing is, is that they have to have a specific purpose. Then also, you want to make sure that you're writing it with that purpose in mind. So it's not a matter of saying, "We're going to take those requirements we started at the beginning with and we're just going to repurpose those." It's really saying, "What are the needs of the stakeholders that need that documentation?" and we're going to write something for them specifically for that purpose.
Shane: Cool. The other thing you mentioned you've been doing is some video classes.
Yes. So as a means of getting the book finished, we had to get that done first and it will be out in September. Then following that, we're going to do some video classes based on the techniques that I described in the book. So the way that book is structured is it starts off, the first part of it talks about ideas, things about contrasting outcome and output, things about contrasting discovery and delivery and needs and solutions.
Then the second part is the four case studies, one of which you mentioned is the submission system. Then the third part of the book is actually a set of techniques that I've organized into kind of the different bits of understanding that you need to do.
The video classes are going to just provide another means of describing what those techniques are, when you use them and collaborative ways to make them useful in projects.
The other thing I'd like to mention about the book and the video class is that it's actually focused on analysis more so in IT projects. So a lot of the literature and a lot of the books out there about analysis in Agile are more focused towards product development, software product development.
I chose to have this book more focused on IT projects. So things where you're doing stuff to support internal business processes and things of that nature because there are several similarities but there are also some differences. So I wanted to focus on that to give that audience something to kind of help them get some guidance as far how they might approach stuff.
That's been a common theme and a lot of people have said that and there's a lot of good ideas in that. I think what they're really reacting to, and I actually struggled with, "Do I call these things projects or not?" The interesting story there is my editor, Deanna, basically said, "I think you should just own it," because a lot of people still call them projects.
The trick is, is that we don't want to treat those efforts the same way we've always been treating them. The danger is how they basically are considered temporary efforts with a temporary team. development.
Part of the project that's useful is we've got a self-contained bit of work where now we're trying to solve a specific problem. I think that part still is relevant but we want to be doing it with teams that are consistent. So instead of taking people and putting together a team, they work in a project and then the team gets blown up, we'd rather much have one team and have work brought to that team as it needs.
I don't think the term project is going to go away anytime soon. So I think it's better instead of inserting a new term that's going to cause confusion, it's more along the lines of saying, "How does this need to work now to be more effective?"
Shane: In many organizations, a project now is really a funding mechanism.
Kent: Yes. That's something else that needs to change. So the project still makes sense as far packaging work together. Funding mechanism, however, needs to kind of more align with, "What are the teams that we have available to us?" It kind of goes back to that idea of the budgeting versus the estimating.
So our constraints in this case are the teams we have available to work on it and then we need to decide what particular outcomes are we looking for this effort or project to achieve and how much within our constraints do we want to actually spend towards doing that?
I have known for a while, at least somewhere in the deep, dark recesses of my mind but it's really only become clear lately through some mistakes I've made along the way, that product ownership is actually a broader combination of at least business analysis, product management and user experience.
So one of the reasons I really started focusing on product ownership is to reinforce the idea that it isn't extremely helpful to just be in one of those areas.
Now, what I see happening a lot is business analysis and product management are very similar but the one you use depends on the context in which you're working. Business analysis tends to be much more frequently used in the IT project space. Product management, same kind of things in the product development space. User experience needs to be in both and I find it often neglected on the IT project side, to the detriment of those.
9. But don't we have specialist user experience people for that?
We certainly do but in some cases, you may not have those expertise there. In other cases is that there are a lot of tools already that exist in user experience that also are frequently talked about in the business analysis community. Sometimes, the same names, sometimes they use different names.
I also think that people in general, to be effective in their professions, certainly, they're going to have specializations. But at the same time, they really can't put those skill blinders on and only focus on doing one thing. I think they need to expand out and rather think about, "What is it I'm really trying to accomplish?"
Frankly, again, for product ownership, it's building and understanding of what the needs are and what the solutions are going to be for those things.
Shane: So solutions.
Yes.
10. We're moving away from this gathering of requirements and throwing them over a wall?
Right. Yeah. It's the perspective that we, first of all, we don't necessarily need to satisfy every need with a software solution or a software problem. In fact, as I've mentioned, with the submission system, we often will do things where if we're getting close to going over our constraint, let's say, what's the simplest way we can do this? Often ways, for a short term, it might be a more manual approach.
In my experience in IT projects, there are several cases where in IT setting, someone comes up with what they think is the need but it's ,really, they're describing, "Here's the solution, I think," where a simple process change can actually get the outcome that they're looking for much more effectively, quickly, and a lot less expensively.
Shane: Yeah. The best work is the money we don't spend.
That's right.
I have the advantage of -- although the whole idea of product ownership isn't as widely discussed as other aspects in Agile, it is certainly being taught by a lot of brilliant folks out there, yourself included.
I'm seeing a lot of resonance behind a lot of those ideas. So a lot of people are talking about the idea of value teams towards getting different skill sets put together in the same place. Also, the idea that it really isn't necessarily helpful to talk about the idea of a specific one person product owner because that's often not realistic. They're expected to do a lot of things that only one person couldn't do but really talking about it as product ownership.
While still understanding is you need to have someone that is making sure whatever decisions need to be made are getting made. They may not be the ones making that decision. They're certainly on point to make sure those decisions happen.
So there's a lot of different talk out there in the community that's kind of all swirling around those ideas and trying to get, I know that people in the user experience and product management communities are really saying, "Hey, we need to get involved here more and talk about things more." A few people in the business analysis community are really saying, "Yeah. We need to incorporate these thigs but also we need to be looking outside of our body of knowledge and figure out what else is out there as well."
I've found myself, it's interesting, I've been going to this conference for several years and I hit a certain point there where I hardly went to any sessions and I'm actually kind of going back up the curve where I go to several. The sessions I'm finding the most helpful are the ones that are talking through -- on the surface, they're very straightforward simple techniques. Mostly around, again, building that shared understanding.
But the good sessions that I'm seeing are the ones that take those techniques and do a deep dive and kind of the subtleties and the nuances and how they can really be interesting. I have found over and over again that the simplest techniques are often the most powerful and the most elegant because the more complicate a technique is, the less likely people are going to be able to use it effectively.
So I've seen sessions on prototyping and how to do that effectively. One was called, "Consensus that Sticks." It was about affinity grouping, something I've been doing for several years. But Jeremy Kriegel who put it on did a great job of kind of going into some really interesting nuances. They're very helpful. There's been a couple others as well that I have found.
Again, talking about simple straightforward techniques but it's the nuance behind them that can be very powerful.
13. The other thing that you do is you blog a lot. So where can we find out more?
All right. So it was a bit of unintentional branding, I think. I originally grabbed the Twitter handle BeyondReqs back in, actually, New Zealand in 2011. I have a blog, beyondrequirements.com, that's the title of the new book. It's all kind of surrounding this idea of looking outside of just requirements and thinking about what the broader thing is.
But one of the things I'm trying to do with the blog is, again, go out there and find where are other good pieces of information looking in the UX, the product management and business analysis communities for those good nuggets that I think anybody in a product ownership-type can find useful.
So doing that and taking a lot of ideas. Also, I'm doing a lot thinking of ideas from the content marketing community because those are folks that also do a good job, especially a site called Copyblogger. That does a great job of following lean startup and actually a lot Agile principles. The thing I kind of like about it the most is they don't necessarily feel the need to put a label on it. They just do it because it makes sense and it's a good way of experimenting and figuring out what works and trying things out and adjusting. They say, "This is just how we work."
They're very good about sharing those ideas and not feeling the need to put labels on it, which I think sometimes the labels can be detrimental, and just basically say, "Let's get to some good practices that seem to work." So I'm trying to invoke a lot of their ideas into the blog as well, putting out a weekly newsletter where a combination of stuff that I've read and then also stuff I've curated from around the internet.
Shane: Kent, thanks very much, it's been good to catch up. Enjoy the rest of the conference.
All right. Thanks, Shane. Good talking to you as well.