Yes, thank you Shane. I’ve been in the technology area for about 30 years now, helping software development teams and organizations deliver technology; started out as a developer, worked my way up in sort of project management roles and over the last 15 years I have been involved in enterprise transformation and standards development and work like that. A couple of big things where I worked with Microsoft and their services oriented architecture group establishing their business architecture practice, so I was a significant contributor to their whole model and the business capability work and stuff that you are familiar with that we’ve done there.

We have a Harvard Business Review article where we talk about some case studies where we made some transformational change in organizations with that. I’ve also worked with PMI on the standards side, I helped deliver the OPM3 2nd edition standard; one of the important contributions there was bringing in the organization enablement aspects - really how do you sustain these changes over time and helping really focus on outcomes and maturing, situations where we’re maturing project management over time and for the last couple of years I’ve been working with the IIBA and you on the business analysis extension, the Agile extension to the Business Analysis Body of Knowledge. During the time I also run a consultancy where we go and we actually work with organizations and help them implement these practices and make this type of changes.

Yes. I think it’s a little more important. In the last decade the Agile movement from a software development team stand point has giving us the ability to rapidly deliver chunks of software, high quality software. We are getting pretty good in the industry of standing up high quality teams , that deliver software that works pretty well. The gap has been in a lot of the Agile literature, there is this presumption that there is a ubiquitous product owner that has all knowledge of the market and knows how to feed things in the right order of the right size with the right information down to these delivery teams and in practice it just doesn’t exist. And there is not a lot of good information about that ; about how to intentionally make that work in organizations. So defining that, shaping that, getting agreement of what the good practices are around that and making that become accessible to clients and the community has been a really important thing to me. And I actually think it’s transformational in the way that organizations can deliver on their strategy and even big companies can rapidly deliver technology to inform process and costumers and adapt to the feedback they give from that performance.

I think this is a more significant transformation that most people understand that are they going on right now, the difference between the way we deliver technology today and the way that we will be doing it in 5 years in many organizations is going to be substantially different.

There is a pretty common understanding that this analysis is taking orders and writing documents that development teams may or may not use (and most often don’t) and building software that is going to get used by the quality assurance organization before technology gets delivered to the business. And "this over the wall" aspect it is a problem for a number of reasons: first off - the way that we test things and the way we develop things, the way that we build things only inform each other, help create opportunities for the way that we are going to do work. This concept of value management is understanding the next most important set of needs in the marketplace or in your business and finding that in a way that you can work through this collaborative process of getting the best solution to the problem delivered in the nearest term possible. So it’s not just about taking orders, it’s about balancing capability and capacity against the next most important things to the business. It’s much bigger than order taking and producing documents.

Yes. What ICAgile is trying to do, it’s an organization that is headed up by Alistair Cockburn, one of the most influential thinkers in the Agile space, signer of the Agile manifesto and what Alistair is trying to do is cross the analysis, testing, development, coaching all the different aspects that go on right now that we have different organizations around. So there is Scrum master certification, PMI has a certification, IIBA is coming over the body of knowledge and ASQ is coming out with a body of knowledge, but they are all different and they don’t all fit together perfectly well.

And so what we are trying to do is come up with a cross cutting set that clearly defines kind of what Agile is and why this is really important is the HR director sitting in their office in an enterprise and is trying to help their organization position for this transformational way to deliver software, has no framework of understanding of what the skills and knowledge and competences are that these people have to have. So by defining this set of learning objectives and making it understood how they fit together and how they are valuable in different circumstances, we are going to help enterprises make better decisions about the types of skills that people need to have, driving a career paths, driving training and driving the hiring practices to make sure you are getting the right people. So the ICAgile is really important in the regard that they are not trying to sell training, they are trying to build a context of understanding that can be consumed outside of the Agile community.

What is interesting is all the competencies that the enterprise needs to deliver all of this are actually the same that you need on a two or four team XP project, that one developer, one costumer sitting together still has to be able to understand the marketplace, communicate well, assess options, build it, test it, learn how to work well together. So all those competencies still exist, but in that little environment you don’t have to be necessarily as intentional, you can feel your way through it. That is how a lot of the Agile practices have emerged, people have worked their way through it and found what works really well. Some good practices are emerging out of that, some pretty common stable things that we can do and now we need to be able to articulate those up to the enterprise, and you just can’t do that tribally.

Because it’s too long, too distant, there is too many different people thinking different things, we don’t get together and have a framework to discuss in the context and because what works in one place may not work in another place. You’ve got have a starting point to start to figure out "I’ve got to get better defining my product". What does that mean at the release level? What does that mean at the strategy level? What does that mean at the street level within my team on this day in this organization with these people, having those containers, the frameworks to discuss that is a good starting point.

Looking at the traditional business analysis or the current version of the BABOK which defines a set of techniques and tasks that people ought to understand and some underlying competencies that a business analyst ought to have in an enterprise, it’s actually a pretty solid piece of work and we went and took it and shaped it work specifically with these Agile teams. Over the last 2 years a number of people, you Ellen Gottesdiener, a lot of influential people from the community had a look at this and participated trying to shape what we have found has worked consistently in the organization. And it’s just another example of trying to pick a set of good practices and put a container around it that the industry kind of agrees are right for many teams often and begin to make that be a starting point of teams to understand from this. We shouldn’t have to recreate this stuff from scratch every time.

This is a really nice piece of work that this team is collaboratively put together in this space and hopefully it’s going to get a ton of traction in the industry.

Maybe we can put a link on the InfoQ site; that would be awesome.

