Our Principles

1. Define all Infrastructure as Code

   • Cloud infrastructure must be defined as Infrastructure as Code (IaC)
   • IaC must live in a version-controlled repository
   • IaC should be developed modularly with sensitive configuration data being extracted to variables
   • IaC components must be maintained and updated throughout its effective lifetime

2. All changes to production should be tested in lower level

   • Production changes must be tested in a lower environment. If this is not feasible, changes must have a rollback plan

3. Version Controlled Assets

   • Code, documentation and resulting binary assets must be version-controlled and appropriately signed or tagged to uniquely identify the asset

4. Configuration Data Storage

   • Mutable configuration data must be stored and consumed programmatically using an appropriate software, service or technology

5. Implement Automated Configuration Management

   • Product teams must implement Automated Configuration Management on deployed mutable instances (e.g. packages, daemons, agents, applications)
   • Changes to running mutable instances must be performed through idempotent automation and not human intervention
   • Automated Configuration Management components must be maintained in the version control system
   • Automated Configuration Management must be incorporated into the FISMA System Continuity of Operations Plan

6. Implement DocOps

   • Product teams must implement Automated Configuration Management on deployed mutable instances (e.g. packages, daemons, agents, applications)
   • Changes to running mutable instances must be performed through idempotent automation and not human intervention
   • Automated Configuration Management components must be maintained in the version control system
   • Automated Configuration Management must be incorporated into the FISMA System Continuity of Operations Plan

The Scrum Team Roles and Accountabilities

by Scrum Alliance (Scrum Fundamentals - Article)

Developer Role and Accountabilities

Developer (or team member). The ideal size for a development team is between 3 and 9 people, not including the scrum master and product owner. Any smaller and the team couldn’t accomplish enough each sprint. Any larger and communication becomes complex and cumbersome.

View our Team Profiles page to learn more about the structure and size of our teams

The developers decide how to accomplish the work set forth by the product owner.

Teams of developers are structured and empowered to organize and plan how to accomplish their work at an agreed upon level of quality—the definition of done. Developers work together to accomplish the sprint goal, checking in with each other at least daily to inspect and adapt their plan.

To achieve these aims, developers perform the following activities:

• Manage the sprint backlog.
• Inspect and adapt through a daily scrum.
• Contribute to the sprint goal.

Great teams of developers have the following characteristics:

• Self-organizing. The developers decide how to turn product backlog into Increments of potentially releasable functionality;
• Cross-functional. Together, the developers have all the skills necessary to create a product increment;
• One-team mentality. Scrum assigns no titles to development team members, regardless of the work being performed by the person. There are also no sub-teams among the developers, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis. ​Individual development team members may have specialized skills and areas of focus, but accountability belongs to the development team as a whole.