 All right. Good morning, everyone. And it's a pleasure to be here. We have Scott Ambler with us. It's a real honor to have Scott Ambler doing this webinar with us. For those of you who've been at the 2012 conference, you might remember Scott Ambler's funny panel discussion on which he basically pulled off the Star Trek series of jokes or kind of nicely weaved the whole thing in. I think it was just fantastic. And we wanted to relive that experience. So we thought if we cannot have Scott Ambler in person, we can at least do a webinar and obviously learn from his experience with this blend agile delivery. So I'll quickly hand it over to Scott without taking much time. And Scott, over to you. Thanks again. OK, thank you very much, Rush. OK, so I'm going to start sharing my screen here. And that is not working well for me. Oh, there it goes, OK. OK, let me just get the screen there up and running here. And OK, you should be able to see slides now. OK, so thank you. So what I'd like to talk about for a bit is dispensable delivery. And more importantly, how it forms a basis from which we can scale agile. So I'll speak for 35, 40 minutes and then we'll go to questions and hopefully have an interesting discussion. So anyway, so who am I? So I've been doing this agile stuff for a long time. I'm the person behind a few of the agile methods, like agile modeling and agile data. And the last few years I've been working on dispensable delivery, which is, as we'll soon see in a few minutes, a decision process framework. So it's a bit different from the way some frameworks are being developed these days. I think it's actually one of the few true frameworks out there, so we'll see in a few minutes if you actually believe me or not. So anyways, what's the overall strategy here? So I'm going to make an argument that there's some really good ideas coming from the agile community, some great philosophies, some great techniques, some great ideas. But it's only a start. And to really make this stuff work, you need to put it all together. So dispensable delivery in many ways. It answers the question, how does this stuff fit together? And when do you use each of these techniques? And how do you combine them? And one of many observations I'm going to make today is that people are making process-oriented decisions all the time. Even if you decide to just follow Scrum out of the box or follow XP out of the box, that's still a process decision. And whether it's a good idea or not for you, it remains to be seen. But you're still making these decisions. And our point is, let's make these decisions intelligently. Let's choose what's best for the situation you find yourself in. Let's, when we're doing retrospectives, let's actually make good choices or make better choices based on knowledge as opposed to the impressions and guessing. So anyways, some of the things we're going to get at with dispensable delivery. And I'm going to show how dispensable delivery forms the foundation from which you can scale. And so what happens is once you know how to do agile software delivery from end to end and you can do it reasonably well, then you're in a position to try to take on some of these complexities that we find ourselves at scale. So having a larger team, having a distributed team, having a facing great domain complexity or technical complexity. So it really, first we want to get good at walking and then we'll learn how to run. I found a lot of organizations try to jump too quickly into doing agility of scale and then running to trouble. And it's not good for them. It's not good for anybody. So let's try to be a little bit smarter about this. Excuse me. So what does it mean to be disciplined? I get this question all the time. So because the fact of the matter is that agile itself requires great discipline to begin with, it's hard to do practices like tester and development. You've got to be disciplined to really pull that off. You've got to be disciplined to work closely with your stakeholders and to follow their priorities and to interact with them effectively. So there's many, many ideas and techniques in agile and in lean that require significant discipline. So what am I getting at? Well, sure, yes. We need discipline for the base agile stuff. But other strategies such as learning continuously and actively trying to reduce the feedback cycle, we talk about it a lot. But actually doing it and living that sort of stuff requires significant discipline. Taking a goal-driven approach, I'll talk about that a bit. So getting away from some of the prescription that we see in the agile community and actually truly owning our processes and truly telling our techniques for what we need to do. Being enterprise aware, so realizing that the team that you're currently working on is only one of many teams. And to be effective, we need to work with others in the organization. We need to leverage and take advantage of previous work or work in progress from other teams. So we really need to be smarter about this. We need to actively streamline the bookend aspects or phases of agile delivery, the project inception or initiation efforts, sometimes called, mistakenly called spring zero, the release effort or the transition or deployment effort, which we might be able to release or which we might be able to reduce by continuous delivery practices. It requires significant discipline to adopt agile governance strategies. It's interesting. Many people in the agile community believe that governance is a swear word. We don't need no stinkin' governance. Well, you are being governed. This is one of the hard realities of software development. Somebody is keeping an eye on the money. Somebody is keeping an eye on what people are doing and keeping an eye on the quality that's being produced. Now hopefully good governance is all about enablement and motivation. And unfortunately, I think one of the reasons why some people are so against governance is because they had actually been governing in a very poor way. Many IT departments actually have traditional governance strategies based on delivery of documents and having reviews and going through quality gates and good stuff like that. And a lot of it's overhead, a lot of it doesn't really help the team, doesn't really enable the team to be better. Yeah, so I'd be better about that too. But just because you've seen poor implementations of governance doesn't mean that governance is a bad idea. It just means that you've experienced poor governance. So why not provide advice to senior management of how to govern you effectively? Because you will be governed. And personally, I find it better to be governed effectively than to be governed ineffectively. So I think it's time for the agile community to step up and really take the bull by the horns, as we'd say, in North America, and help senior management understand how to govern us. So anyways, so what's Disponage Delivery all about? So first of all, Disponage Delivery is a process decision framework. And what we mean by that is we provide guidance for helping you make these process decisions that you face throughout a project or throughout product development. And you might not even be aware that you're making these decisions or perhaps they're being made for you. So we really try to completely and utterly get away from a prescriptive approach, and we'll see that in a few instances. So we take a golden approach, not a prescriptive approach. That is a hybrid framework. So we take great ideas from Scrum and Exchange Programming and Kanban and Agile modeling, Outsiding Development and SAFE and many others, and show how you combine them, how to apply them effectively, how to apply them in the right situation and combine them. So in many ways, Agile or Disponage Delivery is the glue between many of these techniques. We do the heavy lifting on the process decision side of things. That way you can stop worrying about your process and actually get back to developing real business value for your stakeholders. We're solution focused, not just software focused. So we're explicit about that, we're enterprise aware, I was talking about that earlier. So there's a bunch of very good ideas that can really help you up your game as an experienced Agilist. So as I said, dad's a hybrid framework. We take great ideas from a variety of sources. So dad really is the glue that helps to fit all these process bricks together. And what's interesting is, dad adopts ideas from a wide range of sources, not just Agile. So we adopt ideas from the lean community, from the traditional community. I think it's important to respect the people that have taken a traditional approach in the past. Most of the world's major systems have been developed under a traditional life cycle. You'd be hard pressed to do any sort of electronic financial transaction that doesn't hit multiple systems that were developed in a traditional manner or to take any sort of, any form of transit that where the software for it wasn't built in a traditional manner. So I think we need to observe that the world is running on software that in many, much of the software's developed traditionally and that's okay. There are some good ideas coming from there. And even from the unified process, we all love to bash the unified process, but if you actually take the time to look at it, there's a phenomenal wealth of material there. Sometimes, yeah, it's a bit heavy, but we can quickly interpret some of those ideas and lighten them up and really take advantage of some great proven techniques. So this type of things we did when we were first formulating the DAD framework. So one of the things we do is DAD promotes this idea of a full delivery life cycle. Some agile methods don't do that, but DAD wants to give you an end-to-end process, at least an end-to-end delivery process. So we talk about how you initiate a project team or a product team. We cover how you transition your solutions into production or into the marketplace. So we really do look at the full picture. And we use some of the agile square words like phases, there are phases in a project. So I'm a firm believer in empiricism and I run industry-level surveys on a regular basis. And several times now I've examined and I've explored where teams are actually putting their efforts. And some things we've found is that the average agile team spends a little over a month doing project startup stuff, project inception stuff. The average agile team has sprints or iterations of two weeks in length. And the average agile team spends about a month doing transition. So we should respect that. These are easy things to observe. So let's just observe them and respect it and have a fuller life cycle actually be honest about what we're really doing and then find ways to get better at it, of course. But first of all, we need to be clear about how this agile delivery stuff actually works. So this is, now I went from a high level life cycle to a fairly detailed one. This is the basic or the agile life cycle supported by the DAD framework. As you can see, it's scrum-based. We've done some improvements to it, I think. We took some of the marketing out of the scrum method. We use terms like iterations and team lead as opposed to sprints and scrum masters. We're a little more sophisticated in the way that we describe the backlog. It's really a work item list that is prioritized in a risk value approach, not just a value approach. It has different types of items on it. It has different sizes of items on it, as you can see. We also, we show a full delivery life cycle and we also show other aspects outside of the delivery life cycle. So we show that there must have been some sort of project or product identification or ideation effort underway, some sort of a selection effort to start the project off or the product team off. Many organizations have enterprise architecture and business architecture product management type activities at the IT or enterprise level, providing input into what the product teams are working on. There's an operations and support effort in most organizations or if you're a software shop, maybe you're selling software into the marketplace. And the vast majority of agile teams are actually in a position where they're working on a new release of an existing system. So they're actually getting feedback in the form of de-fact reports and enhancement requests coming in from the help desk or the operations people or just end users directly. And these are new requirements that should be prioritized and put on the stack and work on it. So we make all these things explicit. We also include some explicit milestones. You can see them along the bottom of the slide. And some of these things are built right into Scrum. So for example, in Scrum, they talk about having a minimally viable product. That's the sufficient functionality milestone. In Scrum, they talk about regularly asking about the viability of the project. That's the project viability effort. Early in the project, we should come to some sort of a stakeholder vision as to what we're gonna do. Smarter teams prove the architecture of working code or early in construction. And then you release your production when you're ready to go and hopefully at some point you end up with delighted stakeholders. So that's more of a lean concept I guess, but still an important one. So we promote a full delivery lifecycle in that. Another thing we do because we're not prescriptive, we actually support several life cycles. And this is based on the observation that teams are in different situations and some teams that make sense to do a Scrum-ish Agile type of life cycle. In other teams or in a situation where it makes more sense to do something leaner or more along the lines of Kanban. And because we see this in organization after organization, it makes sense to explicitly have that in the framework and to provide advice for when you would like to do the Agile type of life cycle versus when you would want to do the lean life cycle. So one of the things we're trying to do too is let's get away from some of these religious battles. There's people are constantly arguing over, my process can beat up your process. Well, who cares, right? Just do the right thing for the situation you find yourself in. So it makes sense to go lean, go lean. It makes sense to go Agile, go Agile. We also support continuous delivery life cycles. So after a while, as you improve the way that you work, and if you keep your team together, then inception basically disappears, right? So once you get going, well, you just keep going. Smarter teams will squeeze transition down from a multi-week or multi-day phase into a multi-hour or multi-minute activity. And you'll do this through some of the continuous delivery type techniques. So anyways, the point is that some teams in organization will be doing more of a continuous delivery approach as opposed to a project-based approach, and that's perfectly fine. So once again, use the right life cycle for the situation you find yourself in. That also supports what we call the exploratory life cycle, based more along the lines of lean startup practices where if you're in a situation where you don't quite know what your stakeholders want, or they can't tell you for whatever reasons or you're in a R&D type of a situation, well then, the lean startup strategies of trying to learn quickly, of having concrete experiments that you put into production or into the marketplace, so that way you can get feedback really quickly, the need to pivot, stuff like that, all built right in. It's very common to follow a life cycle like that until you finally hone in on what you think you can make money at, and then you might decide to convert over to another one of life cycles that we saw previously, or you might want to continue on the lean startup approach. Do what's right for you. So the point is that we don't prescribe, dad doesn't prescribe a single life cycle, it provides flexibility and provides advice to help you make these important process decisions. So I truly believe we need to start moving away from the prescriptive nature of some of the agile methods, even the ones that claim not to be prescriptive and yet they very clearly are. So it is what it is. I'm also a firm believer that teams should own the process that they follow. A team should decide, should decide and tailor and improve their process. And this is a good thing, this is easy to say, but most people don't have that, most teams don't have the process knowledge to do this well. And I see team after team of very smart people doing the best that they can, but they don't do advanced techniques, they don't, or even not so advanced techniques, they don't even know about them, they don't even know to go looking for them. In many cases, they don't even know the words to use, to do a proper search on Google or Bing or whatever. So it makes it very difficult for them to do process, if to do really do process and to really own their process because they just don't have the skills to do it. So keep that in mind a few slides from now. Dad supports a robust set of roles because agile software development or software development in general is pretty hard. There's a lot to it. And when you take a look at the full, when you consider the full delivery life cycle, when you start going into technical aspects of software delivery or solution delivery, as well as the leadership and management type issues and scrum addresses, well, you end up with a more robust set of roles. When you start worrying about scaling, I'll talk about that in a few minutes. I mean, you start seeing some secondary roles coming into play too. At scale, you find yourself in a more complex situation. And as a result, you'll have a more complex way of working that reflects the complexity of the problem that you face. So let's be a little bit smarter about this. Let's start giving people real coherent options. I was talking about this earlier. Dad teams are enterprise aware. One of the very healthy things about agile is that it promotes this idea of team awareness, of teams work together to build software to build solutions. I mean, that's great, but it's not the full picture because my team has to work with other teams to get the job done. There's other development teams that are in flight along with mine and we gotta make sure we don't step on each other's feet that we actually help each other get the job done that we follow existing standards in the organization. We leverage existing assets, we fix things, we pay down the technical debt as we go. And to do all these things, to work with these other groups to leverage the enterprise architects and other enterprise professionals, it really requires enterprise awareness and being aware of the rest of the organization and how you can work with them and actually enhance the overall organizational ecosystem. So it requires a bit more maturity or robustness than what I see in a lot of agile software development teams. I spoke with this a bit earlier, governance is built right into Dad. The idea of being, once again, being that if we as a community don't step up and help senior management understand how to govern us effectively, well, they're gonna take it into their own hands, they're gonna probably continue to govern us ineffectively, and that's just not that great of an idea. So, and to be fair, there is a lot of important aspects of governance built into techniques like Scrum or unified process or others, but I think we can really up our game a bit and have a lightweight approach to governance that actually helps us to get our job done as opposed to hinder us. Like I said earlier, I see a lot of governance efforts that really seem to be more about hindering us and helping us, and it doesn't have to be that way. It is possible to be governed well, and it's actually highly desirable too. So anyways, this begs the question. I made a claim earlier that Dad is a foundation for much to scale, so well, how do you scale agile? I think that's a valid question. So first of all, let's just review what I claimed earlier that the agile techniques are a great start, but we really need something like Dad to put it all together and really help define how to end to end, how do you do this agile delivery stuff or lean delivery stuff as the case may be. And then finally, once you've figured out how to do it in fairly straightforward situations, then you can start getting a little more complex. You can start dealing with the agility at scale and compliance issues and large teams and geographic distribution, all that good sort of stuff. What does that look like? So one of the ways to enable scaling is to move away from prescription, to move away from this. The only way that we manage requirements is a prioritized stack called a product backlog. Well, no, there's many ways you can manage changing requirements, and that's just one of them. And it's a good one, but it's good in some situations and not so good in others. So wouldn't it be nice to have a choice? So when we started putting that framework together, it's all based on empiricism. We observed teams around the world, we were working on, some of us were working on these teams, and the interesting thing, the teams that were really good at agile, particularly the ones that were starting to get into scaling, they were all working in different ways. They were doing similar things. Don't get me wrong, but there was no one common way of doing things, and this is problematic when you're trying to describe, how do you go about this stuff? How do you give some advice? And it took us a while, but we've actually realized that even though these teams were working different ways, they were achieving the same basic goals. So early in the project, they were doing things like putting the team together and coming up with the initial scope, the initial stack or requirements. They were doing some initial architecture modeling, they were doing some initial planning. They were getting money, they were getting funding for the effort somehow. They were putting their tools together and their workspace together. They almost always were doing some initiation of their risk management stuff. So, but they were doing all these things in different ways. So they were achieving the same basic goals, but in different ways. Throughout construction, these teams, the main teams were choosing to produce a potentially consumable solution, advanced concept over just doing potentially shipable software. They were addressing changing stakeholder needs in some way. They were trying to move closer to a deployable release to, they're getting closer to this minimally viable product. The smarter teams would prove the architecture early. Many teams would pay down technical debt through refactoring and through other techniques. Towards the end of it, just before they would deploy, they would actually do the work to get ready to deploy. And then do the deployment. Throughout a project or product development, there'd be ongoing activities such as growing team members. People would be doing learning activities, like going off on training, getting mentored, pairing, good stuff like that. We'd be doing risk mitigation all the way through. We'd be doing process improvement and environment improvement all the way through. We'd be coordinating our activities. We'd be doing things like holding daily standup meetings perhaps and interacting with other teams and all those good sorts of things. So these were all common things that were happening. So all these teams that we observed were achieving these goals or at least subsets of these goals, but they were doing it in different ways. So this is an interesting observation. So what would happen is, so we came to the conclusion that we're really, to really understand how to do Agile, to really tailor Agile, your Agile approach to meet the needs, the situation you find yourself in, to really own your process, then you need to understand what your options are. You really do need to take this goal-driven approach. So I'm gonna walk through the notation of a couple diagrams in a moment to show you. So these are basically decision trees or some weird form of mind maps perhaps, but we call them goal diagrams. So a goal is shown as a rounded rectangle. So three of the 22 goals that we call out in data form the initial team, expose, gop, and so on. Then each of these goals is described by an issue or a process factor. So for example, when you're forming the initial team, some of the things you need to take into account are, well, where you can get people from, what's the size of the team you're aiming for? I mean, where are the team members, what team members are gonna be on, what people are gonna be on the team, how are they gonna be distributed? How available are these people 100% on the team? Are they 80%, 50% or combinations thereof? And then for each of these issues or process factors, you've got options, you've got different choices. So for example, for geographic distribution, is the team co-located, are some of the people partially dispersed, you've got a few people working remote, or is the team fully dispersed in ways in a different location? Do we have distributed subteams or combinations thereof? And for each of these options, there's advantages and disadvantages and considerations or situations where it makes sense to do this stuff. So no technique is perfect. No technique is good in all situations. They all have advantages, they all have disadvantages, and they all work in certain situations and work very poorly in others. So wouldn't it be nice if you're able to understand the situation you're in, then wouldn't it be nice to choose the techniques that make the most sense for you? So that's the entire gist of the goal-driven approach. So what does this mean in practice? So one of them, so I'm gonna work through, very quickly work through four goals. So of the 22 goals, what we've noticed is that four of them take the brunt of the tailoring when you're applying very scaling factors like geographic distribution and team size and technical complexity and so on. One of them is exploring the initial scope. So during inception, or sprint zero if you wanna call it that, you need to do some initial requirements modeling. At least do some, identify some initial user stories if not be a little more sophisticated. And so some of the issues you need to consider are what's the level of detail we're gonna go to or are we gonna have a lightweight specification, maybe a bunch of user stories and index cards and some whiteboard sketches. Are we gonna have a big requirement up front and a detailed specification? Are we gonna do no modeling at all? How are we gonna go about modeling is gonna be formal, informal. We're gonna do some interviews. How are we gonna manage the work? So when you're first doing the initial modeling, initial requirements modeling, one of the driving factors of some of the other choices are how are we gonna manage change? So are we gonna do a product backlog or are we gonna be a little more sophisticated and do a work item list or even a work item pool? I could take a more of a lean approach. Or maybe we're gonna do formal change management. I've been on a few life critical agile system projects where it was mandated do a formal change request process because we were building medical devices and when lives are on the line, you're a little more careful about how you do change and rightly so. Once you're approaching on functional requirements, you're gonna have an explicit list or an official definition of done. Are you gonna do acceptance criteria for each of your functional requirements? Are you gonna try technical stories? And technical stories are challenges but it does seem to work in simple situations. Another one of the four goals that take the brunt of scaling is your initial architecture modeling, your initial technical strategy formulation. So once again, how much detail are you gonna go into? What types of views are you gonna consider in your architecture models? How are you gonna go about modeling? What delivery strategy are you gonna follow? Are we building something from scratch? Are we extending an existing system? Are we gonna go out and buy a commercial off the shelf system? All these various options. During construction, one of the things we wanna do is produce a potentially consumable solution. This is an advance over producing potentially shivable software. We're not just building software. We're building real solutions. Our software runs on hardware. We're changing the, we have supported documentation. We might be changing the business process. We might be changing the organization structure and the usage of our solutions. This is really a solution we're producing, not just software. And there's more to it than being shippable. I don't wanna ship crap. And it's possible to ship crap. People do it all the time. Just go buy, go take a look at some apps from, anyway it doesn't matter. And so anyway, there's a wide range of quality of software that's being shipped or quality of solutions being shipped. And so if you wanna be successful, what you ship has got to be consumable. It's gotta be something that people want to buy that they want to use and they're happy to use. So we need to offer a game on usability and stuff like this. So the way that you develop your solutions really is also, needs to be tailored based on some of these scaling factors, particularly the complexity. If you're facing great technical complexity or great domain complexity, it will certainly motivate different choices in this goal. I should have also pointed out, these lists of techniques are not complete. So people are developing new strategies every day, but as I think you can see, it's a far greater list of techniques than you've seen in other methods. And the reason why is we're taking a look at a bigger scope, we're taking a look at the full delivery life cycle, we're taking a look at end-to-end for your technical techniques and management techniques and architecture and modeling and documentation and testing and quality and all that sort of stuff. And it adds up as I think you can see. And I'm not saying you're gonna be doing all of this stuff, you're gonna be doing a subset of these techniques, but it's good to know. Oh, I should have also pointed out, the techniques in bold, the options in bold, they're good defaults, the default options. And so if you don't wanna spend a lot of time tailoring your process or thinking about it, then you might just wanna start out with the defects, the defaults, and then tailor from there. And then the fourth process goal that takes the brunt of scaling is coordinate activities. This is one of the ongoing goals. And it's interesting, in Scrum, we talk about having a daily stand-up meeting and that's obviously one way that we can coordinate, but that's a technique for coordinating within a team. Sometimes we need to coordinate across the sub-teams of a program. Sometimes we need to coordinate with other groups in our IT department. Sometimes we, all the time, I would hope, we need to be coordinating our release schedule. Most teams work in organizations where there's multiple development teams under their way. So the way that you release in a production will vary. You might have to be looking, you might have to sign up to a release window or onto a release train. So, and if somebody else, if some other team slips their release, that might mean you slip or that might mean you get pushed forward, who knows? So you're affected by other teams. You need to coordinate this release schedule stuck with your operations people or your release people and make sure that you know what release window you're actually aiming for. So anyways, there's, oh, and there's different ways we can coordinate between locations, like flying people around with ambassadors, by gathering the team at critical times and so on. So the point is, is that, so these goals, you will tailor your process based on the scaling factors that you face. So a geographically distributed team will tailor their approach differently than a team that's co-located. A team of 50 people will have a different strategy than a team of five people, then a team of 500 people. A team in a regulatory environment will work differently than a team in a non-regulatory environment. A team facing great technical complexity will work differently than a team that's not facing technical complexity and so on. And having said all that, there's some scaling practices that may or may not be new to you. So having, doing some initial modeling at the beginning of the project, defining the API either through a documentation or test suite to major components early in the life cycle. Doing continuous documentation, doing development and intelligence or project dashboards, taking a continuous architecture approach to your, in your life cycle, doing continuous deployment and continuous integration. Having active stakeholder participation throughout the project. Using work item pools instead of work item lists or product backlogs, focusing on consumable solutions as opposed to just potentially shivable software. Having a release train, having parallel independent testing in some regulatory environments, you have to have an independent test team. That doesn't mean that all of the testing occurs in that team, but some of it has to. If you want to avoid fines or even potentially stay out of jail. So this is absolutely critical to you. When in programs, actual programs you'll often have an independent test team. In environments where you face significant technical or domain complexity, it'll often make sense to have an independent test team doing some forms of testing. So at scale, you'll adopt practices that make sense at scale that would be overkill in a small co-located team doing something fairly straightforward. So different teams, different situations, they're gonna work in different ways. So just to wrap up here, one of the reasons why we developed Disponential Delivery is to really is to provide a foundation for scaling agile. This is a ground roots type of a strategy. It's not a top down strategy as we see in other methodologies such as SAFE for example. And there's some very good ideas at SAFE that I would suggest you honestly take a look at and adopt where appropriate. But anyways, so dad provides some of the mortar for these bricks, provides the advice for how to fit these things together effectively, how to take individual ideas and techniques from each of these other methodologies and apply them effectively, combine them and use them to the right extent at the right points in time. And then once you get good at doing agile delivery and once you're in reasonably straightforward situations, then you're in a position to start addressing some of these scaling factors like having a geographic distributed team, having a larger team, having multiple companies involved, maybe you're outsourcing some of the work. Having regulatory compliance issues to deal with having significant domain complexity, having significant technical complexity, maybe you're doing systems engineering work, not just software work. So the point is that dad, I think, is a true framework. It gives you choices, it leads you through these choices. It doesn't prescribe a single way of working because I think inherently we know that different teams are in different situations. So we need to find, you know, adopt processes and tailor our strategies to reflect these situations. And we need some help doing it, we need some guidance. And dad, you know, the dad framework is all about providing that guidance, helping you to figure out what process, what techniques to adopt and how to tailor them. And so that way you can get on with a real job of developing good value for your stakeholders. So anyways, I think it's time to, let's go to questions. I will stop my screen share and you can see my, what I look like. So I apologize right now if you don't find me attractive. So I should stop, have I stopped screen sharing? Yes, I see you. And it's okay if you're not attractive. Okay, that's good. Cool. Okay, so do we have any questions? I cannot see them, so. I see a few questions that were asked and we'll go into that. I did want to quickly summarize what, at least I heard from you over the last 40 minutes and I want to kind of do a quick recap and then turn it over to the questions. So one thing that really came out and I think you re-emphasized a few times was the emphasis on kind of a non-prescriptive decision-making framework which kind of guides people who are new to it or who are kind of trying to evolve but not necessarily dictate how things should be done because that kind of feels hypocritic in some sense if you will with the whole agile mindset. So it's good to see that your efforts on dad is basically trying to take proven strategies and provide guidance framework around that. So teams kind of organizations and teams going into agile and beyond can basically choose what works for them at the given situation and then evolve over a period of time to choose another delivery lifecycle or another method, whatever is appropriate. So that's really interesting and thanks for that. Thank you. So we have a few questions. I would like to start with one quickly here. So this is a question from my end. I was listening to you and one of the things that came up in my mind is that and I try to summarize that as well is that you talked about the kind of prescriptive nature of some of the agile methods that is out there. And there's also, I've heard from other people that talk about the learning models of the Shuhari and they talk about at the shoe level when you're new to something, then you need clear instructions, you need explicit rules saying what you're supposed to do. So what is your take? I mean, it feels like if I'm at a shoe level, I need exactly prescriptive steps. But I hear you saying that that might not be necessary. Is that true? So yeah, so we ran that sort of an issue fairly early actually and this is why we have the defaults. So if you remember in the goals diagrams, there was like the highlighted option. So our advice there is that either if you're new to this or if you just don't want to make this, you don't want to have choices because some people don't want to have choices. They just want to be told what to do regardless of their level of expertise that these defaults are good starting points. And then once you get comfortable with them, then you can start tweaking. Maybe through your retrospectives, you'll realize oh well, our current approach to requirements isn't so good. What are our options? So let's go look at the goal diagrams. So that's the basic idea there. And then based on what choices seem interesting, then you can actually do a little bit more reading and figure out here's your advantages and disadvantages. Okay, this option's the way to go. Another, an interesting thing that we do in, and it might not have been totally apparent, but we give, sometimes we give not so good options. So for example, watch I talked with this in when you're addressing, when you're doing initial scoping, one of the levels of detail that we suggest is you might want to consider doing a detailed requirements specification. Now that is generally a bad idea. And but the problem is as many teams are still in this position where they're being handed big detailed requirements documents and they get into these religious battles with people, oh this is evil, you know, I heard this is evil, this must be evil, and they can't really justify why. And what happens, so what I want to do, so what we did in that is we made these decisions explicit. We said hey, you want a requirements document up front? Great, good for you. Here's the advantages, oh not that many, and here's the disadvantages. Oh look, huge list of disadvantages that you might not have been aware of. And then here's when you might actually want to do, here's the situations where you might want to be able to do a big requirements document up front, oh not very often. So we make it really clear. So then if you want to make a bad decision, you're welcome to make a bad decision, but at least you go in eyes wide open. So and that I think is, and what I found is that people, I've been on teams where we've used that, that sort of advice to make it clear to the organization and hey you know, we used to think this was a good idea, it really isn't and here's how it's been a fact is, let's not do that and by the way, maybe a lightweight specification's the way to go. And I think there's this common problem right now in the answer community called water scrum fall or scrummy fall or there's a bunch of different terms for it and it's basically big heavy requirements up front, scrum in the middle, big heavy release process in the back end. And I think the reason why this happens is because we really have sort of ignored the front end of the back end to begin with and we've got a lot of people that really can't explain first of all how to do it effectively in a lightweight manner and why some of these heavier weight techniques really are sort of painful. And so I think hopefully dad's gonna help deal with some of that and just as an aside, the person who came up with the term water scrum fall to begin with, Dave West, I'm actually wrote the foreword for the book. So, you know, weird, you know, weird aside. Yeah, Dave's a great, you can talk to Dave West and really good guy. Yeah, really good guy. Yes. So we have another question. This is from Pramod, one of your books co-author. Pramod and you wrote the refactoring databases book. So Pramod has this question saying, would it be safe to say that use that framework only in an enterprise setting because it feels like it's more targeted enterprise but not startups, is that a fair assessment? Yeah, it's definitely targeted enterprises. We have been, but having said that, we have been using it in a couple of startups and this is one of the reasons it motivated us to add an evolutionary version of life cycle like a lean startup type of a life cycle. But we were also seeing lean startup type stuff being enterprises as well, so we're doubly motivated I guess. But yeah, it really is, the challenge with startups is that, you know, they're small, they often, you know, they're just scrambling to get something done and they're not even thinking about process. They're not yet at least. So, although having said that, if you read the lean startup book, Eric Greese takes a similar approach. He adopts ideas from all over the place. He talks about XP and, you know, I think he talks about adopting some ideas from scrum as well but, you know, he talks about picking techniques up from a wide variety of sources and sort of combining them into lean startup. Some of the ideas were even in the unified process by the way, you know, if you wanna really, I don't think he might, I don't think he mentioned that but, you know, pivoting and things like that. But, you know, be that as a man. So the, yeah, so, you know, long story short is that, yeah, it is mostly geared for enterprises but we have seen it applied outside of the enterprise space too. Cool, cool. We have another question here from Lakshmi Kanth and he's asking, when do you make a go or no go decision on a project in the DAD framework? Is there an explicit step highlighted or is it a continuous thing? Yeah, yeah, it's in several spots. They're early in the project, there's a stakeholder vision milestone where, you know, at the end of inception we basically, you know, you don't move forward unless you come to an agreement as to what you're doing. That can be a no go point. Then there's a project vibe, you know, for longer running teams, you know, so, you know, if you've got a project that's running, you know, six months, nine months, then you might want to be doing, you know, every couple months to a viability assessment. Now in Scrum, they build this right into the end of a sprint, so in theory at the end of a sprint you should be asking, making a go or no go decision. It doesn't seem to happen because they're, you know, the success rate of Scrum projects isn't that much better than say, you know, iterative projects. So, and I think the reason why is that the people that are supposedly making these no go decisions are politically bought into the project. They're the stakeholders that are actively involved and so asking them every two weeks you want to continue on, yes, there's always yes. Even if the team's in trouble, yeah, yeah, I'll keep going on, you know, I love the team, you guys are great, you'll pull out. And they don't make the no go decision. So, having observed this, we explicitly advise, hey, you know what, you might want to bring a couple other people in from the outside to help you through this because they'll be a little more honest about it. So, that's why those project viability or product viability milestones are there, and they're shown as optional, but they're for not only good ideas. Although we also talk about at the end of every iteration or sprint, you should make what we call a go forward decision. And what that is, is that you're making, you've got multiple choices, right? Do we continue on? Do we cancel? Do we pivot? Do we just give up? Who knows? So there's different options there, and it's not just a go and no go decision, it's not a binary decision. So, it's a little more sophisticated than what you see in other methods. Cool, cool. I should also say too, let me finish up there. So, a couple of years ago I ran a survey where I asked, one of the questions I asked is whether or not it's acceptable in your organization to cancel a project. So, if a project's in trouble, well, is it acceptable to cancel it? And I think the answer is that only about 40% respondents said that it was acceptable to cancel a troubled project. And that makes 60% of organizations, they would continue on with it until it's blatantly obvious that it's in serious trouble, and they would cancel it. So, the example would be, if you spend a million and a half dollars on a project, it's politically unviable to cancel it, but when you have a $20 million filling in your hands, that's okay, because obviously, nobody could have possibly succeeded at that. So, you just keep spending money until it's so huge that it's now politically acceptable to kill it. So it's a very strange behavior. And I don't know what's like in all of your organizations, but it's something that you might want to have a conversation about at some point, because it's a healthy thing to kill off a troubled project. Cool, cool. Actually, you kind of quickly touched upon one of my next questions is that you've been running these different agile surveys for a while, very informative surveys, and I think you publish all the results again back to the community free of cost, trying to really up the game in some sense. What was your motivation? So first question is, what was your motivation behind the surveys and did the results from the survey add a data point into that framework? Yeah, so the motivation of the surveys is just to find out what's going on out there, because I'm active on the blog, I'm active on the discussion forums and Twitter and stuff like that, and at conferences, and I just hear these weird claims that it's just, you know, I don't know what your environments are like, but there's no freaking way that would work in most organizations I'm in, and so you hear all these weird claims and they say, okay, fine, so let's go to the community and find out privately what they're actually doing, and very often what people are claiming in public has no basis in fact, so TDD is a perfect example, I love TDD, I think it's great, but I think it has an adoption rate of like 35, 40%. Everybody's talking about it, but very few people are actually doing it, or nowhere near as many people are doing it as seems to be talking about it, and that's sort of an interesting data point. You know, these data points like, you know, the average agile team spends about a month doing inception, about a month doing transition, those are interesting data points, and because you don't hear a lot of talk about that, you hear a lot of denial, there's still arguments going on, I'm sure in some discussion forum right now, somebody's arguing about, you know, is there really a sprint zero? Oh, give me a break. You know, 97% of agile teams use some upfront work. 97%, we can't possibly have a discussion about that, give me a break, and for a group of people that can't shut up about empiricism, and yet 97% of teams are doing it and we're still arguing about whether or not it's happening, give me a break. So this is why I run these surveys, I wanna bring some reality to the conversation. Or all these wild claims that we have, you know, I can't remember what the, you know, that somebody made a claim that you know, agile is three times more successful than traditional, give me a break. The traditional project teams have like a 60, 60 some odd percent success rate, which isn't great obviously, but 60%. So agile has three times success rate of traditional, so it has 180% success rate in these people's minds. How could this be? How could this be? So we just, all these ridiculous claims are thrown out there, both from traditionalists and evangelists and other people, right? So let's just bring some reality to the conversation. So I'm a firm believer in empiricism and people work in a empirical way, make observations and running surveys is one way to make an observation across a wide group of people. So that's what I do. So yeah, and some of that, we share data like that all through the book and on blogs and stuff like that. So I've actually just recently published the 2013 IT project success rates just a couple weeks ago. And interestingly enough, this is the first year where Lean came out on top. So my data that now shows that Lean seems slightly better than agile. So that should get a few people spun up. All right, cool. And did this influence the data framework, the way you went about coming up with the data framework, your surveys? Yeah, so the data framework was mostly about empirical observation of what we're seeing working and not working so well. But we also, while we were writing the book and then after that, we were running the issues going, we don't really have any decent data on this. So that would motivate either a full survey or a couple of questions on a survey. Because yeah, we want to find out what the heck is going on because it's not always quite the rosy picture that people paint. Yep. So we have, I think, another five, four minutes left and we'll try and quickly cover two more questions that are out here. One is, does that framework kind of help getting budget ready for an agile project in terms of knowing what the cost would be for the project? And would you recommend a time and material kind of a model in that? That's a question from Balaji. Yeah, so we give several options for, like everything, right? So we give several options for doing estimation early in the project for different ways to fund a project. So some of the funding techniques are doing the price, doing stage gate funding, doing time and materials, a low time materials with bonuses, performance bonuses, just having a funding pool where you just take whatever money you need. And all those techniques have options, have advantages and disadvantages. It's interesting, and you're once again to get data on this, a lot of teams are still in this fixed priced world which is actually a very risky way of working. It's, doing a fixed priced project is more like gambling than it is trying to do any sort of management or governance. And it's interesting that the more flexible the funding technique, the time materials or time material with bonuses requires better, more sophisticated governance than fixed price. And it's actually less risky than fixed price, but fixed price is perceived by many to be the least risky way of doing things and it's actually the most risky way of doing things. And if you actually wanna have some interesting reads, do an internet search on my name and fixed price unethical. I've gathered evidence that points to the, it's basically somewhere in the range of between incompetent and unethical to do fixed price IT projects. But it depends on my mood of what term I'll use there but it's not, it's never pleasant. It's just a phenomenally bad idea. But anyway, so yeah, I would lean more towards time materials. Cool, all right. We didn't prescribe anything in debt, right? It's just, you know, there's trade offs. Do the thing for your rate technique for situation. Right, and you highlight those trade offs and kind of help people guide through those things. Some of those people might not even be aware of so you kind of put forth all the different perspectives that you've connected over the years and guide people through it. Yeah, definitely. Cool, we have one more question here from Ravi. He says, how does that address aspect of business agility and team agility? Oftentimes, we see business agility and IT goals are different with different stakeholders. What process and practices enable effective participation of business and IT with their own respective goals to work together? Yeah, so that's a great question. So we go after that in several respects. So first, we don't talk about the customer in debt. We think that's, I think, a fundamental mistake in the angel community. We talk about stakeholders. And so there's a wide range of stakeholders. The IT stakeholders, there's the business folks, there's operations folks, there's regulatory people, there's finance people, huge range. So if you take, so first of all, we recognize you've got a huge range of stakeholders and they've got different priorities and all this sort of stuff. The second thing is recognize that if you have product owners, then they can be at risk. Well, there's some very good advantages to product owners and some real challenges with product owners. It's a brutal rule to fill. And they have huge responsibilities because they have to understand all, know who these stakeholders are, understand their needs, prioritize, negotiate, and many more things. So it's a really, really tough role. The challenge with that is that, and that's one way of doing things. So, and because it's such a brutal rule, you'll start finding that the product owner has other people they're working with, like business analysts or system analysts, to help them to understand all this sort of stuff. Discipline Agile teams will, might choose to adopt practices like active stakeholder participation from Agile modeling where you bring the stakeholders into the team and you work with them directly. You adopt inclusive modeling techniques and collaboration techniques such as whiteboards and paper and sticky notes and all kinds of stuff that enable them to be actively involved. You use simpler tools that they can actually pick up maybe even let them do some coding. Stakeholders can be actively involved in coding. I've seen business people do phenomenally sophisticated spreadsheets and then do reasonably decent web pages and stuff like that. So it is possible for them to develop or at least be involved in prototyping. So be open-minded to that. So get the developers actively working with the stakeholders as part of your overall communication. So there's multiple techniques that can enable the team and the business people or the stakeholders to be working together effectively. But a lot of it, a lot of the big challenge is also finding stakeholders with the time. So you might have to educate your stakeholders and we'll talk about that a bit where many stakeholders don't realize that the advantages of being actively involved with the team and to help guide the team. And if you're in a situation where your team can't get access to your stakeholders at least not easily, for whatever reason, then you've got a very serious problem here. And it seems I want to use personas and other techniques to simulate the missing stakeholders, but then it's a bit dangerous, but better than nothing. All right, cool. I'll take one last question, which is more like a final question, and then we'll wrap up. So what is the thing, the one thing that you hate the most about Scram? Oh, all the marketing rhetoric, it's just, you know, or well, maybe the certification, you know, all that nonsense, you know, you know, people go to a two-day course and they come on their certified master. You know, Starbucks baristas get three days of training. So the guy that pours your coffee is better trained than the person who's leading your project team. You know, there's something wrong there. I'm sorry, there's just something wrong in that scenario. And it's weird, like I almost stopped asking people what their role is on an agile project. I'll get like, you know, other people that say they're currently on an agile project, 80% of them say they're Scrum Masters because that's the only training they got. So you've got a team full of Scrum Masters apparently. Like, what's that, right? You need one, maybe you need one Scrum Master. You certainly don't need a team of them. And so, you know, it's just, it's a messed up environment. It's a really, really shame that it's a shame that the unmitigrated greed of a few people have really sort of messed that community up. But, oh well, it's, you know. So you're saying the level is the certified, bad certifications ever? No, we do, but you have to earn them. So, you know, it's, you know, we have three levels, the novice level. You've got to do more work to become a novice person in our world than become a certified master in the Scrum World. To become a mid-level person, you've got to do, you've got to show some experience, you've got to do some work, and to become, you know, become an expert level. Then you've got to, you know, show real successes over a long period of time, giving back to the community. You've got to do work to earn it. I was, earlier today, I was working with a group of people from Encosi, and the Encosi certifications, the beginner level is a couple years of experience, let alone the mid-level is like 10 or 15 years, and to be a senior level person in the Encosi certification, you've got like 25 years of solid experience. It's, you know, so maybe they've gone to the other extreme, but it's healthy to see that, you know, in the systems engineering world, at least they take certification seriously, whereas in the agile world, you know, you stay awake for a two-day course, and you're a master, you know. Wow, good for you. There's always this debate about knowledge as a skill, right? I mean, so I can get the knowledge, but I don't know how to apply that, and I don't have the skills necessary to, you know, do that, and how do you judge the skills of people? Well, yeah, you know, two days of training is two days of training, right, and it is what it is, but actually, there's a really good book by Johanna Rothman about how to hire people and, you know, bring people into your team, and it is various techniques for, you know, testing people out by, you know, getting them to do some real work, and stuff like that, so, yeah, it's, yeah, and, you know, I don't know, the certifications are what they are, I guess. Cool. All right, I think we have overshot our time by five minutes, but it was wonderful talking to you, Scott, and I think it was, your session on that was very informative. I'm sure all the participants who joined in have got some insights and some food for thought to take back to work, so really appreciate your time and look forward to having you in India, maybe the next year. Definitely, I would love to, it's all matter of timing for me. Yeah, all right, you have a great one, take care, thank you again. Absolutely, great, thank you very much.