Agile in Government: Go for Insight, Not Just Oversight

hello and welcome to today's sei webcast agile and government go for insight not just oversight my name is shane mcgraw the outreach team lead here at the sei and i'd like to thank you for attending we want to make this discussion as interactive as possible we will address questions throughout today's talk you can submit those questions in the youtube chat area we will get to as many as we can our featured speaker today is suze miller suez is a principal researcher here at the sei working in the continuous deployment of capability directory her current research is focused on synthesizing effective technology transition and management practices from research and industry into effective techniques for use in the governance of programs adopting or contemplating adult adoption of agile or lean methods now i'd like to turn it over to suze miller good afternoon sue's all yours thanks shane i want to welcome everyone as you can see um i am working from home like many of you and so i want to thank all of the people that make this kind of a of a webcast possible when we're in this kind of situation it's a little different than doing it in the studio as a couple of things about today's talk uh one is this is not going to be an agile basics tutorial i'm assuming that the people that are listening have a basic understanding of agile principles and lean principles and we're going to be talking about things from the viewpoint of the government program office so we're talking about things when there is a contractor involved and actually doing the development so think about this as agile in the acquisition context more than agile in the development context so with that a set of assumptions i'm going to go ahead and move forward and what we're going to talk about today is a little bit of a manifesto if you're familiar with software uh manifesto for agile this is the manifesto idea for agile acquisition um this is notional this is not you know a uh anything that's published you know anywhere in particular but it's it's the synthesis of ideas from the seis uh more than 10 years of work in this area of what are things to pay attention to when you're in a program office and you're looking to move from oversight to insight we're also going to talk a little bit about what are some traditional things that we think about differently when we're going for insight not just oversight uh bottom line up front uh you guys can read most of this but the idea is i'm not saying we're getting rid of oversight i'm not allowed to say that and i would never say that we have things we have to do to meet the regulatory and statutory requirements of a program however we need more than those oversight mechanisms if we're going to get insight things that are part of our normal acquisition like contract data requirement list items required events like pdrs and cdrs they're not always the best way to achieve insight on an ongoing basis and agile development settings promote transparency at a much lower level than what many of us are accustomed to working in and if you are able to achieve that there are some built-in mechanisms for achieving ongoing insight but they require proactive participation from the acquirer to be effective and so that's one of the big messages is that this is a change not just for your contractor but also for the program office and the other government stakeholders so these are closely coupled concepts right that like just like verification and validation you don't really generally do one without the other we are talking about that same idea that we are looking at things that you have to do on a continual basis but their goal is slightly differently different the oversight goal is to make sure that we are giving evidence of the process that's executing is correct that it's appropriate things like that and making sure that the capability requirements are managed and that they are feasible and thing and those sorts of ideas traditional project management when we're looking for insight we are looking for some of the same things but we are looking for some other things as well so we're looking for correct understanding for example of the requirements for the environment so it's not just the requirements as stated but looking ah more in a validation sense of what is changing in the in the in the environment that makes these requirements still be the right ones we are looking very much for providing adequate user participation to support early validation activities this is a big hallmark of agile is that we have much more involvement of the end user community and other stakeholders early a lot of our back end processes we actually try to do what we call shift left to get them more involved early so that we can prevent work rework later on we're looking we still need the evidence for oversight so we still need that but we also need to periodically review the processes and work and make sure that they can evolve one of the things that we know about processes as well as products is that the world changes the requirements change and we have to be ready for that fundamentally we are also looking at managing relationships communication and interoperability within the project and with and with other projects so the program office is taking a much more robust role in managing all of the interfaces of the people that are involved in the whole program so this is a little different than what we might have done before and you know how much you think you need insight determines a little bit on your world view and and these are extremes you know i'm i'm i'm not gonna say that that you know these are here uh quite frankly to be a little bit provocative um but the idea is that if you're looking for something for things that are related to compliance then you assume things like change is an exception you're trying to hold the the contractor accountable for everything and tends to be an adversarial prove to me that you did what i wanted is kind of the the phrase that you would look for when you're looking for collaboration on the other hand you recognize that compliance really hasn't worked very well in many of our complex settings we're looking to be cooperative collaborative try and understand each other's perspectives and get the best result and fundamentally we assume that change is constant we know that if the ground is continually shifting then compliance is not really what we want to be going for we want to go for understanding and and that's a shift that happens when we start thinking about things from an insight viewpoint versus an oversight viewpoint and so that's the first place i want to stop for a second and ask if there are any questions or comments we want to address in the chat is anything for me shane no specific questions but we got a worldwide audience we've got a number of people that know you personally are giving their hellos to you so if you want to hello everybody all right i will look at the chat afterwards in in total but while i'm speaking i'm asking shane to kind of manage that so that i don't get distracted so i hope you will uh i'll be able to tolerate that all right so i'm going to move back on then back some principles i am going to sort of remind you of the agile and lean principles and the agile the manifesto for agile software development is something that we want to move towards these ideas how do these ideas apply to soft the system acquisition and [Music] you know these are you know the and remember the balance of these is what change is not we're not eliminating what's on the right-hand side we're just saying choose the left-hand side when you can those are going to get you better outcomes especially for your small teams so what happens when we move to system acquisition so what we've looked at in synthesizing from our research from these last 10 years are what are the things that are making a huge difference in the success of the of the programs that we're working with and they come down to four areas batch size feedback approach requirements expression and management and this compliance versus insight mindset and so just to contrast the same way that sort of the software manifesto does what's different from agile and traditional in each of these topics so in traditional we tend to have few large batch interactions we have large documents that get delivered we have large uh you know week-long review cycles for technical reviews uh we do things in very large batches but there aren't that many of them which means there's fewer opportunities for feedback what we're going for in agile is many small batch interactions this immediately changes the staffing profile of a program office if i am going to be interacting once a month or once every two weeks versus maybe once every six months with my contracting organization second area is feedback approach especially early in the program for system acquisition we're primarily looking traditionally at documentation reviews what does this uh architecture document look like what did these requirements documents tell me and again they are large batch so this is this is a slog when you're in a program office and you're trying to understand everything that's going on when we move to agile we are looking not just for those and this again we have you know some of this we have to do some of but we're doing demos and user feedback as a much more prominent method of getting feedback and and understanding what is actually happening we still have to do documentation review that's actually part of our required oversight but that's not necessarily where we're looking for the insight we're looking for things that are more related to implementation even early on in terms of requirements expression and management in traditional i say single and i know that there are updates that come along with large requirements documents but the idea is we are going for one single finished requirements document to guide the entire implementation and here we're not looking at that model at all we're looking at this idea of a backlog with a prioritized list of items that were our various expressions of our requirements but we're doing this continuously we are looking at the backlog on a continuous basis to understand what needs to change because of what we've learned what needs to change because the threat environment has changed what needs to change because the technology environment has changed if you look at some of the requirements that programs are dealing with right now there are some software programs that really weren't considering how do we deal with people that are trying to access this data remotely that's something that changed in march and it's probably nothing that was ever in any of their requirements document but the world changed and we need to have a way of understanding what that change means and this continuous backlog refinement is a strategy for that and then down at the bottom that what's your mindset are we seeking insight or are we seeking compliance we have to achieve we have to achieve compliance especially when we start thinking about things like certification but if we don't go beyond that then we are going to get caught off guard in some of these other areas that we're not going to be ready for so we're going to take each one of these and look at them in a little bit more detail as to what they might mean when you're moving into an agile space and i am going to concentrate even though i've got kind of a two-column approach here i'm mostly going to concentrate on the agile side as we go through these after we go through remember remind you of the principles so um these are the principles that go along with this and the main reason i pop these up is to remind us that these are small team focused and most of our many of the programs that we work with are not small teams and that is actually different is that we're not looking in this idea of a manifesto we're not looking at specifically small teams we're looking at much larger programs the other thing i want to bring up is my you know shorthand for how do you scale agile to a large system acquisition is you don't you you do agile at the small team level but you use lean principles from lean engineering and lean product development to actually deal with some of the system level things that are much larger in scope than what you can deal with on a small team these are the safely and agile principles that many people are using today um to talk about their uh their you know how they're going to go about their system acquisition and system development and prime more than acquisition and uh don't forget these i'm not going to go through these today but um you know these are important to kind of keep in your head when you're trying to deal with the system level so the real question is how can we gain insight into contractor expression of the agilent lean principles so the principles that i just put up even if you're not doing them because you're not developing they are what should be guiding your contractors the agile principles should be guiding their small teams and the lean principles should be guiding their larger teams so how do we do that and i will also say as a caveat this is a short presentation so we're really just going to hit the tip of the iceberg on these concepts today before we move into sort of the comparisons side by side i want to stop again see if there's any other questions that uh have come up we do have some questions roland and susan we got a good one from larry asking can you discuss the importance of pmo and developer co-location on the insights uh very interesting question as we are all working from home and none of us are co-located um so in a traditional setting a traditional in a pre-coveted setting i'll put it that way um where you can have pmo and uh developer co-location you get what is the opportunity for what aleister coburn calls osmotic communication where you hear things as you're walking down the hall that help you to understand what's going on or something that needs to be dealt with you you get a much richer context of communication when you can have that co-location what we have learned since covid hit is if you can't have that you have to find other ways of getting that cocktail ear that osmotic communication it is harder and you have to work harder at both informal and formal communications and you have to typically up your technology game game um one of the things that we're seeing is uh zoom for government as an example that was something that probably really would have been slow rolled if we hadn't had this kind of a crisis where people cannot be co-located but it's always beneficial if you can have that co-location but if you can't you still have to go for high bandwidth communication both informal as well as formal any others uh one more from elsa we have more but we can just squeeze one more in this section i identified a bit of chaos when there are several proj several squads and big data projects touching various areas people more areas the greater chaos and consequently delays and budget affection what do you recommend in these cases um so i'm gonna recommend a book that i'm just finishing reading um that that what we're addressing here is what you're addressing here is some leadership issues as well as some team dynamics issues there's a book uh called extreme ownership that came out a couple of years ago that actually deals with how do you deal with the um communications paths among people touching different things so this is not a book about architecture it's more about the dynamics of that the other thing i will say is that when you have lots of people touching the same product from a product viewpoint i want to have an understanding of what the guard rails are on the governance of that so from the viewpoint of who's allowed to touch it for what purpose that's something that the stakeholders that are involved all need to understand and uh promote and and advocate for and comply with if you don't want to have chaos it is something that requires quite a bit of discipline to be very honest all right so we move on from here all right so uh when we go from large to small batch what are some of the typical small batch behaviors that we're seeing that are different we look for even small pieces being implemented because we are looking to learn from them the the shift the reason that we go for early implementation is knowledge gathering and understanding what it is we don't know yet and so that is a big piece that helps us when we go into small batches we also start really mindfully using this idea of stop starting start finishing um that is if you've done kanban or other techniques like that um you know finish something so that you actually understand it and have the knowledge about it rather than having so many things in process that you actually don't know when you're going to get done which goes on to the sec next thing which is you want to limit work in progress to enhance the flow through the system this is a whole whole lecture on itself but trust me you do want to do that um this is a provocative thing for many people that 100 utilization of resources is recognized as limiting flow flexibility and work accomplishment what you say how can that possibly be um it's a true statement if my calendar is completely full from monday to friday and something happens that needs my attention in between then i have no room for it if i leave slack in my calendar for there to be some times what that are not scheduled i actually can take care of more things i don't disrupt the flow of the things i've committed takes discipline to do that small batches are one of the ways that you accomplish that but you have to acknowledge that you're not going for 100 utilization of resources one of the big benefits of small batch behavior is that you have a short time between when a defect is found and when it was created assuming that you're going all the way through an integration and test cycle for the small batch this makes it much easier to find the defect and move on and correct it so it doesn't affect other parts of the system you have to have lots of integration happening if you have lots of small batches that is work but it also is something that really builds confidence in the system's evolution so we have this tendency from all of this to build quality in because we can build it in in small batches okay and i'll let you read the other side um when we move to primarily demos and other mechanisms like demos for user feedback besides document review first thing i want to say right off the bat is demo does not equal test but demo does inform test the thing the feedback we get from testers that have adopted shifting left into participating in demos is they learn more about the system so they can actually create better test cases and they start to understand where testing is very robust in the development side where it isn't so they can fill in the gaps where the testing is not already robust active participation and demos is for small pieces of functionality going back to the small batch we are not trying to create these these complex huge war game kind of demos these are much smaller things and so that allows us to have more interaction with people that actually can understand what's going on in the small things we get open and continuous feedback about the fact of and the meaning of progress or if we're not making progress you know what's the meaning of that lack of progress the info from demos is fed forward into testing so this becomes a source of data for our certification and our test staff to say here's things we've already done and here's what it looks like this is something that really needs to use the concept in agile and it it floats up all the way into the system level of a definition of done and that definition of done for every small thing and all the larger things needs to include certification criteria whether it's cyber dtot uh ato's authority to i don't remember atc but it's in there oh authority to go actually certify authority to operate um participation on continuous integration teams by government staff is seen as a high priority so this is something that happens as a result of going in this direction is contractor and government start to understand that we need people that understand the very technical infrastructure details working on the integration teams and that needs to be a transparent part of the process next one is looking at how do we do requirements expression and when we go to continuous backlog refinement we see a mix of push and pull communication across the government contractor interface on this evolving refinement to requirements so you want tools like jira that's that's just one that is used a lot it's not i'm not saying it's the best but whatever facilitated workflow management tools you have they need to be this on the same platform we need to have that ability for push and pull you want frequent face-to-face high bandwidth we just talked about that meetings so that we can keep the relationship going not just do the refinement tasks this is one of the important things about doing continuous backlog refinement is sharing enough about context so that the government understands what are some of the constraints on the contractor's side contractor understands constraints on the government side and we understand how to work through those things together that is also part of transparency that is going to help to build trust and we see these frequent small batch prioritizations give us this solid base of understanding the current state and the progress so this is what we get out of that kind of refinement last one is compliance to insight um some typical insight behaviors don't immediately react negatively to bad news it is information that's meant to help make a decision and typically a different decision than the direction we were going and if you don't want to discourage people from giving you the latest news even if it's bad you you can't be punishing them for it that's just not gonna work um and you want as much informal handoff of information where it's feasible where it's allowed obviously there are places where you can't do that but to the extent you can informal handoffs are one of the ways that you help people to help you have the right information make sure you have the right scope all of those kinds of things and this also allows agile events that are allowed to preserve their cadence if i am continually interrupting my uh three-month planning cadence all right that's more of a compliance behavior i've got some other data call out here i got to deal with so you guys have got to drop everything and do this that's not really going to help you with the with the insight and the trust and the transparency allowing the agile events to preserve their own cadence builds trust that we can rely on this planning cycle and execution cycle and we can get our work done we also see lots of sharing of test and certification assets so as opposed to if you know the criteria oh my god you'll develop to it and i'm going to lose my independence that's an isolationist viewpoint that is a very compliance related viewpoint you start looking at things from the viewpoint if you know the criteria you will develop to it and that's what i want because if i've done a good job of creating my criteria then you developing to that mean it's going to fulfill that criteria and we all want that that's a mindset shift and no you're not going to i'm not going to tell you every single little thing but i am going to try and make it easier for you to actually do your job in the way that i need for us to be able to certify we select carefully the measures and they are visibly used to solve problems not punish and that's an area that's a whole you know workshop unto itself as to how do you achieve that in a particular setting but you just don't take a template of here's all the measures that i could use and just slap them on you're really looking for insight into the things that are going to help me understand what this team is doing and with everything you're really kind of having this collaborative mindset that we're in this together and we need to solve problems together not just you know uh walk along the same path next to each other all right i'm going to stop at this point and see what other questions have come up so we've got lots of great comments which i'm going to stay away from because i know you said i'll look at those afterwards that would be fine later but like just some questions larry had um if you were going to get into any tools um like collaboration tools specifically they use jira and conversations um do you have other suggestions for collaboration and insight there um so good use of wikis and so di2e is used by many people has a it has a wiki it's got jira which is a workflow management tool any tool that gives you the ability to do what i call unmoderated group editing so um you know shane can get into the document at the same time i am we can edit it and it will merge the changes and and and give it to us and present it to everyone who has access to it same thing with jira um there are some newer tools coming out that uh do that uh that are very nice for um uh group meeting settings unfortunately most of them are not fed ramped and so they are not available for use um in typical program settings you know inside the the government firewalls um and you know more important than which tool it is is that across the government contractor interface you're using the same one you know if at all possible you want to be using the same platform and actually the same repository you want everybody to have access in there that is very different than how we've done things in the past in the past developers environment government environment have been very separate we are moving to a much more collaborative transparent and that's really what you want to go after the places where that has been achieved are places that i see more success in achieving this kind of mindset one more or move on let's do one more what about any what about implementation of program risk management going from oversight to insight okay so we again compliance right we have the arm the whole arm process if you're in the air force acquisition risk management process and we have to pay attention to that we cannot let go of that however one of the things that when you're looking at mitigating risk so identifying risks is one side mitigating risks one of the opportunities with agile is to look at your risks from the viewpoint of which of these risks are actually mitigated by me instituting some of these things that i'm talking about in terms of changes in the way that i do batches and the way that i do transparency which of these risks would be ameliorated by having more of an agile mindset and more of a collaborative government contractor approach to things there will be some that would be this is the mitigation and i have seen programs that actually you'll see that in their risk um uh briefings about you know how are we dealing with this risk well we're dealing with it by having more transparency and here's how that's happening um and things like that so that would be my first suggestion um there is a a group of people there's a community out there that says that by doing agile i am you know immediately mitigating risk and uh i understand their viewpoint of why they say that but we have to be a little more specific in our environments about what about agile is it that is mitigating risk well small batches allow me to learn faster and i have a risk of um that we have a technology that we're really not certain about so i need small batches so that i can iterate and understand what i don't know so those are the kinds of things that you would do all right okay so let's go ahead so um this is the beginning of a conversation and i want to take this farther and actually get to a set of principles that help us for acquisition in the same way that they help you go from sort of these high concepts in this sort of manifesto presentation to actually being able to understand more clearly how to implement some of these um but that's you know over time we'll get there but it's something that is gonna take uh quite a bit of work all right the things we still need to think about but differently and this i'll reflect on a couple of questions that uh we've talked about in terms of of how those things uh how they play into some of these things so the things i'm going to talk about very briefly technical reviews requirements systems engineering contracting measures testing and certification these are one-page summaries of you know an hour and a half to two hours and sometimes a whole day's worth of content uh of things that we've learned about implementing these in different program settings and we actually do have 90 minute modules for each of these and we are now offering them as part of what we're calling a virtual school house so i and my colleagues do the kind of thing we're doing today but with a very particular topic like systems engineering and it's closed usually to a single program but we can there are some options for that but what we get is a lot more discussion than we can really facilitate and it's more specific to a particular setting than what we can do in this kind of a webinar so um the link is there and sean will shane will give you more information about that after um after this briefing but i just want you to know there's more than these one pagers that you're going to see now i'm just kind of cutting them down because of time all right technical reviews what's the switch the switch is projective versus as built right um are typical formal high ceremony things like a preliminary design review and critical design review in the past have been very large batch and once they are done the opportunity for learning what we didn't know or what was wrong about what we thought we knew is much reduced and so taking these down to incremental reviews that are on a much shorter cadence very typical is three month cadence if you're familiar with uh doing uh program increments um a la safe that's you know sort of a typical cadence doing the things you would do on a small batch is one of the ways that you mitigate that and you get uh you can use the exit criteria for formal large batch reviews in these small batch events we may still have to do a traditional system requirements review some of these things we may not be able to turn into small batch but um once you can start figuring out my roadmap of things i need to have more knowledge of you start to get an idea of what my small batches should be and programs that have used this especially early on for risk reduction they are doing a very uh you know their early increments are very focused on risk reduction and that's really what you want but they're doing it risk reductions for implementation so that's a big deal requirements all right i've got my little thing there it says if it's in the backlog it might get done if it isn't in the backlog it won't get done um this is the mantra of moving to a backlog mentality this is very daunting if what you think a backlog is is the 3452 requirements that have been you know prioritized all at once at the lowest level of detail that's not what we're talking about we're talking about understanding that fixed intent and variable intent exists together and that idea of fixed intent are the things we know we know about and they tend to be at a higher level of requirements baseline so that we allow the learning to occur below that level we have used roadmaps to guide what needs to be specified in more detail and when things need to be detailed so we're not talking about 3452 we're talking closer to a couple hundred and maybe 50 or 60 of those are really detailed for what we're going to do in the next three months but the others are at a higher level of detail and that allows us to have trade space so that we can reprioritize when the world changes and it also allows us to focus on the highest risk most valued items earlier systems engineering um what happens when large batch systems engineering meets small batch agile software development we get what we call agile at the bottom of the v and i didn't reference it here but we actually do have an agile minute about agile at the bottom of the v and what is it that is a problem with that um and the problem with that is that if you make all the decisions about what we're gonna do before you implement anything then you're gonna be in the position of having to go back and do quite a bit of rework once you figure out that what we thought we knew is not what's real and implementation is when you find that out so systems engineering moving to small batch is a bit of a controversial topic we have seen some instances of this and i will say that one of the things that moves in this direction is people that have taken the digital engineering ideas to heart and are using model-based systems engineering have an easier time with this concept than folks that are still using very requirements-based uh documentation contracting i put up this is from um aleister cobin coburn's crystal clear um and you know what are the properties of successful agile project teams frequent delivery reflective improvement osmotic communication we mentioned personal safety focus sunshine and visibility i love this one no dark places in this in the in the project how do we contract for these kinds of attributes that's really the question and it's not an easy question we when we go to help an organization to rewrite their contracting documents to be more agile i have a list of 13 documents that are typical in our acquisition ecosystem that i look at to try and say are these agile aware or are they going to disable your move towards agile things like your test and evaluation master plan your systems engineering plan your how your dids are written how your technical review criteria are set up i mean some of them are obvious from what i've said already but there's a whole bunch of them that you need to look at for agile awareness and that's because we've got lots of places where we tell people how to do things or we tell people what to do sorry we don't we never tell them how to do things other than to follow this standard or that standard but um what is it that we want them to do we we have a lot of that what do we want you to do that isn't necessarily aware of how things shift when you move to small batch when you use to demo based user feedback when you move to continuous backlog refinements so these are things that that you have to pay attention to um this area is changing more than some of the others i've talked about the diagram i've got up here i've got a reference to dau because this is the adaptive acquisition framework and depending on the size and context of your acquisition you may actually have a lot more flexibility than you had in the past major capability acquisitions that are complex cyber physical systems have still not been adapted in this way yet but uh software intensive systems that are middle tier and defense business systems actually have uh more contracting flexibility than they have had in the past measuring progress um one thing that doesn't change when you start looking at agile is what's the way to think about measurement you still have to think about all of these attributes that you're trying to measure something about technology effectiveness process performance product and size stability resources and cost etc etc etc and the question then is what changes in the way we think about these things when we move to agile so process performance right resource cost schedule quality we still need to do that but what happens when we move to small batch what happens when we move to we're not projecting what's going to happen and not using proxies like documentation to say this is how we're going to measure progress we actually have real software built how does that change how we look at this and this is uh something that is not trivial to think about there are three areas that are a little different that um you want to make sure get included when you are are adapting your measures flow versus utilization i introduced that topic a little bit value how do we ascribe value to what we're doing and understand what is value added and non-value added and then what's our lead time from concept to capability you will hear people in the commercial world talk about concept to cash our life cycle is concept of capability so how do we get that and again this is a whole if you if you haven't seen uh will hayes's webinar on agile measurement you want to take a look at that because that gives you an hour and a half of looking at that whole topic all right and testing um this is a bill that i'm just going to build out boom boom you've got to shift left and you've got to move the whole cycle of certification and testing earlier as soon as i have something to test i want to be testing and integrating it that is a different mindset that is a whole that's a whole day's worth of talking um but integrating the agile cadence with dt and ot certification and certification is definitely a challenge those folks have a very different uh funding model and work planning model and we have to figure out how we are going to interact with that much more to get to what is on the bottom uh the bottom cycle there so those are our um some areas that we want to think about and certification itself um is multi-dimensional uh we have cyber we have air worthiness we have nuclear surety we have health care uh hipaa all kinds of certifications um and so understanding how they can be involved throughout a process this is just a notional you know multi-um layer organization with a large solution agile release train agile team and i've just sort of marked places where a certifier might be thinking about how can they be more engaged we use this to help communicate with the certification community that there are opportunities in this way of working for them to actually do things that are important to them but they have to understand it and they have to be ready to actually do something about that all right so i'll stop here again what else have we got that we can look at i just have okay we have a question from your friend merlin asking glad you recognized that agile doesn't scale well your experience do contractors developers handle the system level aspects while the participating teams use agile um so we have we actually have a technical note on systems engineering that was written in agile that was written a few years back and we identified three patterns one pattern is systems engineers that say y'all do whatever you're going to do but give me what i want when i want it and that basically means give me a detailed requirement spec one you know early and things like that that you might not do in a typical agile setting the second pattern is where systems engineers act as team members on an agile team and they are kind of the liaison between the agile software developers and the system teams and they help them to sort of translate what it is that they need at different points and then the third um option is where systems engineering is actually operating in a lean agile kind of team us pace themselves where they're doing small batch iteration so if you think of the reference i would give to you is the lean machine um is a book about harley davidson's hardware development and how they went to salt small batch lean um and so they there are our settings that do that when we wrote that tn there was only one organization that we identified in pattern number three i can i i'm not i can't name them but i can at least identify two others that i personally see now that are doing this and so it is becoming something that is more real and pattern two where there's a more liaison kind of effect is actually probably the most dominant pattern right now systems engineers are recognizing that um that just leaving agile at the bottom of the v does not serve their needs any more than it does the software integration needs and so they are interacting more positively anything else yeah a question from mel asking for very large systems without a full architecture or some big picture doing agile early can cause the team to go down many blind apps that cost the project budget and time how do you avoid this so this is uh where vision and road mapping really come into play and what so there's the ideal state and the more pragmatic what you're probably going to have to deal with the ideal state is you get people to recognize that are responsible for that architecture that we need a skeleton to be able you know a skeleton that we think is going to be stable to be able to work from so that what we do is not is not going to violate the creation of an evolvable architecture that that's that's an ideal state if i can't have that state where we actually work together on on creating that road map then you're going to want to be very very clear about when you do things in the agile space what are the assumptions you're making and what are the effects if the architecture doesn't look this way so it's more work for the agile team but it's also a way to get attention that you guys want me to go fast you want me to do software fast and that's all great but if i don't have this information i have to make these assumptions and if they're not right that means rework and so you you have to kind of what you're doing is leading upward and and getting them information but helping them to see where there are places that you can't really move forward effectively without getting interaction with that larger architecture the architecture team just real quick before final thoughts um can we get the links some kathy's asking to the the systems engineering options that you were just discussing and then jade chimed in the agile software software development teams and systems engineering teams that she's referring to are those in the slides many chance or that um the references are not in the slides but i'll i'll give them to you after the facts so that they'll be um in the uh the agilent systems engineering actually uh for each of these topics they're accept certification we do have some kind of a technical note or publication so i'll make sure that that shane gets those and i can send those out to everybody okay all right um so final thoughts and maybe a couple more opportunities for questions we'll see so for program offices this can be a really big shift because it means changes in skill profiles i need people i mean we talk about owning the technical baseline but if you're going to be interacting on a two week or one month or three month basis on the technical evolution of the system you gotta have some chops and so you you know you've got to make sure people have the skills on the government side to be able to be effective in making decisions as things are moving forward also changes in staffing curves for the program office i am likely to not have these okay everybody on deck we've got a month to review all these documents for pdr it's more i need you continually involved at a smaller capacity but i still need you there every two weeks or every month and it changes the character of interactions with contractors and stakeholders much more this is what i need how can we make this happen collaboratively then do this now and do this then also the changes in batch size is something that has a lot of implications so if you think about seed drills and the process that goes along with that that's a very formal process and the idea of having things as cathedrals that are agile work products may not be your best idea because that means i'm going to have to go through contractor formal review and government formal acceptance and review you know every every two weeks or every month or every three months thinking about how that change in batch size affects the way that you organize your business is is really something that is is paramount if you're going to move in this direction why do you would you bother um what we're seeing is especially where we need certified products we can get faster delivery to certification and if we've been able to get certification and dtot to shift left with us earlier we get faster delivery of high value solutions to our war fighters and stakeholders and that's really what we're after is to allow our our you know the the speed of relevance you know sort of phrase is the thing that we're trying to get to and we are never going to be netflix who's you know producing i don't know 200 releases a day or whatever ridiculous number it is that's not who we are but every five years is not the right pace either and and you know every two years is not the right pace either in many of our settings so we've got to figure out better ways of doing this and the system acquisition is a big part of that so i'm going to say thank you i will take some more questions um if we have some time and there's my contact information for those of you that don't already know how to find me um so that's that's it what you got for me shane great thank you thank you very much that was a great uh great presentation uh we're called to the questions i'm gonna read a comment from from adam just to see if you have anything to add to it adam stated when we help our clients we often do a gap assessment against the controls of xyz standard group controls under an initiative and into small chunks for iterative improvement yes um so uh you know that gap analysis can take many forms there are uh places where you're really looking at gap analysis with the ecosystem and we do something similar we've got a white paper on agile readiness and fit analysis where we're looking at where are you in terms of different ecosystem elements some of which i've talked about here and then you also do need to look at how can i operate at the team level all the way up through the enterprise and often there's a disconnect in that middle tier from agile to traditional and bridging that when you have you know portfolio managers and people that are managing the higher levels of the enterprise that are staying traditional but they want the benefits of agile concept capability at the lower levels you've got to figure out how to navigate that and i won't say it's easy because it isn't all right shoes we're caught up in the queue there again make sure you check out the chat because there's lots of people you know and again thank you for a terrific presentation um we hope to do a couple more here in the future with you as well um on there for everybody that today's event was archived it will be available once we stop the stream here at the same url so if you found value in today's talk please hit that like button below and share it with colleagues as well um and just a reminder our next webcast will be august 19th the topic will be octal forte with uh brett tucker and matt kovic talking about some risk management there and we'll make sure we email everybody a registration link and if you have any questions from today's event you can always email info sei dot cmu.edu uh sus i'll give it to you for the sign off anything you want to have before we go thank you and i hope that uh you are successful in moving your systems towards a more agile lean method of doing things because it does help once we get going on it but it i won't be the one that says it's easy it's maybe simple in terms of the concepts but it's a lot of work there's humans involved anytime there's humans involved it's work all right so actually you if you don't mind we're not done we got one snuck in the budget here from irma quick question so all right is he's asking so will the u.s services be releasing incremental j o r d george or o r d s's uh so jason's is the organization that um does those kinds of joint requirements and that's one of the focus areas of the adaptive acquisition pathways in terms of a desire to make that a more agile incremental way of doing things but that was not the first element of where they focus change so i would keep up with that adaptive acquisition pathways website and see what you see in terms of uh joint orgs and things like that coming down the pike in a and see how they're doing with that i will say that is a big lift and it's going to take a while probably to see really results in that area terrific thank you very much for squeezing that in folks that's all the time we have for today thanks again for everyone attending and look for an email about the archive soon thank you you

Channel: Software Engineering Institute | Carnegie Mellon University

Views: 1,145

Rating: 5 out of 5

Keywords: Agile, Lean, Software Testing, System Engineering, Government, DoD

Id: LtDmoL1XQe0

Length: 55min 0sec (3300 seconds)

Published: Wed Jul 15 2020