The SEI helps advance software engineering principles and practices and serves as a national resource in software engineering, computer security, and process improvement. The SEI works closely with defense and government organizations, industry, and academia to continually improve software-intensive systems. Its core purpose is to help organizations improve their software engineering capabilities and develop or acquire the right software, defect free, within budget and on time, every time.
"We talked to a number of program managers. We talked to Agile software team members. The thing that surprised me the most was that all of the feedback that we got about these interactions was about the service side of systems engineering. It wasn't really about the transformation of artifacts. It was about how the teams engage with each other, how they communicate all across the lifecycle of the program. "
"If you have 6 people, you put them in a room, give them access to users, and you are done with the story. If you have 20, you’ve got walls between the people, so you’ve got conversation blocks. If you’ve got 50, you’ve got multiple technologies, multiple teams, and multiple floors…If you have 100 people, you’ve got consistency problems across teams."
"We have seen teams that have devolved into just racing as fast as they can because they don't have the management top cover. We have also seen teams where the management understands that keeping that sustainable pace is part of what keeps the software coming. It is part of what makes their users happy. So, they work really hard to protect the teams in maintaining that pace. "
"One of the challenges we have is to find a good way to answer the needs of the large-scale-program-management focus without violating the kind of space that is created for a self-directed team to use Agile methods and be successful. "
"This is a case where the cultural aspects of Agile are sometimes ahead of where some of the stakeholders are in the acquisition process. This working software principle really brings that to the forefront. "
"We have these meaningless words like staffability. Just as they are meaningless in the software world, we are trying to give them meaning using scenarios. So, we have an exact analog of the architectural side of the house, the software-architecture side, to try and structure the acquisition strategy."
"Historically this has been something that the safety community has known for a long time. If you have safety-critical software or hardware and you test it, then anything you use to generate and test that safety-critical software or hardware is considered safety-critical itself."
"Agile is an evolving learning environment. So, you have the top-level requirements. But, then, as you evolve and learn more about it, different requirements will emerge. And, you need to verify those with the actual operational end user."
"An acquisition archetype describes a situation where an action that's being taken may appear to be sensible and…promising. At the same time, it has unintended, counterproductive effects to what was desired by that action. It might even make things worse than they were in the first place, even though it seemed to make perfect sense."
"Testing by itself just isn't going to get the job done. Testing typically only finds 50 percent of the problems in the code. Since a lot of the problems are introduced during requirements engineering and architecting, it really makes sense to try to both prevent those problems up front and to find the problems then instead of during the typical test cycle when they're much, much more expensive to fix."
"Social dilemmas come in many different forms with different properties, which is partly why they can be hard to fix. That's why we keep seeing them, not just in acquisition but in public policy, economics, sociology, and many other areas."
"One of the key things, if you're going to use Agile methods, is have enough definition up front of what you want to do, but not so much detail that you can't learn, that it can't change, because your environment changed."
"One of the things that we found with DoD and federal clients is that these principles are a little bit new. Some of them feel good—they feel like they fit within the DoD culture—and some of them don't."
"When the project first starts out, initially we're ticking off progress at a pretty regular basis…but what can happen as you start nearing completion—the 70, 80, 90 percent done—is that progress as measured can begin to stall out."
"A TRA is not a documentation review. There's a lot of planning that goes into it, six months to a year's worth of planning out front. You actually get into design details, engineering studies, &test reports. It's really a heavy-duty engineering level review."
"Misaligned incentives usually occur in the absence of well-designed rules that control the rewards or penalties for participants. The underlying idea is that unless the rules incentivize them to do otherwise, people and organizations both tend to act in their own self interest, which may not always be what was wanted."