Agile Portfolio Management

well good afternoon or evening Wow good evening all right that's awesome that's awesome get some life in these these veins so so just a little bit about myself just a little more again I work with a company called leading agile company we've been around for about seven years a friend of mine started the company and we've we just enjoy helping companies out doing some great things had a lot of growth here in the last few years so it's just been awesome it's been a fun ride I jokingly I used to say I had hair when I started but I can't say I can't really say that my experience I grew up as a developer most of my years have been in the financial services space but I've worked with different companies through the years as well and of course being with leading as well almost six years a lot of interesting companies we've worked with so a lot of different domains out there it's been it's been a lot of fun so here's some of the things I think we'll talk about tonight see if you think this is a good good set of topics so we're going to talk about portfolio management in a way that allows us to focus upon the most valuable things most viable things we can do for our company what we're trying to achieve now I like seeing our capacity against a man you guys ever find that the business is asking to do more than you guys have capacity to do is that a problem yeah it's crazy how to be adaptive and support continuous improvement so how do we do that as an organization how do we create the systems that allow us to do that and then how do we support you know how many of you are in really large organizations have you it we tend to from an agile perspective it becomes difficult to support some of the corporate compliance things that we have to deal with security issues regulatory things so we want to talk about how do we work that into our portfolio management system to be able to support that makes sense you guys think this is a good set of topics for us to go through tonight okay awesome the other thing is I want it to be interactive so feel free to stop me ask questions if you think I said something you do you think I'm full of it that's okay too we can have that conversation if we end up tonight just me talking all night it's not going to be fun for you guys well let's make it interactive okay all right so this is the traditional PMI definition of portfolio management I'm not going to read all of these words but I think most of us that have been around for a while this is probably what we grew up with from a portfolio management perspective that makes sense but it may not resonate with you but that's the definition that a lot of us are aware of okay there's another definition of I found investopedia z' definition it actually is in more alignment I think with what we're trying to do from an iterative development perspective so they're saying portfolio management is the art and science of making decisions about investment mix a policy matching investments to objectives asset allocation for individuals and institutions balancing risk against performance that one resonates with me better than the other one how about you guys yeah okay all right so before we talk about portfolio management I want to set some context about what Rick believes agile is and so that will inform our discussion about portfolio management when we're operating in agile worlds that fair to do that okay so there's kind of three things we want to talk about and the first is agile is about creating teams cross-functional teams that have everything necessary for them to complete the work that we're asking them to do that makes sense and those of you who how many of you in this room are doing agile today is that how you would define agile teams okay I always say teams that stay together until death do us part right then we have teams we also have to provide backlogs and backlogs are the things that we're asking our teams to go do to build okay so we have teams we have backlogs and then we want to demonstrate working tests of software so incrementally iteratively getting feedback be able to demonstrate software that's actually working and people can see it touch it and feel it they're cool okay so why is this important so it's important from the standpoint of having teams that stay together having backlog and they're accountable for doing their work but they're accountable for doing the work because we've created clarity in the backlog for those teams a lot of times you find agile teams that are suffering because they don't have the clarity they need about what they're supposed to build they're working they're doing stuff but we don't necessarily have the clarity necessary for them to be building the most important things for the organization in portfolio management is going to help us with that I'll talk about that in just a moment then if we have provided that clarity for those teams then the teams are accountable for doing the work do what you say you're going to do if the team agreed we're going to do these 10 things during this time period then they've made that commitment they need to do those 10 things right clarity accountability and then measurable progress we have to have the ability to to determine if we're making progress toward some goal and can we measure that okay and so if we have this clarity accountability measurable progress we have a system of delivery that allows us to focus on value and deliver things out to our customers yeah yes yeah I'll make sure the stack is available I'm Maria I'm Justin yeah I'll get it to you yep so how do we scale this and this is where we start to get into portfolio management so you think about we have backlogs clarity those backlogs governance for me because governance we hear that word sometimes we we feel like it's a big bureaucratic thing when we think about governance it's lightweight it's making sure we're doing the right things and it allows us to create clarity in the backlog for our teams so the way a lot of times I think about it from the standpoint of governance is how does the rest of the organization operate in a way that we're making the best decisions and what to build and how to build that by our teams then we have structure so when you build teams around something we want those teams to say together and so one of the things we we do is define the structure of those teams and that can be difficult sometimes when we go in and do transformations organizations we've changed the structure cadet depending upon input from an architectural perspective maybe lines of business what are your capabilities from a business standpoint and so creating the structure is important because that structure is what the governance model flows across to allow us to create value and then finally we have metrics and the metrics allow us to demonstrate to ourselves that we are indeed providing value and we should be able to tie that back to our company strategy and those metrics come from two places at least for us when we're doing transformations there's metrics around the system's ability to deliver value and those metrics would stay in place forever and then there's metrics around the change so if you're moving from let's say a waterfall approach to an agile approach there's certain metrics we can pay attention to to make sure we're actually making progress on that journey as well so there's two sets of metrics that I might pay attention to that cool I'm gonna hit them really fast we're not gonna go in a lot of detail on them but we are going to talk about governance structure metrics here next so let's talk about structure so this is a multi-tiered model and this is a common pattern that we use when we do transformations and organizations and so that the bottom tier would be some number of delivery teams so these are your scrum teams typically that are cross-functional have everything necessary to do the work we've asked them to do they stay together they have a backlog and they're demonstrating measurable progress through working tests of software and that structure could you could have teams that are feature teams product teams maybe their services teams you may have a mixture of those I've before my leading agile days I worked in financial services and we had teams that were focused on banking platforms bill payment platforms but they made all of these services teams that had particular services to mean that they were focused on and they provided capabilities that the product teams use you guys have any of that in your organization those types of teams you know okay then above that is something we call program teams some organizations might call these product teams it's also a team that's cross-functional but it's the team that's making sure that we're creating clarity in the backlog for these teams they are creating the requirements they're creating the backlog they're providing that direction they're making decisions about the minimal thing we can do to make sure we're getting the outcomes the business has asked us for so making sure we're building the right thing we don't over bill we want to build a right thing to demonstrate success that that makes sense and then at the top level our portfolio team so portfolio teams are really what's our investment mix look like where should we place our bets what's the next and most important thing for our company to do and oftentimes there may be a tier about this called a strategy tier that strategy tier is thinking about five six 10 15 years out what's the strategy for the company and so if you have that strategy then the test for the portfolio team are we picking the right things to execute on that allow us to support that strategy if we can't demonstrate that then why are we doing this thing right that helps us have a lot of clarity about the things we choose to do or those things we choose not to do any questions about this structure say the bottom delivery team has to work with another team then sells a product layers of different responsibilities and by the time that you even you working with proxy users come to find out that what you're building isn't really what they want yeah so so it depends upon the organization right there so there's no there's not a one answer that's going to to solve that problem but but there's there's a couple of things at what you said so one is making sure the program team has the voice of the customer in some way maybe that customer is not interacting with the scrum teams every single day but there's at least some relationship that we can provide feedback I mean I have organizations that we have the the program team that's providing feedback to the delivery teams every single day and then maybe they're doing feature level feedback out to the end customer on a larger cadence but we're still getting that feedback we're not waiting six months before we get feedback and find out we've not built the right thing so we want to accelerate that the other thing that I heard in there's dependencies I mean almost every organization we work with there are dependencies you know this team can't do something unless this team does something first or this team can't do something until these three teams build some new service capability one of the responsibilities of this program tier is to make sure we're managing those dependencies and and frankly if you're in an organization that has a lot of legacy architecture a lot of dependencies traditional project management that we all do still exist you just have to manage the heck out of this stuff right because pure agile teams are not autonomous in most organizations if they are then you don't have to have that management overhead an agile team that's completely autonomous that has no architectural dependencies or other team dependencies they do whatever they want right you don't have to have that overhead that's just not the nature of the the companies that were working in so we build the system that allow us to manage that and we'll get in a little of the detail behind that when we get into the governance model I don't know if that helped or not but yeah I mean it's one of those things where you really have to dig in a little deeper to find out what the specifics are but there's some patterns right maybe Mike gave something that might say gave something them I had started off slices oh yeah yeah yeah that's right so when we do transformations we don't come in and Bowl the ocean we'll find a slice of the organization so it may end but it's a full stack its portfolio its program its delivery team so it may be you know one portfolio team one program team and maybe three or four delivery teams and you do that slice to make sure we understand all the problems that exist in the organization and once we've demonstrated success then let's start to roll that out okay all right so let's talk about governance and so again governance is the flow of work across the system in the structure and so typically at the delivery team who are talking about scrum that's how work is managed that the program team and the portfolio team it's more flow based we're using Kanban and it's about the flow of value through the system and we'll talk a bit more about that here in a minute when we get into the details of governance okay then let's talk about metrics and so at the delivery team level this is a set of metrics that we typically pay attention to okay so things like backlog size how deep is my backlog made me think of that song how deep is our love how deep is my backlog and we want to make sure it's sufficient depth not to starve the teams but also pushed far enough head to manage dependencies so if you have a lot of dependencies that depth of your backlog maybe three or four sprints if you don't have dependencies maybe it's smaller you could become more adaptable velocity the the the throughput of the team how much can a team demonstrate how much working test the software that can they build on a cadence every single sprint burned down are they burning down toward the goals that we set when we did our planning escape defects are we finding defects from work we did in Prior sprints commitment ratio acceptance ratio are we doing what we said we're going to do you guys said you're going to do these ten things on the backlog you only did eight that's 80% right what's the right number there we're going to measure that and then scope change how much sure is happening we want to measure that because churn at this level may indicate problems above we're not pushing our planning horizon out far enough we're not thinking through this we're not managing the risk and dependencies well you see a trend yep yeah so there's a there's a trend here so when we set up dashboards there's a couple of things we're paying attention to when is it under control so that commitment ratio typically is 80% as long as we're 80% we're thumbs up if he gets below that we need to go find out why that's happening and then what's the trend you know are you trending up as far as your commitment are down you want to pay attention to that velocity the same thing I don't care what your velocity is I just want it to be consistent all right Fitz you know this number this Brenton is this number the next print and that number that that you can't be predictable that's not a stable system right I want to make sure that we have stability in our delivery system okay so at the program team level just a handful of things we pay attention to particularly in the beginning cycle time and and we're thinking about features you know how fast are we getting features into the market what's that cycle time and one of the things we want to do over time is reduce that because as we reduce the cycle time we actually improve the throughput of the organization you can deliver more value by operating in smaller batches so cycle time can be important the number of features blocked so we may have features that are hung up because something down here is blocked we need to go find out why that's happening why are these features not getting out what could we have done maybe it's a planning issue maybe it's a requirements issue what could we have done to make sure those things don't happen in the future and then rework and defects and it's kind of a traditional metric there and then the portfolio level similar similar things cycle time your traditional project management time cost scope those types of things an ROI and capitalization are we capitalizing appropriately are we getting the business benefit that we expect I mean one of the things that we pay a lot attention to at this tier and I'm going to talk about the thing that we pay attention to here called an epoch is does it have a business case can we demonstrate that there's value in the thing that we're doing if we can't why are we doing it okay any questions so it's like think about your car if you're driving down the road we don't have a thousand gauges you know there's a port up under the dash that a mechanic can hook into to get all manner of details about your car if I'm driving my car is that something I should be paying attention to no I maybe I want to have someone pay attention to it if the lights on the dash turn red I've got an issue so we want to make sure the right metrics are being paid attention to at the right level now if we find that our cycle time or we've got metrics at the program tier are going south on us then by all means let's go drop down and investigate that but for people at a higher tier focusing on some of these metrics it's just a waste of time doesn't make sense that's not what we should be paying attention to makes sense okay I know well part of its trust right because we're demonstrating a new approach to delivering value and they want to put their hands on the things that they can see in touch which is are some of those metrics we need to shift that thinking to the perfect metrics to pay attention to governance flow talk about the things that flow first so in the requirements decomposition model that we traditionally use we talked about epochs two features two stories unfortunately in the agile world epoch whoops epochs are that's an overloaded term in some camps an epoch is just a big story that needs to be further decomposed but in the definition that we use an epoch is some business problem or opportunity that we need to go do something about okay those are the further decomposed into capabilities we intend to build features and then those features are further decomposed into stories and the stories are the things that show up in the backlog for our teams we're cool with that okay so one two three five no more than five but yeah we so so it's interesting right when you come into organizations that are very complex a lot of dependencies those stories tend to be too big and it takes time to get them down to the appropriate level of size then they're working in a world that's fictional all right so here are the key goals from portfolio management so now we're back to the topic of of the night and so the governance model is exported to accomplish these goals over time so the first is strategic alignment making sure that the things that we're determining are the things that we're choosing to do invest in do actually match up with our strategy from a company's perspective okay we will also want to make sure that there's transparency organization we understand how the system of delivery is performing so we can make better decisions about what to invest in and and then again build the things that are valuable stop building the things that that don't have value there's a study that a lot of people have used called the chaos report that showed in this this is a set of software that was surveyed 64 percent of features rarely or never used why did we build it right it's there it's it's now has now that software that we can't break in the future we have to continue testing it and support it but no one uses it terrible terrible demand management so making sure that we understand the capacity organization and were able to leverage that capacity to create value how do we improve the predictability organization so we can make better promises into the market okay how do we manage our dependencies how do we manage risk making sure that we're focused on that then detail planning at some point we have to get down to the level of specifics about what we're going to do how we're going to do it who's involved so that level of planning has to occur at some point execution governance so now we're going to build the thing we're making it happen happen we're demonstrating work he tested software frequently we're getting feedback so we want to support that ability from a portfolio management perspective you know say you get into execution and we find that some dependencies outside of our control are not know no longer able to meet their commitments to us maybe we need to escalate that out to the organization and then measuring effectiveness and this is something a lot of organizations have have trouble with we've done it we had a business case but we never did go check to make sure it did what we thought it did we want to make sure we validate that that assumption in that business case okay so this is a flow and so again thinking about that structure we have the portfolio tier the program tier and the delivery team tier and so this is just a flow it it looks like it's a lot but it's it's pretty simple epics are flowing from left to right so think of it as a life cycle for the epic features are flowing from left to right similarly stories and this was just groms life cycle so we're not going to talk about that but you think about portfolio management things are coming in and we have to make a decision to move it forward or not we may kill it we may reduce its scope or we may choose to go do it and we want to do just enough to make that decision so here we're not going to go spend a month doing detail planning we're going to validate the business case our sumption x' we're going to move it over here to determine maybe how we're going to technically solve the problem at a high level again we're not going to spend a lot of time on it is that even viable can we technically solve this problem and so we continue to refine that epoch as it moves from left to right that makes sense okay each step has very clear objectives outcomes and later in the deck I'll show you a slide that has a lot of specifics around the activities that are happening a racy who's involved typically those types of things okay and at any step in the journey we can say we're not going to do it we may have said you know what this thing seems to support a strategy it seems to have a good business case but we get in here and we understand how we're actually going to solve it maybe the cost now of doing it is so high it no longer has a business case killer it's easier when you have a lot of like this because what the problem we have sometimes is if you've you've got an organization that spends months trying to figure something out you've invested that time and effort and we can't let it go even though everybody knows it's not the right thing to do okay any questions okay cool all right so I'm not gonna go through all the details again this the stack is will be available to you guys but it just demonstrate that there's a planting onion you know the highest level we're thinking about our strategy the strategy sets the context for the decisions we're making at the portfolio tier the portfolio tier sets the context for decisions we're making at the program tier owned and owned and under known right and that context is important a lot of times you'll go into an organization you'll talk to a team then the team can tell you everything about their backlog what they're building why are you doing it don't know it's in the backlog we're told to do it how's this affecting your company's strategy how is it changing things they can't answer that question so this sets the context I want our teams to understand all the way back up to why are we doing it because typically we create delivery teams that have smart people in them and I've been building software and solving problems their whole career let's let them understand why we're doing it because oftentimes they can help us create a better solution it's a pair okay so some of the artifacts that we think about from a portfolio management perspective now some of these may if you're using some agile tooling like rally or version one something like that some of these things might be replaced by that tooling epoch brief so that is just a very lightweight description of the epoch we'll talk more about that here in a moment that's the thing that's moving from left to right at the portfolio tier okay then portfolio planning sheet that's some type of sheet that we're using in our portfolio management meeting to help us do decisioning maybe there's some prioritization data and that spreadsheet as well an epic roadmap we'll talk a little bit more about that later but that's just a vision of where we headed 12 16 18 24 months whatever that might look like some kind of dashboard to make sure that we understand the system of delivery is is operating in a way that we expect and so if the dashboard turns red we know we need to go do something about that and release plans a credible plan based upon a predictable organization that allows us to make promises to our customers okay good all right so let's talk about strategic alignment and so when we think about strategic alignment we're making sure that that epic align store strategy and some of the activities that we're doing there is making sure from an intake that we're validating that the thing that we're determining to or deciding to do actually does in line with our strategy making sure if we have a business architecture making sure it fits within that and then anything that does in line we're going to defer or maybe just kill and then at this point we've got an epic brief that's been initiated and we only have epics in the backlog at the portfolio tier that align to our strategy okay so this is some of the stuff that you might see on an epic brief so a name who the name of the epic who owns that is there an investment theme or maybe some strategy strategic theme that we want to tie back down maybe there's some value statement a lot of times the organization's we work with will do a problem statement and typically it's of the form the problem of effects who's affected the impact of that is and then a successful solution would very distinct very succinct very crisp it really helps demonstrate the problem that we're trying to solve I find it to be just really valuable to our teams maybe there's some features and benefits we want to make sure that we start to understand our dependencies and risk and assumptions we probably don't have all of this clearly defined at this point but we will at some and then what do we think the opportunity case and typically that's a product management function that we build out get into demand management solution definition so this is where we're gonna validate that we actually can go solve this problem so so maybe the problem statement is around creating levitating automobiles well we don't have technology to do levitation so that's not viable we can't do it go kill it right so we want to make sure that we can viably create a solution that solves this problem so we want to validate that we want to identify work around risk and dependencies so this early on we want to start to frame it what those dependencies are because a bank I work with one time it had 17 different parts of the organization they potentially had dependencies with and those areas were outside of their control and one of those areas had a lead time of nine months so if I was doing something in the next release and I needed their assistance forget it it's not going to happen so we want to start to and that those are constraints right and if you have those constraints we need to start thinking about those dependencies much farther back than you would like okay so we've got our epic brief we've got some constraints filled out you've probably has some features defined and we've we've got some architectural and risk information at this point we also probably have updated our our way to shortest job first and I'm going to talk about part is a sh in a minute so we'll I'll give you a definition of what this means okay all right so from an epic brief we're continuing to fill this information out so again we're progressively filling this out over time we're not saying how often do you guys find that if you somebody creates difference for you to fill out and we just say oh well here's a template I need to fill out everything in the template and that's what we do right so yes there's a template here but we want to be very prescriptive about how much we need to fill out today versus what we need to fill out tomorrow we don't have to do it all we just need to fill out the the information today to allow us to make the next responsible decision okay cool okay detail planning so so this is where we're really starting to get into the details of what this thing looks like at this point we've defined features we've estimated we've got backlog items created we've got a really good understanding of our risk and dependencies and we've we've this is input into building out our release plans we probably revisit our roadmap based upon what we've learned because some things may be bigger some things may be smaller than we thought we're updating our plans from a portfolio standpoint so there's just a tremendous amount of work going on in the organization and this work is happening all the way down to the delivery team's potentially so the program team primarily is responsible for these activities and the things that are happening here but they have to go reach out to our delivery teams to get them to to assist the delivery teams are estimating they're providing feedback they're providing well you know what we could build this in this different way and it would take us less time okay let's go do that so it's a very collaborative environment in which we're doing this and this is on the portfolio of normal and you got to get information we feedback from the delivery teams mhm and the delivery teams are working feverishly to get there there go yep it's just this data mining is this going to be doing the pie or so think about we're doing a continuous flow right and so there's some collaboration requests for information from our via Libertines going on all the time and so I mean typically what we see our delivery teams spend about 10 percent of their time and I don't don't leave the room say Rick said but about 10 percent of their time supporting the program tier and above either in supporting them to create ready backlog for upcoming sprints or helping answer these questions but part of the the trick here is to make sure we build a program team that has most of the skills necessary to do this because I at this point know once we get into detail planning we have to have our delivery teams represented right but those earlier stages I should have sufficient skills on the program team to answer those questions I shouldn't have to go bug the delivery teams all the time but you might pardon yeah that's right the program team typically has you know product representation bas architecture or an architect may be technical leads are participating from time to time it's just what what's that right structure to make sure that they can accomplish those activities those outcomes yes but at the epoch trouble they're like the team is trying they already pretty much know what they want to work on but what does that ceremony look like when they're like doing some of that data gathering in who do they usually write down on that the the program team or yeah so so there's usually a cadence of the program team so just like portfolio teams have a cadence of meetings some organizations I work with meet every two weeks sometimes once a month just depends upon the organization program teams have a much faster cycle of meeting and working together and there's there's certain sessions there's certain meetings set up to go do these things and so out of that they may say well you know what we don't know you know what our dependencies are in this area of the system we need to go talk to one of these delivery teams to get some input and so that would be an action item they would take and they would go do that so they're managing that work and then they're interacting with delivery teams and external entities because we want to bring in if you've got dependencies for parts of organization outside of your control they need to be brought in to have these conversations as well a company I work with on the program team had representation from the organization that was responsible for deployment and operations of the systems and so there was someone on that program team that represented that area that they didn't go to all the meetings but there were certain meetings they had to be in because we had to have their input or and also give them visibility what's coming none of that helped yeah so there's there's different focuses right so there's focus own so let's say let's go back and dark so let's say that we're our epics are here so there's probably some some session where we're just getting the epic brief pulled together collecting our thoughts and and getting ready to see if it lines with strategy maybe there's something going on to understand if we can go build it what's the solution look like so how do we go do that so there's different outcomes that we're after and so I wouldn't say you've got this big meeting we're trying to do all of this you want to have very focused meetings aligning with these outcomes okay all right okay so we get into execution government governance at this point we're building this stuff we've made we've got a release plan the teams are working within that release plan and their commitments that they're making and we're assessing our progress it's just it's monitoring the system at this point it's traditional project management stuff but even here I mean if we find that they're things that we we've learned that we shouldn't be doing it's okay to kill it here too right that's difficult for some people but but we should have that option as well okay what are the different types of prioritization you guys use today when you're trying to decide what to work on anybody tell me this what's that probability and impact ROI ROI is risk here okay earlier investment so so that's interesting I want to come back to that when we get into read mapping okay so I want to talk about a couple of different partisan techniques so this one's been around forever Moscow right so must have should have could have won half the reason I'm bringing this up is that in a moment I'm going to show you an approach to Road mapping at a high level at that epic level that can leverage this and I'll say Rick didn't come up with this one of my colleagues at leading agile did I saw it and I thought that is cool I'm going to pull this into my talk and he said go ahead and do it all right good technique the other technique is cost of delay how many of you have heard of this how many use this whew okay okay jr. goals so Ryerson in his book the principles of product development flow said if you only measure one thing measure cost of delay okay and so the cost of lay is a revenue that could be earned eat eat month that a projects not the market part yes well it could be it could be savings a cost or it could be revenue generation right right well let's talk let's talk about this I'm gonna give you a real example okay so making this very simple I talked about this with a group one time and they dug into all the details of my calculations and let's don't do that it's just high-level so we've got these three features and we've got a car cost of the lay calculation and so each feature has a certain amount of time it's going to take to do and then each feature also has a dollar amount value that pair okay all right so now let's go to this this page so this is we do everything at once so we're working on all three features at the same time and that's probably is that the best way to work on things to start them off all right terrible way okay so you don't get anything done until you get to the end so you have a tremendous amount of cost of lace so $247,000 lost revenue okay so shortest job first so each job have a certain amount of time it took so let's work on the shortest one then the next shortest one in the next shortest one okay and so by doing that the cost of delay is 175 thousand so we've saved money over doing everything at the same time do the most valuable first so that dollar amount the one that gets us the most revenue let's do it first so the cost of delay is one hundred and eighty seven thousand but if we use the cost of lay calculation which does feature B first feature C then feature a our cross delay is only hundred fifty seven thousand dollars make sense so a lot of the tooling out there supports this you can put in the the values necessary for it to come up with us this prioritization technique for you now what's interesting is so work with a large organization one time and their tooling didn't support this so some of our cotton one of my colleagues created this pretty complicated spreadsheet it allowed them to put all the epics in they were able to create dependencies across other parts the organizations in the spreadsheet and be able to do cost of life and so kind of this stuff in pull it up on the screen and like everybody the room said well okay let's just do that well cost of delay is input in decisioning right just don't use it to blindly go do something use it as input to have a conversation because you may choose to order this in a different way there may be other reasons why you would do that it's just a technique to help you in your partition like that good okay so I saw a couple of hands that are using this technique yeah right that's right that's right okay so it's been effective for you guys yeah okay cool all right awesome all right so how do you guys met how do you guys understand what your your capacity is in your organization today about teams ok velocity of teams what else so so you have a certain amount of capacity and organization yeah how much work how do you how much work you can get done right let me ask you let me show you slide here all right Bing Bing Bing how many of you have worked in organizations where you try to create something like this you put every person in a spreadsheet all the days or weeks how many hours are going to work well Joe's going to be off next Monday let's take eight hours out who's going to be out for a week let's take 40 hours out and that's how you manage your capacity do you find that to be effective no okay all right why do people do it takes a lot of time their managers whose job is this right yeah right yeah so let's talk about capacity and how we express capacity in a different way some options here so T months so getting back to your comment about teams each team represents capacity so maybe we're represented in t months our team Sprint's how many you know how much of a team can do per sprint team releases or story points that's another way to express capacity right it's good with that okay what's necessary for this to happen yeah consistently so if we are not stable if our organization is not stable then none of these matter right because this implies that we have a predictable organization that can perform at the same level ongoing so we have to make sure that we build that predictability in good with that but once we've done that then we can start to make decisions about how we leverage that capacity how many of you have different investments mixes you've got different types of work that you do in your organization and you you set out a percentage of certain type of work that you're going to do how many of you do that in your organization a few so maybe certain percentage for break fix work certain percentage for new product development things like that so we can start to do that so we can start to understand what our investment mixture looks like and then make sure that we can apply that investment mixture across our teams to meet that need and depending upon the tooling we can report upon it we can make sure that that those things are being accomplished across those teams ok all right how many of you are doing road mapping so thinking about farther out in the future okay a few hands how far out a year most people or a year yeah okay a quarter a quarter how many of you have a processor in your company where you do annual planning yeah I'll talk about that in a minute so road mapping so road mapping gives us the ability to think farther out into the future about the things we may do and so we don't have to spend a tremendous amount of time getting the detail for stuff that we're doing twelve months from now but they're big rocks that's where we're headed but everybody has an alignment about where we're headed we have a lot of detail on the things that are upcoming we have less detail as we move to the right but they're directionally sound one of the reasons this is important ties back to the something you said is that if let's say that this big rock requires some capability of an organization or maybe technologies that we just don't have so for us to do that we need to make some investments back here to allow ourselves to be set up for success here and so that rat roadmapping helps it really helps from an architectural perspective because it allows us to create better architectural roadmaps build the right things for the future because we know what's coming it also allows us to manage our dependencies better if we know some of these big rocks are dependent upon different parts of the organization that have long lead times then we can start to get ahead of that that makes sense okay some of the organizations I've worked with they do annual planning and it's a painful process they get into the September may be time period and and all the doors go closed people are in rooms conference rooms we're laying out everything we're gonna do for the next 12 months and it's painful and I was I was in a meeting with a group on time and they were just agonizing over this and I said look guys I said you want to be directionally correct you don't have to have all the details and let me ask you a question so you did this a year ago looking back upon what you accomplished this year how closely did that align with that original roadmap and they said well it didn't well of course it didn't it's directionally appropriate but we know we will adapt and change over time right and so what we do a lot of times work with organization to do quarterly planning and so this roadmap gets updated every quarter maybe every month but typically every quarter so then when you get too close to the end of the year and you're doing your annual planning you just have to add the next quarter right it becomes a less painful process okay so this is the the sequence of flies which I want to talk about Moscow so this roadmap is rolling ahead so many quarters and it represents these epochs and the epochs that are closer to us these are being done these are being plans we know a lot about them but the rest of these epochs are just on the roadmap right directly this is where we think we're going and so then you can start to have these conversations well this is active so of course it's must abacus we're doing it this is plan so these probably are must-haves but then we have some of these different flavors out here as we look at our roadmap okay and so let's apply those and so at this point what do we know at this point we've dropped down away from epics down to features so we've got must have features should have we know a lot here don't we okay do you commit to the could haves mmm don't do that do you commit to the wish to house mm-hm do you commit to the could house probably not what about the must-haves we can make that commitment right yeah and so yes the lighters yeah yeah that's right well so Kano model is the tip it's particularly used in product management we're trying to understand table stakes the things that you have to have the things you then and then there's something called two lighters we don't necessarily have to have them but if we did them our customers would be just ecstatic right and so sometimes we choose to do that that's not a bad thing to do so if we have the capacity to pull those things in but we were Nikki and I were talking earlier about a situation where you've got some capacity because we know there's unplanned work coming in and if we have a sequence in which that unplanned work did materialize maybe we can pull in a little lighter at that point because we've already committed to her committed items we're getting that stuff done now we've got some additional capacity to do some of these other items that would be kind of cool for our customer okay so at this point we have a more reliable commitment must have features we want to realign this and if we finish early then what would we do if we finish early here yeah what do we do to these let's let's start to move those things in right and so we're always pushing we will always want to push from right to right to left I have to think about that because I'm backwards for you guys the must-haves to that that side makes sense and it's it's this is a this is the thing that you can do just put some cards on a table you don't have to have a tool you know get some sticky notes put these things color code them must have should have could haves and start to rearrange this stuff and have discussions because you may have a situation where well you know what I believe this is a must-have let's talk about it let's have that conversation and realign that be very dynamic it can be pretty fast to do these types of things okay all right when you get into some details on the governance model remember this picture this picture is just the flow of epochs and features and stories across the organization the structure of portfolio program delivery teams okay so when we work with organizations this is typically our starting place and for each one of these blocks we want to talk about what the objectives are outcomes activities who's involved so this next slide is going to be way too much information but it just gives you the level of detail that we can talk about and this is where I'll touch upon compliance issues okay so this is the detail in the governance model for the portfolio tier and so for each one of these blocks life cycle of the epoch moving from left to right we have the purpose we have activities the types of things that are happening at this time so this gets back to your question about meetings that we might want to have because these activities have to happen outputs what's the expected output from this state and then who's involved so we've got a racy at the team level okay and so for intake we're just making sure these things are initiated and we want to make sure that at this point it aligns with strategy that's all we're doing okay but then as we get into solution definition we want to to make sure that we're validating the business case the viability of our organizations to build in we want to understand our constraints start to identify that work we want to start to understand our risk in dependencies and so these are some of this is not a menu that you have to fill out it's the things that you might do depending upon your organization but this is a set of things that you might output from this state right and then once we've made that decision if the epic moves to the right we get into released targeting and so this again gets into the rulli's planning activities that we typically do all right a lot of detail going on here at this point but by the time we get into execution we've got three to or Sprint's worth of backlog created for all of our teams we've got our dependencies managed we've got risk managed we've got a risk burned down all those things are happening we have a credible release plan that everybody can shake their head and say yep thumbs up we we believe we can commit to this that good again just making sure the system of deliveries performing as we expected and we're meeting our commitment and then we validate the epic making sure that it does what we expected it to do so this is where the earlier discussion about getting validation from your customers if you can bring those customers in to validate let's do that there's certainly validation going under the team level every single sprint are more frequent more frequently than that but I would love to have feature level of validation going on with our customers as frequently as we possibly can right I've got organizations where they'll do you know every two sprints they have a little mini UAT with their customers and they get feedback from that okay and one of the things we want to make sure at the end we do as well is here was our business case it's out did we meet that business case and maybe that's something we can do immediately sometimes it takes time you know maybe the business case was a certain amount of revenue up left over six months maybe we don't we can't validate that until six months later maybe we can see some trends but maybe we can't truly validate it then later okay so similarly to the portfolio tier same little detail for the program tier so this is the life cycle of features same thing going on this is where solution design are we able to craft a solution for the problem they're trying to solve are we able to create credible release plans so all of the stuff that's happening there and again we talk about who's involved who's who's responsible who's informed all the things that we typically do with the RACI chart right making sure that we have clarity there and this may change depending upon your organization but but it's directionally correct this is typically what we see the most okay I'm a few clients using safe yeah I mean you know it's interesting so safe is a very prescriptive I'll say that was probably not appropriate but you know it's a very well-defined approach for delivering value in certain environments we we find there's some aspects of safe that we feel we do right there's a lot of the stuff that there's a lot of overlap between what we do and what you see safe does we we find that you you have to tune your solution for an organization based upon where they are and where they need to go and so it's not a one-size-fits-all we need to make it very prescriptive based upon where they are where they're headed and so that's where the the dynamic is I think the difference yep I didn't see that in the program why do you lose or fully they'll help you continue doing yeah it's probably just it well probably for where this came from we had in the decadence of meetings for the Werdum team every month they had a retrospective so it was less a retrospective at the gap at the feature level is more they do a retrospective every month and so I think for the the example that this came from that just wasn't relevant here but there's no reason why I couldn't put it there right if that's meaningful so what I typically do at the portfolio level is again the same thing at the at the program team level I would do a retrospective every couple of months it depends upon how frequently they're meeting if the portfolio team is meeting every couple of weeks then I'll I do a retrospective for the every month for the first maybe six months but once that portfolio team gets performing well then maybe the retrospectives happen less frequently just depends because the retrospective is really helping us create a high-performing portfolio team right okay good question thank you and again I'm not gonna go into the delivers here also you guys have the stack so and I will share with you the PowerPoint which will be one one talk I did they wanted a PDF but the PF is not very helpful so you guys can take this powerpoint and use it as you feel feel inclined okay so I think we've talked about oh you know what so as we get into solution design and and particularly release planning but here so how many of you have organizations that have to do penetration tests security tests things like that yeah and so so I would want to start to have the conversations about those requirements and needs here because typically what happens we don't do it until we're executing that's - yes the virgam tear it it's too late here we want to start to have those conversations so if we have certain compliance and regulatory requirements and needs particularly if we have to work with other parts whereas a to make sure that we can pass those we need to start to frame those conversations up early doing it back here is too late and what we specifically I don't think we have in this example but a client I work with we specifically list it out bringing in the security team to do a security review we don't know a lot yet but I would rather have a security review that's incomplete here and learn something than to late makes sense okay all right so portfolio management focuses on valuable things balancing capacity against a man how to be adaptive since work continuous improvement and then how to support government security audit and those types of things and from an audit perspective it's interesting all here well we have to do X Y & Z because audit says we do well that's not true audit is just checking to make sure you're doing the things you said you were going to do right you're responsible for that so if you're doing things because audit says you have to do it but they're no longer providing value then we need to change what we're saying we're doing make sense yeah yeah but but yeah there's those external audits that you have to do but a lot of times when internal audit internal audit is just making sure we're doing what we say we're gonna do right and we before I joined leaning agile of my colleague and I at that company we redid the SAS 70 control objectives it was just a mess and and and we were getting beat up all the time because the things that it said we were supposed to do just wasn't relevant anymore so just rewrote them and we were fine at that point because we just redefined what we said we're gonna do then the next time we had an audit we passed because we did what we said we were gonna do thank you all right cool any questions yes mm-hmm yeah well typically that's something you would see happening at the program tier so if you've got product people involved so typically journey mapping those types of things you're defining your personas so that's part of the requirements elaboration process is part of determining what you need to build how you're going to build for your customers so yeah I would I would an organization I had had a strong UX organization and they did a lot of journey mapping and so that was input as part of the epic definition and feature definition so doing it down at the describe team level it's too late right it was input into creating a good backlog for our teams good other questions just tired of listening to Rick and want to go home I'm sorry yes yes I don't think I truly understand the quite the problem yes oh oh oh well okay so organizational structure from an HR perspective versus structure delivery yeah well that's all I mean it's a problem right if that's right that's right yeah it's disruptive so I would want to get up under while that's happening you know why why does an organization feel compelled to reorg every three or four or five six months all right well well well so the thing if you're truly doing a transformation organization this is not happening down to scrum teams this is a company transformation from the top all the way down so we're having those conversations and so you'd have to have some influence and a lot of times it's a lack of trust right if we can't demonstrate predictability and a stable delivery system there's people at the top that we have to make change but we can demonstrate an approach by using structure governance and metrics to allow you to create a delivery system that becomes stable and predictable and because you just happen to get Bob to come down yeah so that at a certain level you can't protect against those right but you want to continue working up the organization to create the influence necessary to keep those things from happening or at least find out why they're happening my experience is I haven't I haven't found most companies having that amount of disruption that that may not be representative of what's out there but I just haven't experienced it the organization's I I've been experienced tend to be more stable than that so other questions was this useful okay awesome more way what do you mean two elements right so yeah so well so there are tools there's tools in the agile space that support this so you know if you wanted a agile lifecycle management tool that support support level management program management all the way down to deliver teams you know version one does it Riley does a jurors made good progress here in the last year and being able to do portfolio management there's a number of tools out there that do that I mean to the point you know we've had organizations as you spreadsheets my works to yes I mean we will look for a tool that supports kind of waterfall and the future my child do you have to lose a football yes that just makes me feel ill you have to work your way towards a job yeah right right well so it gets back to the discussion we had earlier about doing a slice right because so because if you're doing waterfall you've got systems in place and so what we want to do is let's let's create a slice of the organization that operates in an agile fashion tool them up appropriately show that success and then as these people move off of waterfall they're just expanding into that tool set so buying a tool to try to do both I don't know that that's the right answer especially if your eventual journey takes the whole organization to agile I don't know Paulie deserves deeper conversation so thank you which I'm gonna play off the lives yeah any other questions why I've been an organization that has both agile and waterfall and waterfall for climatization hmm yep so it does cross in the same organization some of the same resources yep or in both types of prod yeah and it become it's just becomes a project management it's a planning horizon issue at that point because I so the the organization I told you earlier at 17 different parts of the organization that I had dependencies owned all those parts were waterfall this part this part of the organization was agile they didn't it didn't matter I don't care if you're a waterfall I just care that you make your commitments now if you're lead times nine months that's another problem right but yeah if you if you if you can meet your commitments then we're good okay any other questions thoughts eat mayonnaise on this or that but one of the situations that we have is that we have a pretty tight deadline to get some major models out the Wesley's just converted over to doing a new product so that's their central warehouse modules sort of thing along right about jeans order estimating so but we also have things that we're still working on right now we're getting the customer feedback and so and those were like gaps or bugs or just whatever you do with maybe new enhancement requests so we're trying to figure out like with forecasting like our velocity when we could actually project to have this warehouse central kitchen actually done swaggy you know what we think this thing made possibility plus being able to commit some of these gaps and this customer feedback that's coming in how do you like manage this like long term commitment that we have to get this done in time mr. Feeny to meet the stephan1 simple kitchen but then also we've got all these things that we've pushed out there and then everybody's like well yeah so it gets back to understanding your investment mix right I'm gonna use this chart to just illustrate muses chart for different purpose but but let's say that let's say that 60% of your capacity is focused on that new product development that gives you certain amount of capacity 40% for the other stuff and so we just have to hold ourselves to that standard if if if you have sufficient break fix customer requests coming in to meet that 40% then manage it that way if maybe if it's only 20% the rest of your capacities to this new product development and just manage it that that means that the flow is pretty even as far as that unplanned work coming in and maybe you just have to make it so you know maybe there's spikes but your response back to the customer is this is when you're gonna get it you we got it here but you're gonna get it to spreads from now not this print and just manage it that way because you should have a good understanding of your velocity right it's just what is your investment of that velocity toward those different categories of work Yeah right they're not high performing it well it is a wild ass guess so you know holding me to that commitment like you need to call us yeah well that was the other thing I was going to say if you know your demand is greater than your capacity maybe the company has to make an investment um you know my bank account doesn't support me buying a Lamborghini so if I want a Lamborghini I have to increase my bank account somehow right yeah and I don't know your problem I know but the way you're describing it it's like I'm just throwing so much that you can't give a common you can't get a constant velocity because it just it just being thrown at you the whole time yeah well this sounds to me like there was a belief and a certain throughput that the team had that you haven't obtained which that's reality this is what your throughput is look what can we do to prove it but there were some assumptions made that we're wrong yeah right okay yeah well then there you go there you go that's right that's right yes well I had a 350 horsepower engine in this car and now I'm running with a hundred horsepower and you're expecting the same outcome right yes so we'll do three weeks here then we'll roll out three weeks and we'll roll up deuce I said time out May 10 we plead on each one of those draw a vertical line you just killed us Yeah right you got 10 10 10 10 roll out and like oh my god I said yeah that doesn't happen until June of next year I can fix this right but I'm gonna show you that exactly with what my team can do yeah and I said like I said do you why a Yugo or a Lamborghini yeah which one does we need more people we need four teams instead of - right right right and if we have that you might have the 14 we got that not only that and also some nice to have it what to have projects later on we'll have that in place that we do it right person maybe typically it's set at a higher level strategy so based upon the strategy the company here's what we're willing to spend to support those typically yeah well so so it's interesting right so this is so a lot of times most organizations walk in they're very project-based funding and what we want to do is we want to fund teams we want to fund capacity and make sure we're picking the right things to do with that capacity it's a different way of thinking about it right and that that's a hard one to pivot as well I see a lot of companies well we have some of those too yeah Brian or do they want to put in resources for something like automated testing right so there's but even those conversations have to demonstrate value because the business doesn't care that we're doing automate testing or not they care about the outcomes and if we can build a business case that this thing that took us six months to build last time you wanted it if we had invested in automated testing maybe it would have taken three months so that's a 50% reduction in cost to deliver the same amount of value so we have to have business discussions about even those technical things and you have to have a backlog so make use that capacity that's right that's right right anything else all right guys well thank you for coming out been a good crew

Channel: LeadingAgile

Views: 15,301

Keywords: agile, portfolio management, software delivery, scaled agile, software development, agile portfolio management, project management, lean portfolio management, business agility, project management 101, project management tutorial, project management fundamentals, project management construction, project management tools

Id: lVWvq6GN5rg

Length: 76min 38sec (4598 seconds)

Published: Wed Sep 20 2017