As you start to get into working incrementally and iteratively in organizations with rapid feedback and small chunks of work it’s really difficult to create the distinct gaps between some of the testing aspects and some of the analysis aspects and some of the project management aspects and these become a smoother more consistent sort of body of knowledge at this level so the value management begins to talk about those aspects of project management that are directly related to flow in leading teams. So the way that you chunk work up, how you prioritize, how you shape things into iterations becomes a value management thing not a distinct project management thing. The way that you do acceptance testing and validate that what’s been delivered actually meets the needs that you described up-front maybe help you to define acceptance criteria, again we don’t want to throw that on the wall.

So there is an aspect of this that really becomes part of the same job that’s quality, and it’s not necessarily on the load testing, some of the big things, they are certainly big parts of QA or testing they are distinct, but this sort of managing at the business value level across multiple Agile teams or across the single Agile team. This distinction isn’t meaningful between project management, business analysis and testing all the time. So this value management is that layer of pulling it all together. And another thing is you and I in the business analysis community; you understand that what I am calling value management is what you and I always done as business analysts.

Chris Matts will say the same thing. He does the same job in every project and he gets hired into different roles. We’ve had this conversation for a long time, but to get the world to understand that we are talking about something other than the order taker who takes pieces of paper from the right side of the desk and slides it across the left side of the desk. It’s sort adding a term that probably describes it better because a business analyst analyses something and produces an analysis. So defining and adding a new language isn’t overloaded with the history of bad business analysis ispart of what this value management is about.

It’s a way of thinking and understanding. It’s a set of competencies and outcomes that need to be done intentionally well. There is a lot of good practices around and if we can define those well enough, like I think we’ve done a lot of this in the Agile extension, if we could do this well enough, then even the smallest team regardless of roles, regardless of position, people think it up and pay attention to doing these competencies intentionally. And so communicating outside of a job title or a domain specification to being meaningful things you have to do to support the delivery of technologies is really what we are trying to do there.

One of the interesting phenomenon that we’ve seen a lot of organizations that the risk management aspect of projects is putting a project management domain and handle with a separate team independent from the delivery organization. And they might go do some analysis and come up with some categorization of frequency and impact and do a bunch of planning around what they want to do about those risks and it’s not completely clear to the Agile delivery team what those risks are, how those risks might manifest or what they might want to do differently or be paying attention to, to manage it. So one of the things that I’d like to see brought more into this context as part of this value management story is what are the obstacles to delivering value and how can we make those explicit in the same sort of mechanisms that we track scope, so for example just bringing risk stories right into the backlog and involving the whole team in managing risks.

So a risk story would be the things I need to do to address a risk and helps me begin that there is value into addressing a risk, there is value in learning something I don’t know and we tend to start delivering stories that are valuable early in Agile teams because we’ve been told we have to be costumer value delivery all the time, without paying attention to the value that is inherit in mitigating a risk or learning something important about how I might build something. So part of this prioritization mechanism as we start to talk about risks and project risks and organizational risk and technology risk is making them explicit in the list of work that has to be done and using that risk burn down as a high level prioritization strategy and mitigation strategy in the backlog, so when I release I want to to the riskiest things early and then learn the stuff I need to do and to my valuable work. In a sprint I want to find other things that are likely to make me fail the sprint early. When I start working on a story I probably want to go figure out what I don’t know about what my challenges are early rather than differing things to the end.

So two interesting things happened: we tend in projects (because of how we’ve been managed over time) to push those riskiest things out to the end because they are the things that make it hard to keep our earn value on track or to keep our release burn down matching to what the expectation of the business is, but they are also the ones that are most likely to cause us fail on the commitment, so we tend to push them out to the very end and then we don’t fail until we’re 80-90% of the way through the project when we start doing the risky things. The concept here is doing good risk analysis and using risk above new value as a prioritization mechanism as trying to get explicit thinking around that in the enterprise.

It could be the project manager because that is a role but it’s surely not done in a vacuum by the project manager, it’s a team wide or organization wide process just like the value stories are, they get elaborated, they get discussed, they get explored and prioritized, they are increments of value. If we can start to think about risks as increments of value; bringing down a risk is just as valuable to my project to the end of the day as delivering a feature is so changing the thinking about it, pulling down the risk management out of an abstract specialization that happens outside of the team into a primary capability within the delivery team is an important aspect of this emerging value management space.

What I found for the most part is that people that are product owners, that are business facing, are very pragmatic and what they really understand is risk story, they really understand the value of burning down risks. It’s because we don’t try to have a conversation, we don’t have a context to create meaning around it that we start pushing under what I believe is a perceived constrainer, a perceived priority on the part of the delivery teams, but in my experience business people understand risk. They understand spending some money to have a greater likelihood they will get something of value, they understand buying insurance, they understand all these sorts of things that you do, so risk is clearly part of their thought process, we have to articulate it meaningful in the context of the scope to get into understanding what we are trying to driving to. Does that make sense?

Sure. Help get involved in these different areas of knowledge or emerging and becoming more explicitly in the Agile space, get involved in understanding what makes sense and participate where you can in providing feedback in these opportunities. So this stuff has to be pragmatic and make sense to the world, just getting involved in volunteer activities of helping build these bodies of knowledge. There tons of opportunities for people to participate and provide feedback. The second thing is every one of these ideas that you hear in this space as ideas emerge, take them with a grain of salt, evaluate them against your experience and your understanding and your context, don’t take any practice literally, look for the outcomes you’re going for and find out how to make those happen to the organization. That is sort of my coaching tip for the day in this emerging space.