diff --git a/content/guides/0_a_guide_newtoagile.md b/content/guides/0_a_guide_newtoagile.md deleted file mode 100644 index cc25d130..00000000 --- a/content/guides/0_a_guide_newtoagile.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: 'A Guide: New to Agile?' -category: Agile ---- - -Are you new to Agile? Trying to understand how this approach to project management differs from more traditional methods? Wondering how this will affect projects at the General Services Administration (GSA)? The CTO Team and [TECH.GSA.GOV](https://tech.gsa.gov/) can help! This guide will direct you through the content and resources we offer in regards to [Embracing Agile](/guides/embracing_agile/) and the [Steps You Can Take [Today] to Succeed in Agile Delivery](/guides/steps_to_succeed_in_agile_delivery/). - - -## Understanding Agile - -Agile is not a process, methodology, or a specific tool. **Agile is a mindset.** The [Agile Manifesto](http://agilemanifesto.org/) fully details the [values and principles](http://agilemanifesto.org/) that comprise Agile behavior, which we summarize in [Agile Adoption](/guides/agile_adoption/). It also includes some common terminology, an introduction to the benefits of Agile culture, and behaviors we can adapt to becoming more Agile. - -In [Popular Approaches to Agile Adoption](/guides/popular_approaches/), we highlight the most notable Agile frameworks [Scrum](https://www.scrum.org/) and [Kanban](https://leankit.com/learn/kanban/what-is-kanban/), and discuss their values, common terms, roles, ceremonies, and how teams can get started with each approach. however, agile adoption is not always an easy transition; shifting the mindset of an organization and its people can present many challenges. [agile adoption challenges and best practices](/guides/agile_adoption_challenges_and_best_practices/) features some of the major challenges to Agile adoption and recommends various mitigation techniques. - -Despite the challenges, the benefits of an Agile environment can far outweigh the growing pains, as introduced in Agile Adoption at GSA. [Visibility & Status in an Agile Environment](/guides/visibility_and_status/) further discusses how creating an Agile environment can better support Business and IT [collaboration](/guides/business_and_it_collaboration/), transparency, visibility, communication, and accountability. - - -## Implementing Agile at the Organizational Level - -The success of an Agile implementation begins “at the top” - it requires the full support of executive and managerial leadership. The GSA provides support of Agile adoption through Agile Blanket Purchase Agreement (BPA). As part of the GSA IT vision, we have committed to building a supportive environment for iterative and open-source development. The [U.S. Digital Service Playbook](/guides/digital_services_playbook/) and [18F: Agile Principles and Practices](https://pages.18f.gov/agile/) outline the practices that have been put in place to support Agile and iterative development environment by the Office of the Chief Technology Officer (CTO). - - -### Agile Practices - -Moreover, we understand that continued success throughout an organizational Agile implementation is not only supported by [Applying Agile Practices to Business Teams](/guides/applying_agile_practices/), but also helping organizations find ways to transition [Traditional Management Skills and Functions in an Agile Organization](../traditional-management-skills-and-functions-in-an-agile-organization/) and identify [Measures of Success in an Agile Organization](../measures-agile-success/). Further, while Agile practices are often relegated to projects / processes within information technology, many other industries have developed innovative and strategic agile methods which we detail in [agile human resources (HR)](/guides/applying_agile_practices_hr/), [agile legal](/guides/applying_agile_practices_legal/), and [agile marketing](/guides/applying_agile_practices_marketing/). - - -## Implementing Agile at the Project / Product Level - -Agile adoption at the organizational level creates a transparent, responsive, and flexible environment that is readily able to handle change in the market. However, we recognize that not every *project or product* will benefit from an Agile approach, those that do are typically large and complex in nature. Those that do are typically large and complex in nature as we note in [How to Determine Projects Fit for Agile](/guides/how_to_determine_projects_fit_for_agile/). In [Agile vs. Waterfall - Scope, Schedule and Cost](../agilevs.waterfall_scope_schedule_and_cost/), we explore the main differences in *why* you would select an Agile approach (versus a traditional project management approach) and then recommend these [3 Steps to Develop an Agile Product Roadmap](/guides/develop_an_agile_product_roadmap/) that define the product / project's path to success. - - -### Agile Approaches - -The CTO Team provides Agile coaching, resources, and guidance in the Scrum, Kanban, and [DevOps](/guides/what_is_devops/) approaches. Regardless of the framework used, the goal is to continuously improve upon iterative development and encourage [Collaboration Across Agile Teams](/guides/collaboration_across_agile_teams/). We can walk you through [Conducting an Agile Project](/guides/conducting_an_agile_project/) and provide guidance on [Establishing an Agile Team Working Agreement](/guides/agile_team_working_agreement/), [Managing Requirements in an Agile Environment](/guides/managing_requirements/), [Defining When a Requirement is Complete](/guides/requirements_complete/), [Writing Effective User Stories](/guides/effective_user_stories/), [Estimation & Story Pointing](/guides/estimation_and_storypointing/), and facilitating successful [Agile Meetings Goals and Benefits](/guides/agile_meetings_goals_and_benefits/). - - -### Agile Contracts - -As efforts progress, Business groups may require procurement of Agile resources to fill project roles through a contract. The CTO Team has worked with various groups across GSA IT and outside organizations, including Contracts and Acquisition, to develop supporting resources for Agile contracts, including a [PWS Template](/guides/agile_contracts_pws_template/) and [Task Order Template](/guides/agile_contracts_taskorder_template/) (also available in a downloadable MS Word format). The template provides contract language guidelines and sample language for procuring resources through an Agile BPA. Further, we have comprised Agile interview questions for [Vendors](/guides/agile_contracts_interview_questions_for_agile_vendors/) and [Roles](/guides/agilecontracts_interview_questions_for_agile_roles/) to ensure informed selection of the right approach and skillsets for a successful Agile project / product delivery process. - -*For frequently-asked, high-level questions regarding Agile, check out the [Agile FAQ](/guides/agile_faqs/). For various terminology used throughout the content, the [Glossary](/guides/glossary/) provides an up-to-date reference. Additionally, most content cites sources used or a “Good Reads” section that includes reference information.* diff --git a/content/guides/API_standards.md b/content/guides/API_standards.md deleted file mode 100644 index 8e14f4ed..00000000 --- a/content/guides/API_standards.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: API Standards -category: API ---- - -GSA has developed [API Standards](https://github.com/GSA/api-standards) that capture GSA's recommended best practices, conventions, and standards for Application Programming Interfaces (APIs). - -API Security is governed by the GSA IT Security Procedural Guide: API Security CIO-IT Security-19-93. Reference that guide for security-related topics such as HTTPS encryption, authentication, and authorization. - -The API standards include these required items: - -1. **Add Your API To The GSA API Directory** - The GSA API Directory is available at [https://open.gsa.gov/api](https://open.gsa.gov/api). -2. **Use The api.data.gov Service** - The [api.data.gov service](https://api.data.gov/about/) is an API management service for federal agencies. GSA APIs should use the api.gsa.gov base domain with this service. -3. **Provide Support For Versioning** - Versioning APIs makes the process of adding new functionality smoother and less disruptive to existing API consumers. -4. **Provide Public Documentation** - The developer's entry point to an API is its documentation. Clear and functional documentation improves the on-boarding process. -5. **Provide A Feedback Mechanism That Is Clear and Monitored** - Having an obvious mechanism for clients to report issues and ask questions about the API demonstrates that the API can be counted on for production usage. -6. **Provide An OpenAPI Specification File** - Providing this allows consumers to understand the details and can be used by development or testing tools accessing your API. -7. **Follow The Standard API Endpoint Design** - This allows for a standardization of all Public APIs released for easier consumption. Exceptions: Not required for SOAP APIs. Not required for APIs that were in progress or production prior to December 2018. diff --git a/content/guides/API_strategy.md b/content/guides/API_strategy.md deleted file mode 100644 index d86fe7ba..00000000 --- a/content/guides/API_strategy.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: API Strategy -category: API ---- -[The GSA API Strategy](/assets/cms/files/GSAAPIStrategy.pdf) describes GSA’s direction for agency­-wide API design, development, architecture, operations and support, and security. We want to use public APIs to expose public data for transparency, data consumer engagement, and application development. We also want to use non-public APIs to promote system integration and migration of legacy systems. In all these efforts, we seek to adopt industry best practices for API design, development, and management. - -## API Strategy Implementation Approach - -The following diagram demonstrates the three-pillar approach we are following to implement this strategy: - -![API Strategy image listing the 3 pillars of Implementation: External Customer Experience, Internal Engagement, and Technical Architecture](/assets/cms/guides/api_3_pillars.png "3 Pillars of Implementation") - -## Pillar 1: External Customer Experience - -Providing APIs and API documentation that fulfill the needs of customers. Designing from a user-focused perspective, rather than technology-focused. The [GSA API Directory](https://open.gsa.gov/api) and [Self-service API Documentation Hosting](https://github.com/GSA/open-gsa-redesign/blob/master/APIDOCS.md) are the primary methods of implementing this. We also plan to implement Human Centered Design (HCD) techniques to enhance our developer experience. - -## Pillar 2: Internal Engagement - -Building a community of API owners and practitioners inside GSA to develop APIs in a consistent fashion. The [GSA API Standards](/guides/api_standards), [GSA API Guild](/apiguild), and [GSA API Management Portfolio](/apiportfolio) are key components of this pillar. - -## Pillar 3: Technical Architecture - -Designing technology solutions for developing and hosting high quality APIs. Creating technical guides to assist teams in implementing APIs that follow the [GSA API Standards](/guides/api_standards). \ No newline at end of file diff --git a/content/guides/AgileContracts_Interview_Questions_for_Agile_Roles.md b/content/guides/AgileContracts_Interview_Questions_for_Agile_Roles.md deleted file mode 100644 index f6bb6926..00000000 --- a/content/guides/AgileContracts_Interview_Questions_for_Agile_Roles.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Agile Contracts - Interview Questions for Agile Roles -category: Agile ---- - -This content provides scenarios and questions that are intended to guide the the government representative during the interview and evaluation phase where a candidate is being considered for an Agile delivery role. These sample questions can be used to evaluate and assess the overall experience, competency and compatibility of a candidate (Federal or contractor) being considered for specific roles in Agile methodologies (e.g. Scrum Master, Product Owner, developer, tester, etc.) - -## Scrum Master Interview Questions - -The Scrum Master (SM) is responsible for facilitating and maintaining the Scrum process and the overall health of the process and team. The Scrum Master performs this role by administering the Scrum ceremonies, facilitating the organic self-organization of the team, and removing any obstacles that may be impeding the team’s progress. - -**Below are some of the basic Scrum Master Interview Questions when vetting a candidate for this position:** - -|**Interview Questions**|**Agile Response Samples**| -|---------------|---------------| -|How do you differentiate your role as a Scrum Master against the Project manager or the Product Owner role?|| -|How do you facilitate the creation of an effective scrum team? What does your ideal Scrum team look like?| | -|How do you help the team set sprint goals? | | -|Why and how do you conduct the Daily Scrum meeting?| | -|What is your experience with guiding teams with estimation?| | -|If the team’s work doesn’t get completed in a sprint, what would you do?| | -|What is your experience with reporting and metrics?| | -|How do you help your teams continuously improve and reach their product/sprint goals?| | - -## Product Owner Interview Questions - -The Scrum Product Owner (PO) is the primary project key stakeholder. The primary role of the product owner is to have a vision of what needs to be built, and convey that vision to the scrum team. The Product Owner is the lead champion of the product and is responsible for ensuring the product creates value for its customers and users as well as the company providing it. The PO does this through the product backlog, which is a prioritized features list for the product. - -**Below are some of the basic Product Owner interview questions when vetting a candidate for this position:** - -|**Interview Questions**|**Agile Response Samples**| -|---------------|---------------| -|How would you characterize your role as a Product Owner?|| -|What is the difference between a Product Backlog and a Project Backlog?| | -|Describe your role as a PO in the Scrum Ceremonies/meetings?| Understands that the PO is integral in keeping the team on track and plans to be an active and regular participant in the collaborative activities and meetings. | -|What is your approach to creating and managing product roadmaps?|| -|What does a typical day look like as an Agile Product Owner?|| -|How do you manage changing requirements?| Plans to employ Agile approaches to managing changes in requirements, such as: | -|How do you avoid misallocating resources to features or products that are NOT a priority? || -|What would you say are the most important skills for a PO? || - - -## Developer Interview Questions - -|**Interview Questions**|**Agile Response Samples**| -|---------------|---------------| -|How would you say Agile development impacts the programming design and development process?| | -|How long is a typical sprint cycle when you are breaking work down and estimating?| | -|What would you say are the most essential programming best practices within the Agile development frameworks?| An in depth understanding of the nature of Agile development and delivery process such as: | -|What is your experience writing automated test cases? | | -|What is your experience with continuous integration? | Detailed explanation of how continuous integration is used on previous projects| -|How did you manage traceability of the requirements?| | -|How do you handle changing requirements?| | -|How do you understand team velocity to measure team capacity?| | -|What would you say are the most important skills for an Agile developer?| Technical:| - -## Tester Interview Questions - -|**Interview Questions**|**Agile Response Samples**| -|---------------|---------------| -|How is Agile Testing different from traditional testing models, in light of the role of the tester?| | -|How do you decide what to test, and how to thoroughly to test?| One approach is to identify and analyze the most and least important in the delivery product. Consider rational inclusion/exclusion criteria based on the product such as; | -|What is your testing approach when requirements change continuously?| Some possible answers can be; | -|What types of testing are you familiar with?| Examples of the various types of testing in Agile development include; | -|What is Test Driven Development (TDD)?| TDD is an approach where the development team first writes automated test cases which describe new functionality cases and creating small codes to pass that case. Followed by the refactoring of the code to meet the test criteria.| -|What is your experience writing automated test cases?| | -|What is your experience with Agile frameworks? | | -|What would you say are the most essential skills for an Agile tester?| | -|What qualities / attributes should a good Agile tester have?| | - - -## Additional Reference - -* [42 Scrum Product Owner Interview Questions](https://age-of-product.com/42-scrum-product-owner-interview-questions/) -* [How to Manage Change Requests](http://www.bridging-the-gap.com/how-to-manage-change-requests/) -* [7 Skills You Need to Be a Great Product Owner](https://www.scrumalliance.org/agile-resources/7-skills-you-need-to-be-a-great-product-owner) -* [Essential Skills for the Agile Developer](https://www.agilealliance.org/resources/sessions/essential-skills-for-the-agile-developer/) diff --git a/content/guides/Agile_Adoption_Challenges_and_Best_Practices.md b/content/guides/Agile_Adoption_Challenges_and_Best_Practices.md deleted file mode 100644 index 30431bb5..00000000 --- a/content/guides/Agile_Adoption_Challenges_and_Best_Practices.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Agile Adoption Challenges and Best Practices -category: Agile ---- - -Various [data sources](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf) indicate that the top most common challenges to successful Agile in organizations are mostly related to all or one of the following. - -**Company philosophy at odds with core Agile values.** Company culture continues to dominate as the top cause of failed organizational Agile implementations. The failure to overcome cultural resistance and build an Agile-ready organization is the number one barrier to successful enterprise Agile adoption. Cultural change is critical to ongoing successful corporate Agile adoption because in most cases, Agile must co-exist with traditional development approaches. Successful Agile implementations need support from the team members, management, and executives to embrace new ways of completing work and collaborating. Roles in the organization will be affected in some way. - -{{
}} - -*Recommendation*: Start small. Experiment with pilots and prototypes. Ensure key stakeholders have a common understanding of Agile concepts and benefits. Set up a robust feedback mechanism to involve stakeholders early on in the process. Show and communicate progress and success. Envision Agile benefits, desired outcomes, a foundational roadmap and how to measure success. Plan a concise, contextualized strategy for Agile transformation. Others throughout The organization will realize when something great is happening and will jump on the bandwagon to adopt a methodology that is showing promise. - -**Inadequate experience with Agile approaches.** For most new Agile teams, members are typically inexperienced in applying basic Agile practices and unfamiliar with successful agile transformations. An Agile process will expose problems and issues with the project more quickly than a more traditional development process; addressing such and what to do about those problems and issues is also not always very clear to new and inexperienced Agile teams. Challenges can surface in prioritization, breaking up requirements into testable and independent increments, understanding and communicating problems that need to be addressed on a retrospective, etc. that add up and make the difference for the team’s success or failure with Agile. - -{{
}} - -*Recommendation*: Understand that inexperienced teams need more formal process and guidance. Focus on collaborating to design an intuitive product or process rather than extensive training. Include an experienced Agile resource to coach on the team that has strong experience practicing Agile methods, and experience being successful with Agile. Optimize work with distributed teams using easily accessible, intuitive communication and collaboration tools. If possible, keep team members stable on a project until the project is completed. This will help teams mature and develop a cadence and well-defined velocities that provide better predictability to product owners and stakeholders. Invest in making training and continued coaching guidance available for the teams to consult. Encourage a learning organization by launching a community of practice. - -**Lack of management support.** Typically this relates to ‘middle management’ lack of trust for a new process, lack of understanding of changing roles and a lack of engagement or buy-in to the new process. In most enterprise wide agile implementation efforts, it is common for teams and executive to have great enthusiasm for the effort. However, in the absence of a strong Agile transformation plan, project and program managers or, functional “resource” managers often feel isolated mainly because their roles are no longer clear. This results in a general resistance and creates additional barriers to further Agile adoption and success. - -{{
}} - -*Recommendation*: Executive leaders should model the behavior they want their management team to display. Lead by being an example and live the values they want them to adopt, and help middle managers understand how they fit into the changing organization. - -**External pressure to follow Legacy systems and processes.** This is especially common in large enterprises, where some teams follow Agile approaches and other parts of the organization operates within traditional waterfall approaches, sometimes working under the umbrella of the same portfolio or program. In such cases, the Agile teams are usually being grafted into the existing traditional portfolio and project management methodology, and with teams that are working against different schedules, trying to deliver on a specific project. - -{{
}} - -*Recommendation*: Aim to get business units aligned through training to ensure that managers of different areas are not siloed and understand the implications of interacting with teams that do work in the new way. The ultimate goal should be to break dependencies across the entire organization. Adopt an Agile funding model where investment is made in small increments in a way that allows for prototyping, learning early and course correction so that cross-functional teams can learn to work using an Agile approach. Change your metrics. Identify new metrics that move away from measuring and tracking lines of codes, quality issues and reports as success factors and deliverables Focus on “working product” and value delivery; they should be the greatest measure of success in an Agile environment. And to achieve this, facilitate continuous collaboration between the business and the development team. - -**Data Sources** -* [VersionOne: 10th State of Agile Survey](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf) -* [Gartner](http://www.gartner.com/technology/topics/trends.jsp) - -**Additional Reads** -* [Change Management for Agile Projects](http://enterprise-knowledge.com/change-management-for-agile-projects/) -* [The Agile Cultural Shift: Why Agile Isn’t Always Agile](https://www.cgi.com/sites/default/files/white-papers/agile-culture-white-paper.pdf) -* [Why Agile Fails when Organizations try to “Go Agile”](http://enterprise-knowledge.com/why-agile-fails-when-organizations-try-to-go-agile/) diff --git a/content/guides/Agile_Contracts_Interview_Questions_for_Agile_Vendors.md b/content/guides/Agile_Contracts_Interview_Questions_for_Agile_Vendors.md deleted file mode 100644 index 9a45c735..00000000 --- a/content/guides/Agile_Contracts_Interview_Questions_for_Agile_Vendors.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Agile Contracts - Interview Questions for Agile Vendors -category: Agile ---- - -This content provides scenarios and questions that are intended to guide the the government representative during  the interview and evaluation phase where a vendor representative has been shortlisted and is being considered for an Agile delivery RFI or RFP. These sample questions can be used to assess the overall experience, competency and compatibility of a vendor or contractor for Agile product development or project management  engagements. Please refer to the *“Agile Roles: Interview Questions”* guide for interview questions for evaluating candidates being considered for specific roles in agile methodologies (e.g. Scrum Master, Solutions Architect, etc.). - -## Product Development: Scope and Changing Requirements - -|**Interview Questions** | **Agile Response Samples** -|---------------|---------------| -| How do you apply Agile in your general Product development process? |Process in place to capture requirements and continuously evaluate the product backlog items:
  • Users are the center of design to source requirements, test and accept functionalities throughout development
  • Recurring sessions with the customer representative (Product Owner) to review backlog, (re)prioritize and update requirements.
| -|What is your process for seeking, capturing and managing customer feedback and requirement changes during product development? | Engages with customer representatives on an ongoing basis:
  • Plan to implement an agreed process for Change Management with the customer during sprints
  • Recurring product demos or meeting sessions for capturing feedback
  • Ongoing backlog planning and requirement negotiation sessions to work on highest priority work based on scope and product objectives throughout the product development lifecycle (e.g. The priority of not yet implemented functions can be downgraded in favor of new requests that are prioritized more important to achieve the primary objective of the contract).
| -|Can you provide case studies of Agile projects with similar complexity involving a product? |Shows effectiveness of sprint planning, implementation and release process
  • Sufficient details on a high-level or kick-off (design) sprints before starting on the delivery sprints
  • Dependency identification process
  • Resolution in the sprint planning
  • Low number of defects and integration issues during releases
| - -## Project Management Process and Approaches - -|**Interview Questions** | **Agile Response Samples** -|---------------|---------------| -|What is your team’s experience with Agile methodologies (e.g. Scrum, Kanban, Lean, SAFe, etc.)? | Identifies key personnel for Agile team roles and skillsets.
  • Project team is defined with cross- functional representation i.e. Scrum Master, Product Owner, Development Team (Web, database, etc.), UI/UX designers, testers, etc.
  • Experience and Credentials of Scrum Master, Product Owner (CSM/CSP, CSPO, etc.)
  • The individual team members that will carry out the project can be present for individual interviews
  • Plans for how the Team focus on identifying daily hurdles and having these obstacles removed quickly by the Scrum Master
| -|What is your approach for estimation and capacity planning? |Process in place to predict capacity during sprint planning and ensure sprint delivery commitments.
  • Relative estimation approaches (e.g. story points) for vague/broad requirements
  • Velocity determination as requirements are broken down
| -|How do you break down work into manageable user stories and tasks?| Dives further into the roles on the team, specifically the technical roles.
  • Identifies the technical personnel who are responsible for scoping user stories and setting technical direction. Is the technical direction being set by junior or senior personnel?
| -|Describe an ideal work week| Framework and rules of engagement to ensure development team is working as efficiently as possible.
  • Description of communication channels from product owner/ stakeholder to development team and vice versa
  • Further elaboration of daily scrum/ standup meetings- technologies used, format, timing.
| -|How do you measure performance and effectiveness? | Framework for capturing product metrics (e.g. effectiveness, quality, sprint / product Burndown/Burnup charts, etc.).
  • What success looks like on similar Agile Projects. Request for examples from specific projects.
  • What kind of reports / dashboards will be generated
  • Sample measures in relation to Story Cycle Time, Velocity, Defect Density, test statistics, etc.
  • How customer meetings would be conducted, plain status reports or contain insights and learning from the retrospectives. Request for sample reports to evaluate.
| -|What approaches do you use for continuous process improvement? |Mechanisms in place for effective retrospectives / Lessons Learned sessions.
  • Measures of velocity to set higher targets for improvements
  • Review work process at the end each sprint and take corrective actions
| - -## Delivery Process - -|**Interview Questions** | **Agile Response Samples** -|---------------|---------------| -|How would you explain a minimum viable product (MVP) based on your delivery approach? | Process ensures the highest priority items are delivered in increments.
  • Ready and able to showcase development process if given one week to develop a piece of functionality
  • Process in place to deliver increments which represent a cumulatively growing subset of the final product
  • Deliver the minimum set of features required to meet the objectives of users and customers
| -|What process do you use to identify end-users and capture their needs? | Process ensures end-user requirements are continuously reflected in the effort.
  • Methodology (e.g. Focus group workshops, surveys, interviews, shadowing, mindmaps, etc.)
  • Sample questions to be answered by users, that are intended to facilitate the understanding of user needs and not developing fully detailed specifications upfront
  • Participants: sample list of primary characteristics of users or personas to be recruited to participate in the research or approach for persona identification
  • Schedules: that are timeboxed and iterative, enable the process for feedback
  • Tools: UI / UX demo and test tools, meeting space needs
  • Reports / results format and dates
| -|How do you execute integration communications, testing and release management? | Sufficient engineering checks and balances in place to minimize defects and ensure delivery quality.
  • Approaches for design reviews, code review and unit testing e.g. automation practices
  • Plan for integration testing and / or performance testing for big releases
  • Process to ensure test cases and automation scripts are up-to-date
  • Support system of experienced designers/architects for ongoing architectural reviews to capture technical requirements
  • Communication plan with technical stakeholders
  • Agreements on the definition of done for each delivery/product increment
| -|What are examples of Agile tools and technology you are familiar with? (e.g. software development) | Shows tangible experience with a pool of tools and technologies relevant to the domain in question and support the Agile delivery and development process.
  • Examples of end-to-end tools used to facilitate projects (e.g. JIRA, Rally, VersionOne, Trello, DevOps tools for continuous delivery, etc.)
  • Examples of experience in IT Architecture and system development using Agile and DevOps development practices
  • Example projects and solutions to the cloud, hybrid, or on premise data centers, and employing automated testing
  • Security tools and practices needed at the code and user level; request examples the tools used.
| - - -## Additional Reading - -* [Finding a Partner to Trust: The Agile RFP](http://www.methodsandtools.com/archive/archive.php?id=84) -* [Top 20 Scrum Master & Agile Scrum Interview Questions](https://www.simplilearn.com/agile-scrum-master-interview-questions-article) -* [5 Agile Methodology Interview Questions To Find Your Next Testing Superstar](http://reqtest.com/testing-blog/agile-methodology-interview-questions/) -* [Your 16-Point Litmus Test for the Right Agile Development Services Vendor](https://www.brillio.com/insights/your-16-point-litmus-test-for-the-right-agile-development-services-vendor/) diff --git a/content/guides/Agile_Contracts_PWS_Template.md b/content/guides/Agile_Contracts_PWS_Template.md deleted file mode 100644 index 86e9f285..00000000 --- a/content/guides/Agile_Contracts_PWS_Template.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -title: Agile Contracts- PWS Template -category: Agile ---- - -This content provides contract language guidelines and is intended to serve as a template for the government representative during the development of a Performance Work Statement (PWS) under an Agile BPA. The sample language provided here can be used to clearly outline and communicate the background, objectives, and delivery requirements of the intended product / service in-line with an Agile delivery process. - -[GSA Tech Guides](/guides/) also provides additional content and guidelines that delve further into and provide concrete tools/techniques on requirement breakdown and relevant sizing approaches to encourage delivery on an Agile project. Some example content include: - -* [Conducting an Agile Project](../conducting_an_agile_project/) -* [Managing Requirements in an Agile Environment](../managing_requirements/) -* [Defining When a Requirement is Complete](../requirements_complete/) -* [Estimation and Relative Sizing](../estimation_and_storypointing/) - -Moreover, [Interview Questions for Agile Vendors](../agile_contracts_interview_questions_for_agile_vendors/) and Specific [Agile Roles](../agilecontracts_interview_questions_for_agile_roles/) contents provde further guidance for GSA staff on what to inquire and expect from contractors during the vetting process. - -## PERFORMANCE WORK STATEMENT (PWS) TEMPLATE - -**[DOWNLOAD PWS Template](/assets/cms/files/AgileContractsPWSTemplate.docx)** - -### Background - -[Provide background for the Task Order, outline why the contractor team would want to work on this and who the major user groups would be] - -### Scope - -[Provide scope of work for Task Order] - -_Sample Scope Statement_ - -*The scope of this task order is for the Contractor to deliver the {name of product / system}.* - -*"The preceding high-level requirements must be met in order to fulfill the objectives of this task order and may be refined adaptively over the course of the effort to continuously meet specified user needs. User needs will be prioritized based on business value and technical dependencies in {name of application used for managing the product backlog}."* - -### Performance Objectives - -[Use this section to outline Objectives for the Task Order. Objective summarizes the Product Vision, High-level technical functions, high-level business functions, Primary end-users and their high-level needs (if applicable), the development approach and description of systems to be used (if applicable), ongoing process for evaluating and determining changing scope] - -_Sample Objective Statement_ - -*"{Name of organization} is seeking the creation of {feature name} prototype of {name of system}. The new {name of system} will {desired high-level functionality} and meet evolving requirements while leveraging Agile best practices in software development including but not limited to; open source code, human-centered design, and with an extensible infrastructure and robust communication between the product sponsor and the project team.”* - -*“A minimum viable product (MVP) of this system is expected within the first {Time frame} under this task order. It is the Agency’s desire that the critical components, which are defined as “must haves” in priority (see {section name requirements}), are included to the greatest extent possible in the MVP. The MVP, which emerges out of user testing, must fall within the scope of the Product Vision as described in the statement of work or statement of objectives. Examples of high-level user stories include, “As a program manager, I would live to view a list FedRamp approved applications online so that I can invest on the right tools for my projects"* - -### Constraints - -[Provide technical constraints here] - -_Sample Constraint Statement_ - -*"Contractor shall adhere to US Web Design Standards or other development standards as developed by the 18F team. As part of this being purchased off of the Agile Blanket Purchase Agreement (aBPA), work will be conducted in two-week sprints and reviewed at the end of each sprint for acceptability before moving on. The contractor and government may mutually agree to alter sprint length as needed. The contractor will not be responsible to perform the following: {add here} e.g. Hosting development environments"* - -### Roles and Responsibilities - -#### Contracting Officer (CO) - -[Add specific roles here] - -_Sample Contracting Officer Language_ - -*"The Contracting Officer (CO) is responsible for monitoring call order contract compliance, contract administration, and cost control and for resolving any differences between the observations documented by the Government and the contractor. The CO will designate, at a minimum, one (1) CO’s Representative (COR) or one (1) Alternate CO’s Representative (ACOR) as the Government authority for performance management, based on the complexity of the services measured, as well as the contractor’s performance."* - -#### Procurement Manager - -[Add specific roles here] - -_Sample Procurement Manager Language_ - -*"The Procurement Project Manager is the interface between the requiring organization (GSA 18F) and contracting organization. The Procurement PM coordinates technical aspects of the contract with the COR / ACOR and CO, assists with contract administration, ensures client acceptance of services, and reviews invoices for payment."* - -#### Product Lead - -[Add specific roles here] - -_Sample Product Lead Language_ - -*"The Contractor shall provide a Project Lead as the primary point of contact for the coordination between the contractor, the Product Owner, as well as the CO and COR / ACOR. The Project Lead’s responsibilities include:* - -* _Coordination with the contracting organization’s program office to enable timely problem resolution,_ -* _Properly aligning staffing requirements_ -* _Facilitating product reporting in line with Agile delivery methods. Per Agile development principles, the Contractor’s Project Lead will be expected to work with the 18F Product Owner and Scrum Master to develop Product / Sprint plans and reporting in line with Agile delivery approaches."_ - -#### Product Owner (PO) - -[Add specific roles here] - -_Sample Product Owner Role Statement_ - -*"The Product Owner is the project’s key stakeholder and is from the Federal product line team. The PO shall be responsible for having a vision of what product team wishes to build, and convey the vision to the contractor’s scrum or development team. The PO’s responsibilities include, but are not limited to, the following:* - -***Creating and Managing the Product Backlog:** The PO is responsible for delivering and maintaining the Product backlog with a complete with a prioritized list of features containing descriptions of desired functionality of the product.* - -***Providing clarification on requirements during Agile ceremonies:** Working with the Scrum Master, the PO shall hold recurring backlog refinement sessions to continuously refine and prioritize requirements and decision-making during sprint planning and implementation. The PO shall ensure the sprint backlog is created with the highest priority work to deliver the product.* - -***User Acceptance Review:** The Product Owner shall work with the COR / ACOR to inspect and accept / approve Contractor work delivered each sprint."* - -*The PO role should be filled from the Federal side as a representative of the needs of the sponsoring business line.* - -#### Scrum Master - -[Add specific roles here] - -_Sample Scrum Master Role Statement_ - -*"The Scrum Master is responsible for facilitating Agile ceremonies and discussions among development and customer team members. They are responsible for coaching the team on the Scrum processes and removes impediments for the team. Scrum Master Role activities include, but are not limited to, the following:* - -***Facilitate Scrum Meetings:** The Contractor is to coordinate and facilitate scrum meetings, such as, Sprint planning, Backlog Refinement, Sprint Reviews and Sprint Retrospectives and provide just enough records.* - -***Team Performance and Metrics:** The Contractor works with product leadership and the team to define relevant metrics that are formulated and utilized for meeting project objectives.* - -***Team Coaching and Coordination:** When appropriate, the Scrum Master shall plan and coordinate trainings and coaching for the team on the Scrum processes. The Scrum Master serves the Product Owner Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value"* - -*This role should be filled from the Federal side as a representative of the needs of the sponsoring business line."* - -#### Technical Lead - -[Add specific roles here] - -_Sample Technical Lead Language_ - -*"The 18F Technical Lead is responsible for coordination between the contractor’s development team, the Product Owner and the key technical stakeholders."* - -### Operational Requirements - -#### Personnel - Skills and Knowledge - -[Add specific skills and knowledge required here] - -_Sample language on Skills and Knowledge_ - -*"The contractor shall provide qualified personnel with relevant experience and domain knowledge in line with this task's performance work statement, in terms of necessary skills at the requisite level of knowledge and experience. Broadly, a team assigned to build the {product name} is expected to have experience with:* - -*{List relevant domain here} e.g. building and testing web-based or mobile applications: user-centric design practices, usability testing, User experience design, Visual design, Specific code languages, Cloud deployment, Open-source login / authentication services, Agile and scrum methodologies, etc."* - -### Deliverables - -[Add specific details here] - -*"The Contractor is required to provide the following deliverables within the designated timeframes:* - -_Sample Deliverables table below_ - -| **Section(s)**| **Deliverable**| **Due Date**| **Delivery Method**| -|----------------|-----------------|--------------|---------------------------| -| # | Product Backlog | Beginning of each sprint | Electronic / visual board accessible via web (e.g. JIRA, Trello, etc.) | -| # |Design Deliverables | End of every applicable sprint | Mock ups and / or design files (if applicable) or design changes reflected in the Development Prototype| -| # |Development Prototypes | End of second sprint, and every sprint | accessible on the web via staging server / development server| -| # |Reports | One business day after each sprint | Demo of product increment, Sprint performance metrics, etc.| -| # |Transition plan | # business days before the conclusion of the second-to-last sprint | See transitions Section | -| # |Code Repository of Product - Version controlled | End of call order|Version-controlled Open Source repository of code that comprises product that will remain in the public domain | - -### Review and Acceptance - -[Add specific details applicable to review of deliverables and acceptance process here] - -_Sample Language for Acceptance and Inspection_ - -*Quality Assurance - "The Government will provide a Quality Assurance Surveillance Plan (QASP) to monitor the Contractor’s performance. The QASP will provide oversight help to ensure that service levels reach and maintain the required levels for performance of this task. Further, the QASP provides the COR with a proactive way to avoid unacceptable or deficient performance, and provides verifiable input for the required Past Performance Information Assessments. The QASP is a living document and may be updated by the Government as necessary. Any updates to the QASP will be provided to the Contractor."* - -*"The Government and Contractor define acceptance of the deliverables as follows:* -*Deliverable passes all new automated and manual acceptance tests that were defined before the most recent iteration. Deliverable passes all prior automated and manual acceptance tests, verifying that no regression has occurred. Deliverable conforms to the “definition of done” that was defined before the iteration.* - -*"The customer/PO will have a period of one week within an iteration (“Evaluation Period”) after increments of a deliverable have been provided to verify that the Deliverable or part thereof is not deficient per acceptance criteria. The PO should notify Contractor prior to the expiration of the relevant Evaluation Period if the Deliverable or part thereof is deficient in any material respect (a “Nonconformity” pursuant to the definition of done or acceptance criteria agreed upon by the parties). The Contractor will correct such Nonconformity as soon as reasonably practical but no longer than the length of one iteration whereupon. The Government will receive an additional Iteration period (“Verification Period”) commencing upon its receipt of the corrected Deliverables or part thereof to verify that the specific Non-conformity has been corrected.”* - -*“The Contractor will also deliver the release test plan which is a step by step walkthrough of the functionality in the release and allows the user community to make notes and comments regarding how that functionality can be improved and made more useable or defect-free. The Contractor shall work to correct all errors and increase usability. Comments that are delivered within [agreed # of days] of the release walkthrough shall be included in the subsequent deliverable/release.”* - -### Transitions - -#### Transition Plan - -[Add specific details applicable to transitions here] - -#### Transition Activities - -[Add specific details applicable to transitions here] - -### Travel and Other Direct Costs (ODC) - -[Add specific details applicable here] - -### Terms and Conditions - -#### Type of Contract - -[Add specific details applicable here] - -_Sample Language for Contract Type_ - -*"This is a [labor-hour (LH) FFP, Hybrid, etc.] order under master Agile BPA (aBPA) terms and conditions"* - -#### Period of Performance (POP) - -[Add specific details applicable here] - -_Sample Language for POP_ - -*"The Period of Performance (POP) includes a base period of 3 month, with 5 additional option periods, each 3 months in duration. Further, a contingency of up to 6 months may be exercised . The POP is expected to begin within 10 calendar days after award."* - -#### Place of Performance - -[Add specific details applicable here] - -#### Contract Administration - -[Add specific details applicable here] - -### Payment and Invoicing Procedures - -#### Content of Invoice - -[Add specific details applicable here] - -#### Final Invoice - -[Add specific details applicable here] - -#### Close-out Procedures - -[Add specific details applicable here] - -**[DOWNLOAD PWS Template](/assets/cms/files/AgileContractsPWSTemplate.docx)** for additional resources including *pricing templates* - -**References** - -* [The TechFAR Handbook for Procuring Digital Services Using Agile Processes](https://github.com/usds/playbook/blob/gh-pages/_includes/techfar-online.md) -* [Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, Agile Contracts Primer](http://www.gao.gov/products/GAO-12-681) Tom Arbrogast, Craig Larman, and Bas Voddee, -* [Finding a Partner to Trust](https://agilecontracts.org/) The Agile RFP, by Peter Stevens cited -* [Agile Services for the Enterprise, Statement of Work Template](http://www.methodsandtools.com) - GSA Alliant Shared Interest Group (SIG) -* [PERFORMANCE WORK STATEMENT (PWS)](https://github.com/18F/bpa-opm-eqip/blob/master/PWS.md) Electronic Questionnaires for Investigations Processing (e-QIP) Prototype Development diff --git a/content/guides/Agile_Contracts_TaskOrder_Template.md b/content/guides/Agile_Contracts_TaskOrder_Template.md deleted file mode 100644 index 1e2339c9..00000000 --- a/content/guides/Agile_Contracts_TaskOrder_Template.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Agile Contracts- Task Order Template -category: Agile ---- - -This content provides contract language guidance and is intended to serve as a template for the government representative during the development of a Task Order under an Agile BPA. The sample language provided here can be used to clearly outline and communicate the high-level objectives and task-level delivery requirements of the intended product / service in line with an Agile delivery process. Additionally, this Task Order structure enables the government to allow contractors to work in a flexible way while maintaining high expectations for code quality and successful agile project management. - -[GSA Tech Guides](/guides/) also provides additional content and guidelines that delve further into and provide concrete tools/techniques on requirement breakdown and relevant sizing approaches to encourage delivery on an Agile project. Some example content include: - -* [Conducting an Agile Project](/guides/conducting_an_agile_project/) -* [Managing Requirements in an Agile Environment](/guides/managing_requirements/) -* [Defining When a Requirement is Complete](/guides/requirements_complete/) -* [Estimation and Relative Sizing](/guides/estimation_and_storypointing/) - -Moreover, [Interview Questions for Agile Vendors](/guides/agile_contracts_interview_questions_for_agile_vendors/) and Specific [Agile Roles](/guides/agilecontracts_interview_questions_for_agile_roles/) contents provde further guidance for GSA staff on what to inquire and expect from contractors during the vetting process. - -## AGILE BPA TASK ORDER TEMPLATE - -**[DOWNLOAD Task Order Template](/assets/cms/files/AgileContractsTaskOrderTemplate.docx)** - -### Background - -[Provide background for the Task Order, outline why the contractor team would want to work on this and who the major user groups would be] - -### Objectives - -[Use this section to outline Objectives for the Task Order. Objective summarizes the Product feature in light of vision of the product and high-level technical functions, high-level business functions, Primary end-users and their high-level needs (if applicable), the development approach and description of systems to be used (if applicable), ongoing process for evaluating and determining changing scope] - -_Sample Objectives Statement_ - -*The [Applicant tracking system (ATS)] will enable the electronic handling of recruitment needs. The ATS will enable the organization to collect and store candidate and job related data, track and monitor the process of candidates through all stages of the hiring process. The product will support HR policies and federal regulations as applicable.* - -*“Users and user needs will be prioritized based on business objectives / value and technical dependencies in [name of application used for managing the product backlog].”* - -### Scope - -[Provide scope of work for Task Order] - -_Sample Scope Statement_ - -*“The scope of this task order is for the Contractor to deliver the [name of product / feature of a system]"* - -_Sample High-level User Scope in User Story Format_ - -*“As a job applicant, I want the ability to access a virtual job application so that I am able to edit, submit and track the status of my job application online”* - -*“As an HR representative, I will be able to view applicants information and data online”* - -*“As the hiring manager, I want the system to perform preliminary data validation checks on “required” questions, so that sufficient information is submitted for my review.”* - -*“As a system security specialist, I want the system to “mask” user's login credentials, so that the user's security information is protected from possible system breaches.”* - -*The scope also includes the technical and related project management activities such as but not limited to:* - -- *Tasks that the contractor must successfully perform,* -- *Operational requirements that must be met while the contractor performs,* -- *Generalized administrative requirements and any other terms and conditions,* -- *Invoicing Instructions for contractor to receive payment”* - -### Roles and Responsibilities - -[Add specific roles here] - -**[DOWNLOAD](/assets/cms/files/AgileContractsPWSTemplate.docx) the Performance Work Statement (PWS) Template for sample language on Agile Roles and responsibilities** - -### Tasks - -[Add specific tasks here] - -_Sample Tasks Statement_ - -- *“The following requirements must be met in order to fulfill the objectives of this task order and may be refined iteratively over the course of the effort to continuously meet specified user needs. Specifically, the contractor will provide the following tasks and services:* -- *Contractor shall coordinate with the government and [name of sponsoring organization] stakeholders to conduct end-user research on the [application name] and agency-user experiences and apply the research to inform application and content design and development.* -- *Contractor shall use plain language in application design and development, wherever possible.* -- *Work with GSA’s Office of Chief Information Officer in order for the System to receive Authority to Operate [list technology stack options that are already approved].* -- *Contractor shall select a technology stack that accomplishes the needs as stated in the objectives.* -- *Contractor shall work with the government and [name of sponsoring organization] project teams to ensure that the system is compliant with interagency requirements and policies, to include security policies.* - -*“As part of this being purchased off of the Agile Blanket Purchase Agreement (aBPA), work will be conducted in two-week sprints and reviewed at the end of each sprint for acceptability and feedback"* - -### Operational Requirements - -[Add specific Personnel Skills and Knowledge] - - _Sample Sample Language on Skills and Knowledge_ - -*“The contractor shall provide qualified personnel with relevant experience and domain knowledge in line with this task's performance work statement, in terms of necessary skills at the requisite level of knowledge and experience. Broadly, a team assigned to build the [product name] is expected to have experience with:"* - -*[List relevant domain here] e.g. building and testing web-based or mobile applications: user-centric design practices, usability testing, User experience design, Visual design, Specific code languages, Cloud deployment, Open-source login / authentication services, Agile and scrum methodologies, etc.”* - -*“Both COR + Tech Lead need to coordinate with vendor on setting up development and test environment and access to accounts prior to kick off."* - -### Deliverables - -[Add specific details here] - -**Also [DOWNLOAD](/assets/cms/files/AgileContractsPWSTemplate.docx) the Performance Work Statement (PWS) Template for sample language on Contractor deliverables, delivery method examples and timeframes** - -### Transitions - -#### Transition Plan -[Add specific details applicable to transitions here] - -#### Transition Activities -[Add specific details applicable to transitions here] - -### Travel and Other Direct Costs (ODC) - -[Add specific details applicable here] - -### Terms and Conditions - -#### Type of Contract - -**Also [DOWNLOAD](/assets/cms/files/AgileContractsPWSTemplate.docx) the Performance Work Statement (PWS) Template for sample language for types of contract language** - -#### Period of Performance (POP) - -[Add specific details applicable here] - -_Sample Language for POP_ - -*"The Period of Performance (POP) includes a base period of 3 month, with 5 additional option periods, each 3 months in duration. Further, a contingency of up to 6 months may be exercised . The POP is expected to begin within 10 calendar days after award."* - -#### Place of Performance - -[Add specific details applicable here] - -#### Contract Administration - -[Add specific details applicable here] - -### Payment and Invoicing Procedures - -#### Content of Invoice - -[Add specific details applicable here] - -#### Final Invoice - -[Add specific details applicable here] - -#### Close-out Procedures - -[Add specific details applicable here] - -**[DOWNLOAD the Task Order Template](/assets/cms/files/AgileContractsTaskOrderTemplate.docx)** for additional resources including *pricing templates* - -**References** - -* [The TechFAR Handbook for Procuring Digital Services Using Agile Processes](https://github.com/usds/playbook/blob/gh-pages/_includes/techfar-online.md) -* [Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, Agile Contracts Primer](http://www.gao.gov/products/GAO-12-681) Tom Arbrogast, Craig Larman, and Bas Voddee, -* [Finding a Partner to Trust](https://agilecontracts.org/) The Agile RFP, by Peter Stevens cited -* [Agile Services for the Enterprise, Statement of Work Template](http://www.methodsandtools.com) - GSA Alliant Shared Interest Group (SIG) -* [Performance Work Statement (PWS)](https://github.com/18F/bpa-opm-eqip/blob/master/PWS.md) Electronic Questionnaires for Investigations Processing (e-QIP) Prototype Development diff --git a/content/guides/Agile_FAQs.md b/content/guides/Agile_FAQs.md deleted file mode 100644 index 67526863..00000000 --- a/content/guides/Agile_FAQs.md +++ /dev/null @@ -1,272 +0,0 @@ ---- -title: Agile FAQs -category: Agile ---- - -## What is Agile? - -Agile is considered an alternative approach to traditional project management or product development. It is a value-based, iterative approach under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. - -Although it rose out of software development practices, Agile is not a software-development framework. It is neither methodological nor prescriptive; there is no exact way to become Agile. Also, Agile is not synonymous with Scrum (or Kanban, TDD, etc.) or a specific tool (i.e. JIRA, Rally, etc.). - -The term agile was first coined for this in 2001, in the Manifesto for Agile Software Development (Agile Manifesto) and although originally written as Agile (with a capital A) this is progressively becoming deprecated. - -Success in Agile is based on an attitude of “servant leadership” and focuses on the team, not just developers. Agile encourages and does not lack in accountability or ownership. As a solution for complex problems, teams must “be” Agile, not just “do” Agile. - -More information and associated documents can be found in our [Agile guides](/guides/0_a_guide_newtoagile/). - - -## What is the Agile Manifesto? - -The Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners . The participants found consensus around four main values below that makeup the Agile manifesto. - -**Individuals and interactions** over **processes and tools**. Agile is more about transparent interactions than technology. - -**Working software** over **comprehensive documentation**. Create something usable quickly to enable faster customer feedback. - -**Customer collaboration** over **contract negotiation**. Ensure customer buy-in between Business and IT, with marketable visibility. - -**Responding to change** over **following a plan**. Leave room for emergent solutions and better respond to change - -More information and associated documents can be found in our [Agile guides](/guides/0_a_guide_newtoagile/). - - -## What are the Principles of Agile? - -1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. - -2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. - -3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - -4. Business people and developers must work together daily throughout the project. - -5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. - -6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. - -7. Working software is the primary measure of progress. - -8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. - -9. Continuous attention to technical excellence and good design enhances agility. - -10. Simplicity — the art of maximizing the amount of work not done — is essential. - -11. The best architectures, requirements, and designs emerge from self-organizing teams. - -12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. - -More information and associated documents can be found in our [Agile guides](/guides/0_a_guide_newtoagile/). - - -## What are the most common Agile methodologies? - -### Scrum - -A framework for the iterative development of complex products, particularly software. Scrum is the most widely recognized Agile framework, and is compatible with other Agile practices like Extreme Programming. Scrum is comprised of a series of short iterations – called sprints – each of which ends with the delivery of an increment of working software. - -The framework is comprised of three roles: - -- Product Owner -- ScrumMaster -- (Scrum) Team - -Four Ceremonies: - -- Daily Standup Meeting -- Sprint Planning Meeting -- Sprint Review -- Retrospective - -Three artifacts: - -- Burndown charts -- Product backlog -- Sprint backlog - -Scrum should not be used interchangeably with the term Agile. Agile is not a framework, but a broader set of values and practices, while Scrum is a specific framework that fits comfortably under the Agile umbrella. - -### Kanban - -Kanban is a tool derived from Lean manufacturing and is associated with the branch of agile practices loosely referred to as Lean software development. Like a task board, Kanban board visually represents the state of work in process. Unlike a task board, the Kanban constrains how much work in process is permitted to occur at the same time with the purpose to reduce bottlenecks and increase throughput by optimizing that segment of the value stream that is the subject of the Kanban. - -A principle difference between Kanban and Scrum is that Scrum limits work in process through timeboxing (i.e. the sprint) and Kanban limits work in process by limiting how much work may occur at one time (e.g. N tasks or N stories). - -### Extreme Programming (XP) - -A software development methodology adhering to a very iterative and incremental approach, Extreme Programming is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. XP consists of a number of integrated practices for developers and management – the original twelve practices of XP include Small Releases, On-site Customer, Sustainable Pace, Simple Design, Continuous Integration, Unit Testing, Coding Conventions, Refactoring Mercilessly, Test-Driven Development, System Metaphor, Collective Code Ownership, and Pair Programming. Most successful Agile practitioners adopt some subset of XP practices, often in conjunction with Scrum. - -More information and associated documents can be found in our [Agile guides](/guides/0_a_guide_newtoagile/). - -## What is the difference between Agile and Traditional Project Management? - -### Traditional “Waterfall” Project Management - -- Requirements and design decisions are made up front -- Months of planning before development begins -- The customer sees the product for the first time when the final product is done/delivered - -### Challenges - -- Months before customers are interacting with what was developed -- No time to change course along the way. By the time people provide feedback, it is too late. - -!['Waterfall' Project Management](/assets/img/guides/EK_Waterfall.png) - -### “Agile” Project Management - -An agile approach enables rapid incrementally shippable deliverables and collaborative decision-making between the parties. In software, Agile is a method of software development that is based on **iterative and incremental delivery** approach that anticipates the need for flexibility into the delivery of the finished product. - -!['Agile' Project Management](/assets/img/guides/EK_Agile.png) - -The noteworthy differences for Agile development is the common delivery cycle and milestones in delivery cycle that include: - -- Time boxed and iterative/incremental product development/delivery -- Intermediate milestones: deliver a deployable system with useful features, it may have insufficient functionality -- Definition of Done/Releasability: each iteration/sprint delivery is done, programmed, tested, and so on, and is in theory releasable. - - -## How do organizations benefit from being Agile? - -One benefit of agile is to reduce a product’s time to market by delivering a product increment frequently. Through this process, customers and users are engaged throughout the delivery cycle to regularly review the product increment and provide feedback. By creating feedback loops with every increment, the product created value working with customers rather than for them. As a result, excess time and resources are not spent creating something customers do not want. - -Being Agile also promotes innovation in product teams. Taking an iterative, incremental approach promotes experiential learning, and short release cycles encourage teams to experiment to find relevant, simple solutions. - -![Agile Benefits](/assets/img/guides/Agile_Benefits.png) - -[VersionOne: 10th State of Agile Survey](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf) - - -## What are the common challenges to adopting Agile? - -Various data indicate that the top most common challenges to a successful Agile in organizations is mostly related to all or one of the following: - -- Company philosophy at odds with core agile values -- Lack of experience with agile methods -- Lack of management support -- Changing the development culture -- Team work using traditional development methods -- Lacking consistent practices - -Source: [VersionOne: 10th State of Agile Survey](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf) and [Gartner](http://www.gartner.com/technology/topics/trends.jsp) - - -## Do Agile approaches only work in the Software Development Industry? - -Although it arose out of software development practices, Agile is **not** just a software development framework. - -Many other areas outside of Technology have found success in developing an Agile culture, including [Manufacturing](http://www.fujitsu.com/global/documents/about/resources/publications/fstj/archives/vol43-1/paper16.pdf), [Marketing](http://agilemarketingmanifesto.org/), [Legal](http://www.abajournal.com/legalrebels/article/the_rise_of_the_agile_lawyer/), Customer Support, and more recently, Learning Design, and [Human Resources](http://hr-gazette.com/hr-agile-manifesto/). The benefits of an Agile culture provide more customer-focused efforts, increase communication, enable change, improve quality of delivery, provide a more responsive environment, and increase both transparency and visibility. - - -## Is Agile suitable for all projects? - -Not necessarily. Depending on the nature of the project and the product in question, there are times where plan-driven project management methodologies (like the waterfall method) provide a higher likelihood of project success. - -According to Mike Cohn, one of the contributors to the invention of the Scrum software development, the most [appropriate projects suitable for Agile](https://www.mountaingoatsoftware.com/blog/deciding-what-kind-of-projects-are-most-suited-for-agile) (Scrum, Kanban, etc.) are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to the organization or at least new to the team building it. For instance, developing a new phone application. - -If the project/product is very familiar to the team and if the team continues building the same thing everyday, there is an element of predictability that may not require an Agile approach to succeed. For instance, a fast food restaurant producing fries or burger with set recipes. - -If the project/product is very familiar to the team and if the team continues building the same thing everyday, there is an element of predictability that may not require an Agile approach to succeed. For instance, a fast food restaurant producing fries or burger with set recipes. - -There are various ways that can be used to decide whether the project team tasked with completing should be handled using an Agile framework or traditional plan-driven project management method, and it starts by taking a look at the information the team already has. Below is an example analysis based on risk and complexity. - -!['Agile' Suitable Project Management](/assets/img/guides/Agile_Projects.png) - - -## Who is practicing Agile? - -According to the [State of Agile Report: Agile Trends - 2015 Agile Survey](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf), agile software development has grown increasingly popular over the last decade. The number of large enterprises that are embracing agile continues to increase each year. - -### Agile Demographics - -![Agile Organizations Locations](/assets/img/guides/AgileOrgs_Location.PNG) - -In addition, 2 out of 3 IT organizations are either pure agile or or leaning toward agile (Source: [PMI Pulse of the Profession, 2016](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2016.pdf). - -![How often Agile project management is used](/assets/img/guides/Agile_In_PM.png) - -Agile approaches are also being used for teams outside of IT such as Marketing and Human Resources. The top three industries adopting Agile are Software Development, Financial and Professional Services (Source: State of Agile Report 2015). - -![Agile Industries](/assets/img/guides/Agile_Industries.PNG) - - -## What are the trends in Agile? - -The most popular Agile methodology is Scrum (Sources: Gartner 2015, VersionOne 2015). - -![Most Popular Agile Methods Used](/assets/img/guides/Agile_Methods_Used.PNG) - -- **80%** of organizations now have distributed agile teams, up from 35% two years ago (Source: VersionOne) -- Scaling agile is increasing: **57%** of organizations use Agile for program management; -- **51%** use Agile for portfolio management (Source: PMI, 2016) - - -## Are there specific tools for Agile? - -Although Agile does not require a specific set of tools for a successful adoption, not all traditional project management and other tools work well with Agile. Some companies configure existing tools in an Agile way while others use index cards and sticky notes to follow the frameworks. Some development group use JIRA software to help with things like requirements management, collaboration and testing. - -According to the [10th State of Agile Survey (2015)](https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf), out of the many software management solutions on the market, over two-thirds of survey respondents use Microsoft® Excel (60%) to manage agile projects. Other commonly used tools were Atlassian / JIRA (51%), Microsoft Project (33%), and VersionOne (28%). - -![Tools for Agile](/assets/img/guides/Agile_Tools.png) - - -## What are the most popular trainings / certifications on Agile? - -### Project Management Institute - Agile Certified Practitioner (PMI-ACP) - -The [Agile Certified Practitioner (ACP)](https://www.pmi.org/certifications/agile-acp) from the Project Management Institute (PMI), is for project management professionals whose organizations currently use or are moving to agile practices. The PMI-ACP proves certification holders have real-world experience managing agile projects and familiarity with many subsets of the agile methodology including Scrum, Kanban, Lean and others. Those who achieve the certification must earn 30 professional development units (PDUs) every three years to maintain their status. - -### Scrum Alliance - -Scrum is the leading framework of the agile methodology, especially for software development. The Scrum Alliance is the leading membership organization for Scrum professionals, with the mission of supporting widespread adoption and effective practice of Scrum. The Scrum Alliance offers [six Scrum certifications](https://www.scrumalliance.org/certifications) for IT and software development professionals: Certified Scrum Master, Certified Scrum Product Owner, Certified Scrum Developer, Certified Scrum Trainer, Certified Scrum Coach and Certified Scrum Professional. - -### International Consortium for Agile (ICAgile) - -The [International Consortium for Agile](https://icagile.com/) is an independent accrediting agency offering comprehensive agile certifications that provide role expertise across all agile 'flavors,' including Scrum, eXtreme Programming (XP), Kanban and more. There are three certification levels: Professional, Expert and Master, to test and evaluate candidate's knowledge acquisition and competency within Agile. - - -## Where can I find industry Agile conferences / events? - -The following websites provide information on the most popular and relevant Agile events and conferences taking place in the United States and around the world. - -- [AgileAlliance - Events](https://www.agilealliance.org/events/) -- [Agile and Beyond](http://agileandbeyond.com/) -- [Gartner’s Symposium/ITxpo](http://www.gartner.com/events/) - - -## Where can I find credible resources on Agile? - -### Agile Overview - -- [Agile Manifesto](https://agilemanifesto.org/) -- [Agile Alliance](https://www.agilealliance.org) -- [VersionOne](https://versionone.com) -- [Atlassian](https://www.atlassian.com/) - -### Setting Up Agile Teams - -- [How to build a kick-ass agile team](https://www.atlassian.com/agile/teams) -- [Building an Agile Team](https://www.infoq.com/articles/building-an-agile-team) -- [3 Key Steps to Building an Agile Team](https://www.cprime.com/resources/blog/-3-key-steps-to-building-an-agile-team/) -- [An Operating Model for Company-Wide Agile Development](https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/-an-operating-model-for-company-wide-agile-development) -- [Who is Watching After Your Agile Money?](https://www.cio.com/article/238370/who-is-watching-after-your-agile-money.html) - -### Scrum Teams - -- [Scrum Framework](https://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/) -- [Scrum Reference Card](http://scrumreferencecard.com/scrum-reference-card/) -- [Scrum Is, Scrum Is Not](https://kenschwaber.wordpress.com/2011/08/11/-scrum-is-scrum-is-not-2/) -- [Why Scrum?](https://www.scrumalliance.org/why-scrum) - -### Kanban Teams - -- [Everyday Kanban](http://www.everydaykanban.com/what-is-kanban) -- [Kanban Explained](http://kanbanblog.com/explained/) -- [LeanKit](https://leankit.com/learn/kanban/what-is-kanban/) - -### Data and Information on Agile Trends, Blogs, etc. - -- [VersionOne](https://versionone.com) -- [ScrumAlliance](http://www.scrumalliance.org) -- [Gartner Research](http://www.gartner.com/technology/research.jsp) diff --git a/content/guides/Agile_Investment_Proof-Of-Concept_phase_checklist.md b/content/guides/Agile_Investment_Proof-Of-Concept_phase_checklist.md deleted file mode 100644 index e08f705f..00000000 --- a/content/guides/Agile_Investment_Proof-Of-Concept_phase_checklist.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Agile Investment - Proof Of Concept (PoC) Checklist -category: Agile ---- - -During the PoC Phase: - -* Agile Scrum team is assigned to implement and test solution recommendation -* Provide and measure outcome of PoC team -* Review PoC recommendation -* Business / technical review to approve/reject progressing to next Phase - -## *Input* Checklist Before Starting PoC - -### Scope and Approach -* PoC scope is defined -* High-level business needs have been identified and prioritized -* High-level technical needs and requirements have been identified and prioritized -* Approach for PoC phase had been defined - -### People and Resources -* Sponsoring Department/Executive has been defined -* Key personnel resources and skill sets identified and secured -* Assigned Product Owner from the Business Team -* Assigned Scrum Master -* Agile coaching support and guidance -* Team members are fully dedicated to the PoC effort - -### Development Environment -* Development environment setup completed (e.g. test/dev environment, production, etc.) -* Access requirements identified, requested and setup completed - -## PoC *Output* Checklist - -### PoC Success Criteria -* Measures of success for PoC have been met and accepted by stakeholders -* Recommendation for Prototype phase developed -* Key personnel resources and skill requirements identified -* Process approach is defined -* Prototype Scope is defined -* High-level *business features* have been identified and prioritized -* High-level *technical features* and requirements have been identified and prioritized - -## Sample Technical Considerations for Next Phase Recommendations - -### Existing Solutions and Systems -* Has it been specified if the solution requested is a feature fix or capability enhancement on an existing platform? -* Has it been determined if the capability will reside in a solution that is GSA-internal or managed by an external vendor -* Specify if it will reside on a current GSA IT platform that is up for contract renegotiation -* Has it been determined if Solution is cloud based, if not, will it need to integrate with an application maintained in Cloud Services or on premise services? - -### Software -* Has solution languages, tools and applications been determined e.g. web, mobile, core SW languages (Java, Python), Open source/public code, etc.? -* Has it been specified if the solution requested is a service or solution IaaS, PaaS or SaaS? - -### Data -* Has the type of data the solution will work with been identified? (e.g. No Data, Structured Data OR/AND Unstructured Data) -* Has the condition of the data been specified (Format - JSON, XML, Excel, CSV, etc. Data size, frequency of capture, current storage)? - -### Security -* Has it been determined if PII or Payment Card Information (e.g. credit card numbers) will be stored in the system? -* Has it been stated if the solution should leverage Single Sign-on (SSO). If yes, have the applicable GSA IT platforms or applications identified? - -### Environment and Integration -* Has the list of other applications the solution requires to interface/integrate with been identified? (e.g. GSA IT platforms, Vendor platforms, etc.) -* Have integration requirements with a third-party application, another system within GSA, and/or a system outside GSA? If yes, have applications been listed? - -### Network -* Specify if the system is assessed through GSA network only or through outside network -* Has required access been identified, requested and setup completed? diff --git a/content/guides/Agile_Meetings_Goals_and_Benefits.md b/content/guides/Agile_Meetings_Goals_and_Benefits.md deleted file mode 100644 index a06f6b16..00000000 --- a/content/guides/Agile_Meetings_Goals_and_Benefits.md +++ /dev/null @@ -1,246 +0,0 @@ ---- -title: Agile Meetings - Goals and Benefits -category: Agile ---- - -## Sprint Planning - -Also see: [Conducting a Sprint Planning](/guides/conducting_sprint_planning) - -### Purpose -To define a realistic Sprint goal and backlog containing all items that could be fully implemented until the end of the Sprint by the Scrum team. The sprint planning meeting results in two Scrum Artifacts, the Sprint goal and Sprint backlog. - -### Who should attend -The Product Owner, Scrum Master and the entire Scrum Team. - -### How it is conducted -* The Product Owner defines the Sprint Goal - a short description of what the sprint will attempt to achieve, clarifies the details on backlog items and their respective acceptance criteria. -* These entries are updated and broken into smaller stories by the team so that they can be completed within one Sprint. -* The stories are estimated, prioritized and tasked. -* The Scrum Team defines their capacity for the upcoming Sprint - the total capacity of the Scrum Team might change from sprint to sprint. In order to provide realistic commitments, it is necessary to know the total capacity of the team for the upcoming Sprint, with consideration of vacations, public holidays, etc. -* Tasks are assigned amongst the team members based on their experience levels and expertise. -* The team is ready to start with the daily sprints. - -### Useful Tips -* Timebox the meeting. Stop when you reach time. -* The Product Owner should have the Product Backlog prioritized and ready before the meeting. Only review stories that are ‘ready,' i.e. meets the Definition of Ready (DoR). -* Review and agree on the acceptance criteria that says when a given work is considered ‘done,' i.e. meets the Definition of Done (DoD). -* The Scrum Team selects how much work they can do in the coming sprint based on their capacity and should not be influenced by the Product Owner. -* The Product Owner should clarify with stakeholders on any unclear requirements for the team. -* Plan for collaboration of team members and NOT for optimal ‘resource utilization.' - -### Benefits -Below are some of the benefits of running a successful Sprint Planning meeting: -* Enables the Team to agree on the sprint goal and commitment. -* Creates the platform to communicate dependencies and identify team capacity to set and commit to an achievable sprint goal. -* Ensures that daily sprints remain productive. - - -## Daily Scrum / Stand-up - -Also see: [Conducting a Daily Scrum / Stand-up](/guides/conducting_daily_standup) - -### Purpose -To provide a platform for a Scrum team to get together and review progress toward their Sprint goal and assess any risks to their Sprint commitment. - -### Who should attend -The Scrum Master and the entire Scrum team, Product Owner (optional), and Outside stakeholders may attend by invitation of the team - -### How it is conducted -* During the daily scrum, each team member answers the following three questions - * What did the team do yesterday? - * What will the team do today? - * Are there any impediments in the way? -* By focusing on what each person accomplished yesterday and will accomplish today, the team gains an understanding of what work has been done and what work remains. - -### Useful Tips -* The daily stand-up should be time-boxed -* Should be held at the same place or location and time every day -* Each member of the team should participate, and own/share responsibility of the full sprint backlog -* The Scrum Master facilitates regular daily meeting times. -* Don't update the sprint backlog during this meeting. -* The goal should be to resolve impediments. -* Ensure that each team member remains present till the end of the meeting. -* Make sure it is understood this meeting is not a status update meeting in which a boss is collecting information about who is on schedule or behind schedule. Rather, it is a meeting in which team members make commitments to each other. - -### Benefits -Below are some of the benefits of running a successful Sprint daily Scrum meeting: -* Enables the team to be in sync on how things are going -* Allows for identification and solution of impediments -* Provides an opportunity for small course corrections within the sprint -* Building trust between team members -* High visibility of progress -* Promotes self-organization in team: team members hold each other accountable for achieving their daily commitments. - - -## Sprint Review (Demo) - -Also see: [Conducting a Sprint Review (Demo)](/guides/conducting_sprint_review) - -### Purpose -To provide the platform for the Scrum Team to showcase what they accomplished during the sprint while creating the opportunity to stakeholders to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements. - -### Who should attend -Product Owner, the Scrum team, the Scrum Master, management/ stakeholders, customers and developers from other projects. - -### How it is conducted -* The Scrum Master makes administrative arrangements for the review -- reserving the conference rooms, arranging for refreshments, getting additional presentation aids (projectors, whiteboards, flip charts, etc.). -* The Product Owner makes sure key business stakeholders are available to attend and confirm and assess the product or product increment. -* The Product Owner provides a demonstration of features completed and reviews the commitments made at the Sprint Planning Meeting, and declares which items are accepted and considered done. -* Product Owner answers questions and gathers feedback from Stakeholders. -* The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. - -### Useful Tips -* Timebox to one hour per week of Sprint length. -* Focus on acceptance criteria that has met the Definition of Done (DoD). -* Prepare and practice before the meeting. -* Center the demo around a realistic user experience and business value (not just proving functionality). - -### Benefits -Below are some of the benefits of running a successful Sprint Review meeting: -* Stakeholder engagement (early and frequent feedback). -* Maximizing Responsiveness to Customers. -* Team building and collaboration. -* Maximizing quality. - - -## Backlog Refinement (Grooming) - -Also see: [Conducting a Backlog Refinement (Grooming)](/guides/conducting_backlog_refinement) - -### Purpose -To review items on the backlog to ensure the backlog contains the appropriate items, that are prioritized, and items that are at the top of the backlog are ready for delivery. - -### Who should attend -Scrum Team, Scrum Master, Product Owner - -### How it is conducted -Occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity. Some of the activities that occur during this refinement of the backlog include: -* Refining and removing user stories that no longer appear relevant. -* Creating new user stories in response to newly discovered needs. -* Re-assessing the relative priority of stories. -* Assigning estimates to stories. -* Correcting estimates in light of newly discovered information. -* Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration/sprint. - -### Useful Tips -* Set a goal for the meeting. -* Treat the backlog refinement meeting just like the first part of the Sprint Planning Meeting. -* Ensure everyone understands that estimates are not final until Sprint backlog items have been accepted into a sprint. -* Consider doing some informal backlog refinement with SMEs before the full team backlog refinement. -* Assign action items for questions and any big risks or unknown items. - -### Benefits -Below are some of the benefits of running a successful Backlog Grooming meeting: -* Helps ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority. -* Enables the Team to ask questions and have requirements cleared before sprint planning. -* Helps the team understand the project or product and its objectives. -* Helps the team break down larger stories into a more manageable, smaller stories, which makes for easier estimating, and saves time during sprint planning session. - -## Sprint Retrospective - -Also see: [Conducting a Sprint Retrospective](/guides/conducting_sprint_retrospective) - -### Purpose -A meeting where the team discusses the just-concluded sprint and determines any changes to improve the next sprint. Looks at the “how” or team delivery process. - -### Who should attend -Scrum Team, Scrum master, Product Owner (optional) and Note: ideally no management. - -### How it is conducted -Retrospective activities try to address three main questions/points through discussion: -* *What went well during the sprint cycle?* -* *What went wrong during the sprint cycle?* -* *What could we do differently to improve?* - -Example Topics include: -* Milestones, dependencies, motivations, misunderstandings, processes, etc. -* Process and way of working -* Focus on continuous improvement -* Look ahead to mitigate possible risks or concerns - -The meeting is facilitated by the Scrum Master. - -### Useful Tips -* Gather information/data based on facts. -* Generate relevant insights - conversations over accusations. Open, honest and constructive. -* Prioritize and decide on actionable commitments, assigned to a team member with a timeline. -* Revisit issues and check-in on status in the future. - -### Benefits -Teams that conduct retrospectives at the end of each sprint (iteration) are able to: -* Reflect on their process and agree upon a way of working. -* Collectively find ways to improve productivity and reach goals. -* Determine and constantly update the Definition of Done. -* Continuously improve and evolve. -* Build the team's sense of ownership and its self-management. - - -## Scrum of Scrums - -Also see: [Conducting a Scrum of Scrums](/guides/conducting_scrum_of_scrums) - -### Purpose -Also known as a Meta-Scrums, the purpose of is to provide the platform for team representatives to share high-level updates on their respective team’s work, identify impediments, and collaborate on help needed from other teams. - -### Who should attend -Teams select a representative, or "ambassador," to attend the session who is able to articulate progress and impediments on their behalf. Depending on the context, ambassadors may be technical contributors, or each team's Scrum Master, or even managers of each team. - -### How it is conducted -* Teams select a representative as "ambassador" to attend the session who is able to articulate progress and impediments on their behalf. -* The "ambassador" participates in a daily meeting with ambassadors from other teams. -* During the meeting, each team representative answers the following three questions: - * *What has your team done since we last met?* - * *What will your team do before we meet again?* - * *Is anything slowing your team down or getting in their way?* - * Are you about to put something in another team’s way?* -* Resolution of impediments focuses on the challenges of coordination between the teams -* Solutions entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc. - -### Useful Tips -* Track Scrum of Scrums items via a backlog of its own, where each item contributes to improving cross-team coordination. -* Change attendees over the course of the project. Allow the team to choose its representative based on who will be in the best position to understand and comment on the issues most likely to arise at that time during a project. -* Allow the team to frequency of the Scrum of Scrums meeting. Similar to a daily scrum, the suggestion is to have this session on a daily basis, if applicable. -* Unlike the daily scrum meeting, if a problem is identified and is prioritized high, it should address in the scrum of scrums. Therefore, while many scrum of scrum meetings will be over in fifteen minutes, it’s recommended to budget more time to address potential problems. - -### Benefits -* Can be used as a technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. -* Allows clusters of teams to discuss their work, focusing especially on areas of overlap and integration. -* Provides a platform to identify situations where teams need to coordinate -* Keeps people connected by making sure that at least one member from each team sees one from every other team once a day. - - -## Release Planning - -Also see: [Conducting a Release Planning](/guides/conducting_release_planning) - -### Purpose -To commit to a plan for delivering an increment of product value that represents the amount of scope that a team intends to deliver by a given deadline. Enables multiple Teams plan development for a product release. - -### Who should attend -The Scrum master, Product owner, Delivery team or agile team, Stakeholders - -### How it is conducted -* The Product owner prepares High-level vision, market, business objectives and a prioritized backlog. -* Scrum master – Facilitates the meeting. -* The Agile Development team – Provide insights into technical feasibility and dependencies, overall capabilities, known velocity, technical impacts, etc. - -### Useful Tips -* Have a “definition of ready” for backlog items to be discussed during release planning. -* Ensure leadership and stakeholders are present and engaged. -* For small teams, make sure the entire cross-functional team is there to participate for both input and accountability purposes. For larger teams and organizations, a subset of the team may be selected or elected to represent the team. -* Establish a common baseline for sizing estimates. -* Logistics: Create an agenda in advance. Consider room size and breakout rooms or online video conferencing is available for distributed teams. -* Plan to limit releases deadlines - typically range between 2 and 12 months. - -### Benefits -Below are some of the benefits of running a successful release Planning meeting: -* Provides the team a common vision about what needs to be achieved, and when. -* Provides the platform for collaboration across multiple teams to identify cross-Team dependencies and sequence of work. -* Guides the team to make informed decisions based on dependency, capacity and available skills. - -## More Resources on Agile Meetings - -* [6 Common Misconceptions and Anti-Patterns of the Sprint Review Meeting](http://www.solutionsiq.com/6-common-misconceptions-and-anti-patterns-of-the-sprint-review-meeting/) -* [Backlog Grooming](https://www.agilealliance.org/glossary/backlog-grooming/) -* [Agile Release Planning Best Practices](http://enterprise-knowledge.com/agile-release-planning-best-practices/) diff --git a/content/guides/Agilevs.Waterfall_Scope_Schedule_and_Cost.md b/content/guides/Agilevs.Waterfall_Scope_Schedule_and_Cost.md deleted file mode 100644 index 19ac7ea1..00000000 --- a/content/guides/Agilevs.Waterfall_Scope_Schedule_and_Cost.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Agile vs. Waterfall- Scope, Schedule and Cost -category: Agile ---- - -## Understanding the Differences - -Agile is a value-based, iterative approach under which business needs and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. -The traditional Waterfall approach is a sequential process of a series of activities or phases that need to be complete before moving forward to start a new phase. The requirements are identified upfront and the customer does not have the opportunity to interact with the product and provide feedback until the final product is delivered. If there is a change to be made after the final product has been delivered, there will be a high-cost associated with it since there was no prior opportunity to course-correct and the changes have to go through the full process again. - -|**Traditional Waterfall Approach** | **Agile Approach** -|---------------|---------------| -| Sequential product development/delivery process where each phase needs to be complete in order| Time boxed and iterative/incremental product development/delivery| -| Requirements and design decisions are made upfront| Product Owners and Development Team have the opportunity to negotiate and re-prioritize requirements throughout the development process| -| Months of planning before development begins| Intermediate milestones: deliver in deployable increments with useful features, it may have minimum viable product functionality| -| Broken into stages that need to be completed before you can go to the next | Complete transparency in development process, each iteration/sprint delivery is done when it is programmed, tested, and so on | -| The customer sees the product for the first time when final product is delivered | Customer is constantly interacting with product and providing feedback | -| Making changes so late in the process can be expensive and time-consuming | Changes are embraced in the iterative process through constant communication and prioritization | -| Only one initial investment to be spread out over the project timeline | Incremental investment process where money is released with phases| - -## Agile Investment Approach - -What is the Agile Investment Approach? - -* **Development Approach:** An Agile, phased approach to prototyping potential solution investments -* **Business-driven:** Identify strong product owners (business-side) with available time commitment -* **Budget:** Stagger release of funding dollars to reduce spend and make more informed decisions - -All pilots begin with an approved Business concept. Once the Product Owner and Scrum Team members are identified, the CTO Office then engages the right resources for Discovery that will lead into the Proof of Concept (PoC) phase and beyond. -* All projects derive from approved Business concepts -* All projects engage the right resources for success -* Not all pilots lead to prototype / scalable solutions - -{{
}} - -Why use an Agile Investment Approach? -* Reduced risk and improved IT investments -* Increased collaboration among IT & Business Owners -* Provide faster solution delivery & increase transparency - -During the Discovery Phase, a goal is set and the team will identify 1-2 high-value use cases that will quickly acknowledge whether the solution chosen is the right one to meet business needs. Right away, every sprint (typically 2-3 weeks) allows stakeholders to see and track progress. - -## Measuring Success - -While a traditional waterfall approach can work well for projects with routine and predictable requirements, an agile approach is a better fit for large cross-functional, complex products because it allows you the flexibility to make changes to requirements as they become available. - -{{
}} - -In the phased investment approach, an agile team learns early what works and what does not, which gives them more knowledge on the product and alternatives. Releasing the funds in increments allows an agile team to better inform investment decision-making and potentially reduce their overall spending. The advantage of the incremental approach is that the team learns early, fails early, and can course-correct while the budget is still intact. - -Often times, in a Waterfall approach, defects are not discovered until the end of the process when testing takes place. Once the errors are exposed, the team has to retrace steps back to the beginning, while the project budget and schedule are both at risk. - -In order to measure success, a product must meet the success criteria determined at the beginning of the project. Typically, the criteria will include meeting all customer requirements and business lines getting to see the product early and making decisions. These decisions are an important part of determining success as they range from the ability to learn early and stop before spending all funds, to if the product plan proves not feasible during the discovery or proof of concept phases. diff --git a/content/guides/Business_and_IT_Collaboration.md b/content/guides/Business_and_IT_Collaboration.md deleted file mode 100644 index 24c021a4..00000000 --- a/content/guides/Business_and_IT_Collaboration.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Business and IT Collaboration -category: Agile ---- - -Technology and software are shaping industries and transforming the way business is done. As organizations evolve, business leaders are increasingly recognizing that continuous learning and responsiveness thrive only on collaboration and business engagement. - -{{
}} - -The [Agile Manifesto](http://agilemanifesto.org/) emphasizes value on customer collaboration, specifically consistent interaction of the customer with the product at every phase of the development lifecycle. When used effectively, Agile frameworks can improve collaboration between leaders, managers, end-users and the development team. True agility enables business processes and engagement throughout the development process, resulting in the production and delivery of successful products that help end-users do their jobs better. - -## What is Effective Collaboration? - -* **Continuous Interaction:** in Agile approaches, the top measure of product success is whether it meets user / customer needs. Regardless of what the development team builds, a product without engaged users is a failure. To this end a common understanding between business leaders and team members is required to ensure the requirements clarification and prioritization process is an ongoing team effort. Effective Agile product development and project management relies on bidirectional communication. Business leaders and technology teams need to interact on a daily basis throughout the project / product development lifecycle. -* **Enabling Environments:** business leaders and technology teams need environments that facilitate communication and create constant feedback loops. This becomes more imperative in cases where team members and key project players are geographically dispersed. The organization will also need to invest in the relevant technology / tools that enable the technology team to effectively communicate and deliver faster to the business needs. -* **Leadership by Engagement:** leadership and senior management support agility and collaboration practices through making the organizational and cultural changes and actively participating in projects to bring business units, IT, and customers together as a team. - -## Collaboration Tools and Techniques - -Supporting an organization’s move towards agility needs technological tools that minimize siloes and drive change in the organization. There are various tools and techniques that can be used to ensure business users are involved throughout the entire project lifecycle. Some noteworthy examples of Agile approaches and tools are highlighted below. - -### Agile Meetings and Activities - -There are a number of regular activities and meetings that take place among Agile Team members and stakeholders that emphasize collaboration and the flexibility to adapt to changing business realities. Each meeting/activity in Agile methodologies has a specific [purpose and multiple benefits](/guides/agile_meetings_goals_and_benefits/). Below are some examples on how customers and business units can ensure engagement within Agile teams: -* Participating in product demonstrations -* Reviewing and providing timely feedback and business decisions, -* Clarifying requirements on ongoing basis -* Ensuring appropriate removal of team impediments. -* Performing user acceptance tests -* Approving changes to requirements, etc. - -### Technology Tools - -Organizations are faced with the challenges to support distributed workers, attract global and mobile talent and connect a worldwide ecosystem of customers and project teams. A wide variety of software products are available for organizations to choose from, inline with their needs and unique organizational culture. To this end, technology resources need to support constant mobility, real-time, quality and reliable collaboration. -Some examples of the top collaboration tools will provide organizations with the ability to: -* Manage requirements and collaborate, real-time on documents/prototyping - example software include ActiveColab, mind mapping software such as FreeMind, Visio, Google Drive, etc. -* Virtual prioritization, tasking, and [visually track status](/guides/visibility_and_status/) in an agile environment - top available tools include JIRA, Rally, VersionOne, Trello, etc. - -## Additional Reads -* [Bring Agile to the Whole Organization - Harvard Business Review](https://hbr.org/2014/11/bring-agile-to-the-whole-organization) -* [Agile-management-and-leadership](http://searchsoftwarequality.techtarget.com/feature/FAQ-Agile-management-and-leadership) -* [Finding Ways to Improve Business – IT Collaboration](https://www.infoq.com/news/2013/06/improve-business-it-cooperation) -* [Developer picks 7 hot tools for agile development](http://searchsoftwarequality.techtarget.com/feature/FAQ-Agile-management-and-leadership) -* [Enhance Collaboration Between Business and the IT Department](http://www.cio.com/article/2445035/collaboration/enhance-collaboration-between-business-and-the-it-department.html) diff --git a/content/guides/Collaboration_Across_Agile_Teams.md b/content/guides/Collaboration_Across_Agile_Teams.md deleted file mode 100644 index 1ad4ebe1..00000000 --- a/content/guides/Collaboration_Across_Agile_Teams.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Collaboration Across Agile Teams -category: Agile ---- - -The [Agile Manifesto](http://agilemanifesto.org/) emphasizes value on on individuals and interactions over processes and tools, specifically encouraging face-to-face communication as the most effective way of conveying information and collaboration between Agile teams. Effective collaboration enables teams develop workable solutions to complex problems. However, in reality, this is constantly challenged with large, distributed teams, forcing communications into different directions. - -## What is Effective Collaboration? - -**Clear objectives and separation of work** each team member should understand. Separation of work between multiple teams also creates independence for teams to minimize duplication of efforts and enables teams to identify and plan for cross-team dependencies. This is best achieved by developing and maintaining a Team product backlog for respective teams to ensure each team is driving solutions towards delivery of the big picture. - -**No departmental silos** creates successful Agile Teams that are cross-functional, with multidisciplinary members with numerous skillsets from across the organization, collaborating together to deliver a given product. Thus, they go beyond the boundaries of traditional departmental gridlines. Part of a successful Agile transformation is to drive the necessary cultural and structural changes to support its teams at the organization level, particularly by eliminating silos. - -**Collaborative architecture and design guidelines** Agile teams are self-organizing, or should be. According [Principle 11](http://agilemanifesto.org/principles.html) of the Agile Manifesto, the best architectures, requirements, and designs emerge from these self-organizing teams. To this end, it is within the responsibility of the larger organization to enable the collaborative environment for its teams for emergent architecture designs while providing guides and architectural standards for the entire organization system that is beyond their scale. A simple, easily implementable, [collaborative architecture](http://www.scaledagileframework.com/agile-architecture/) is enables teams to enhance design, performance, usability and of cross-team implementation synchronization. - -## What tools and techniques facilitate collaboration? - -Given our fast-paced virtual world, collaboration practices and tools should be adapted with large and distributed teams in mind. Tools and approaches tweaked to foster simple and frequent communications for large teams will have lasting benefits enabling a successful collaboration for the organization. Below are examples best practices that help facilitate collaboration between distributed teams.   - -**Cross-Team Daily Stand-ups:** Teams can select a representative to attend this session and provide the platform for teams to share high-level updates on their respective team’s work, identify impediments and collaborate and plan on help needed from other teams. [Scrum of Scrums](https://www.agilealliance.org/glossary/scrum-of-scrums/) is one instance of these meetings used to scale collaboration among large Scrum teams. - -**Multiple Product Owners Check-in:** for large Agile teams that have multiple product lines and Product Owners, a regular check-in enables the Product Owners to discuss scope, acceptance criteria and dependencies to align and prioritize initiatives to create their team’s Product Backlogs. This approach also enables the Product owners to agree on and guide their respective teams to deliver the highest priority tasks for the organization. - -**Cross-Team Release Planning:** holding a quarterly or monthly review and planning session enables teams to define high-level requirements, map cross-team dependencies and help teams understand how all separate team efforts contribute and integrate into the final solution. - -**Cross-Team Retrospectives:** creates the platform for teams to examine and reflect on their collaboration process, identify action items and hold themselves accountable for improvements. For instance, teams can utilize retrospective sessions to develop or update team-working agreements, definition of done and their norms for working together. - -### Technology - -**Visual Boards:** Kanban or Scrum boards help teams collaboratively plan their work together, visualize progress and stay focused on their respective goals. Software applications such as JIRA, Trello, and VersionOne provide the features to foster discussions and collaboration across teams via co-planning, progress tracking and frequent communication. - -**Real-Time Collaboration Tools:** especially important for teams that are not co-located, these involves several kinds of synchronous communication tools that are reliable and easily accessible for teams to interact in real-time. Some examples include the utilization of conference equipments with video capability such as WebEx, GoToMeeting, or AdobeConnect, etc., organizational chat tools which allow groups to have text conversations and collaborate in an effective and efficient manner such as Slack, Google Hangouts, Skype, etc., and document or whiteboarding tools for ideation and brainstorming such as Google Drive, MS Office 365,  etc. - -**Integration Tools:** With multiple teams continuously producing increments and builds into a single product base, end-to-end integration and testing becomes one of the main acceptance requirements. The organization will need to support this process by equipping integration teams with the required applications to automate work and create cadence. Various software tools are available to support these handoffs between teams, applications, infrastructure and operations making the process automated and repeatable. Popular software examples in the industry include DeployBot, Jenkins, Octopus Deploy, etc. - -## Additional Reads -* [Collaboration Techniques for Large Distributed Agile Projects](https://www.thoughtworks.com/insights/blog/collaboration-techniques-large-distributed-agile-projects) -* [IT Applications: 5 Way to Improve Agile Collaboration In IT](https://www.cebglobal.com/blogs/it-applications-5-ways-to-improve-agile-collaboration-in-it/) -* [Agile Architecture](http://www.scaledagileframework.com/agile-architecture/) -* [Agile Technique To Manage Distributed Teams](https://www.scalablepath.com/blog/agile-techniques-to-manage-distributed-teams/) diff --git a/content/guides/How_to_Determine_Projects_Fit_for_Agile.md b/content/guides/How_to_Determine_Projects_Fit_for_Agile.md deleted file mode 100644 index b23751d9..00000000 --- a/content/guides/How_to_Determine_Projects_Fit_for_Agile.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: How to Determine Projects Fit for Agile -category: Agile ---- - -Organizations commonly adopt new processes / approaches that have proven to reach markets faster, realize quicker returns and minimize costs. Agile is a set of values and frameworks geared to shift efforts toward efficiency and continuous value delivery. Although Agile is a relatively new way of thinking, it’s rolling success in delivering more within the challenges of the triple constraints (scope, schedule and budget) has gained it popularity and wider adoption in the project management world. Yes, depending on the scenario, plan-driven, traditional project management or “waterfall” can provide a higher likelihood for projects’ success. - -So, what drives the decision to go with one or the other? What are the factors to consider when selecting the approach that best meets the needs of the organization? - - -## The Nature of a Project/Product - -A good starting place is to examine the three important aspects of a project: Scope, schedule and cost. In order to determine the best approach, consider these factors against the specifics of the project / product in question. Below are sample real-life project scenarios that could be considered during this process. - -| Important Factors | Product/Project Scenario | Methodology | -|-|-|-| -| Requirements (Scope) | There is an idea for a new, complex product and specific requirements will surface through small experiments, based on market/user needs (e.g., starting a new product line or a new marketing campaign). | Agile | -| Requirements (Scope) | The project has a checklist of requirements with predefined stages that must be completed in a predictable sequence. The list must be completed to deliver the final product (e.g., hardware installation or bridge construction project). | Waterfall | -| Time/Schedule | The product/project needs to meet an aggressive tiemline even with limited features or functionality (e.g., showing available product samples at a bazaar or expo). | Agile | -| Time/Schedule | The product requirements and functionalities are fully defined up front, regardless of user needs, uncertainity, and risk. A full set of these requirements are required to be delivered within a set deadline (e.g., implementing a new regulation that becomes effective on a specified date). | Waterfall| -| Cost | While traditional project management is optimized for efficiency and direct project success, Agile frameworks respond to non-traditional success factors such as speed and delivering a product that maximizes business value (even at a higher risk). The spending in Agile can not be measured by minimizing direct project costs, rather, through the cost savings realized through fast delivery of solutions that meet the business needs and succeeding more quickly. Applying the right balance of cost and resources in relation to the above scope, risk, and schedule factors is what will ultimately lead to optimal cost saving. | Unlike the above elements, it may not be reasonable to make an equivalent comparison on the cost factor. When considering cost, it is important to note that one approach is not inherently always cheaper or more expensive than the other. | - -*It is also important to highlight that there are times when Agile approaches can be applied to facilitate transparency and communication at team-levels even when the nature of the project is best suited for waterfall approaches. A good example here would be a construction team that adopts Scrum practices, such as daily stand-ups for their daily check-ins, sprints to break down their work, and Kanban boards to visualize progress and track the work in queue.* - - -## The Project/Product Environment - -Another vital element that can inform or influence approach selection is the project / product delivery environment and life-cycle. Factors to consider here include: - -| Important Factors | Environment Scenario | Methodology | -|-|-|-| -| Customer/User Engagement | Customers and users are able to engage throughout development or will need to provide feedback on an ongoing basis | Agile | -| Customer/User Engagement | The project/product has customers/users that have provided defined requirement steps and are interested in seeing the final product only | Waterfall | -| People & Skills | The proejct team is very familiar with the product/project. For instance, building a new version of an existing product | Waterfall | -| People & Skills | Cross-functional teams (that occupy multi-disciplinary roles) are fully committed to reach quick decisions and complete the project | Agile | -| People & Skills | Individuals wearing multiple hats or using shared resources in the project. Team members are required to meet the ongoing daily needs of the organization. | Waterfall | -| Third Party Engagement (Contracting Model) | Contract engagements are based on fixed scope and fixed budget where requirements are defined upfront | Waterfall | -| Third Party Engagement (Contracting Model) | Frequent delivery of usable capabilities are required from vendor/contractor to accommodate customer feedback | Agile | - -Overall, supporting [data](https://www.infoq.com/articles/standish-chaos-2015) suggests that not all Agile projects succeed and not all “waterfall” projects fail. Organizations can identify the most fitting approach that helps accelerate delivery, minimize risk, save costs, and ultimately present a higher likelihood of success by carefully analyzing the nature of a product or project and having a good strategy that creates the enabling environment. - -Further, if the decision is to transition to an Agile approach, similar to any new process or change initiative, Agile adoption requires a supportive environment that spans beyond a given project / product to an organizational transformation. An Agile implementation must be supported by change management activities that foster buy-in and ensure the Agile vision and goals are clearly communicated across the enterprise. - - -## Additional Reading - -* [Embracing Agile - Harvard Business Review](https://www.infoq.com/articles/standish-chaos-2015) -* [Project Success: Agile vs. Waterfall](https://www.infoq.com/articles/standish-chaos-2015) -* [Change Management for Agile Projects](https://enterprise-knowledge.com/change-management-for-agile-projects/)   - diff --git a/content/guides/Steps_to_Succeed_in_Agile_Delivery.md b/content/guides/Steps_to_Succeed_in_Agile_Delivery.md deleted file mode 100644 index d97c24f8..00000000 --- a/content/guides/Steps_to_Succeed_in_Agile_Delivery.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Steps You Can Take [Today] to Succeed in Agile Delivery -category: Agile ---- - -Organizations in the 21st century face great opportunities and threats presented by fast paced technological advances. According to Forbes Magazine, the most [defining traits of a successful 21st century organization](https://www.forbes.com/sites/gapinternational/2014/09/03/the-six-defining-traits-of-the-successful-21st-century-organization/#f2e3ddf1c600) are **relentless innovation** - requires a new mindset that liberates everyone in the organization to innovate regardless of position or function, and breakthrough **performance environments** that are flexible enough to support rapid movement, speedy decision-making and process alignment to regularly achieve extraordinary outcomes. When long rooted processes start to fail and the need for such lean delivery becomes more evident, *change* becomes a question of *when*, and *how* it can be implemented to realize the desired results with just the right amount of disruption. - -In federal environment, where there are multiple customers being served and where the room for error is minimal - it is imperative to define and communicate the drive behind the change and the direction for a new approach before the organization can embark upon the journey of uprooting and transforming embedded delivery processes. Further, it is vital to find a starting point where the initial activities are not overwhelming for those who are championing the change. - -If you are part of a change initiative and looking to develop your own approach for giving structure to starting such a difficult process of organizational change, below are some of the most effective approaches to get started. - -## Step 1. Demand a Vision for Your Team - -All change leaders and contributors need a relevant purpose for why they should commit the time and effort to make significant changes in the way they work. This vision provides a clear picture for individual contributors to visualize the opportunities created after the change and how their efforts now, will pay-off in the long run. On the contrary, the lack of such purpose, adversely affects the motivation for individual contributors, thus resulting in a high likelihood of abandonment during the transition. To this end, investing in time and resources to define and communicate the vision and strategy behind a change initiative is the most essential factor to secure buy-in and commitment to kick-off and support the initiative to success. - -### Checklist for Developing an Effective Vision Statement - -A change vision differs from overall organizational vision, it provides a clear picture of what the future will look like after the change and contains the following attributes: - -* It’s written in simple language and easy to understand -* Uses pertinent facts to produce an appealing change vision -* Creates a sense of urgency -* Has a shared purpose - contributors understand how they will be able to take advantage of the opportunities that are created by the change - -## Step 2. Start Small - -Experience shows that integrating Agile principles and practices into complex workflow takes time and several iterations. Additionally, if such practices are mandated from the top without being supported by an overarching vision and strategy, individual contributors will have localized perspectives on the best route to reach the goal, resulting in uncoordinated, overlapping initiatives that increase the risk of waste and failure too early in the process. - -The best way to reduce such risk is to “think scale,” while starting small with lean, pilot Agile teams and [development approaches that tailor](https://enterprise-knowledge.com/agile-vs-waterfall-project-management-series-part-3-compromising-to-a-tailored-approach) and break down bigger transformation initiatives into smaller team activities and iteratively build towards a more comprehensive, final process. Starting small creates a safe space for teams to experiment in small batches, inspect and adopt quickly while reflecting on their process decisions to improve. Further, experimenting with smaller Agile teams facilitates organizational learning for scaling by allowing new teams to course correct based on lessons learned from the earlier pilot teams. - -### Agile Teams - Quick Starter Kit - -Lightweight practices to start introducing Agile approaches to your teams - -* Redefine [traditional roles](/guides/traditional-management-skills-and-functions-in-an-agile-organization) to enable your team skills thrive in Agile approaches (e.g. Program Managers use their leadership skills to drive high-level strategies, remove roadblocks, manage stakeholders, etc.) -* Hold 10-15 mins check-ins, daily if possible or 3-2 times a week with your development teams. This is known as the Daily Stand-up or the Daily Scrum -* Plan your work in short iterations, 2-3 weeks in length with specific outcomes in mind. Also known as Sprints -* Meet with your team to review the *outcomes* at the end of each iteration to acquire feedback and build your queue for the next iteration (Sprint Review/demo) -* Meet with your team to review how this *process* is working and how to improve it at the end of each iteration (Sprint retrospective) -* Implement action items and keep repeating this process -* Read [Agile Meetings and Benefits](/guides/agile_meetings_goals_and_benefits) on who should attend this activities, the purpose, agenda, benefits and tips to run them effectively. - -## Step 3. Learn, Improve and Repeat - -Reiterating and applying the [Agile principles](http://agilemanifesto.org/principles.html), specifically setting up intervals to reflect on process, adjust, adopt and improve behavior accordingly, is the key to continuous improvement (or [Kaizen](https://en.wikipedia.org/wiki/Kaizen)). Additionally, regularly revisiting the Agile values and principles with your team, can shed new light in how each aspect of your new process and interactions are giving priority to your new values and how you can continue improving the way you work. Retrospective activities try to address three main questions / points through discussion: - -* *What went well during the sprint cycle?* -* *What went wrong during the sprint cycle?* -* *What could we do differently to improve?* - -Example topics include examining milestones, dependencies, motivations, misunderstandings, etc. around the team’s processes and looking ahead to mitigate possible risks or concerns. This improvement process also facilitates trust and collaboration across and between business and development teams. - -Another way to achieve continuous improvement is to facilitate a learning organization through training and team / personal development. Although becoming Agile cannot be trained nor mandated, individual contributors can enable a supporting environment by evolving their behaviors and practices to support cultural change and the way the organization operates. - -### Most effective Ways to Achieve Continuous Improvement: -Retrospect: - -* Gather information/data based on facts -* Generate relevant insights - conversations over accusations -* Facilitate open, honest and constructive communication -* Prioritize and decide on actionable commitments, assigned to a team member with a timeline -* Revisit issues and check-in on status in the future - -Personal/Team Development: browse these [Agile resource and guides](/guides). diff --git a/content/guides/Traditional-Management-Skills-and-Functions-in-an-Agile-Organization.md b/content/guides/Traditional-Management-Skills-and-Functions-in-an-Agile-Organization.md deleted file mode 100644 index 1f1e292c..00000000 --- a/content/guides/Traditional-Management-Skills-and-Functions-in-an-Agile-Organization.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Traditional Management Skills and Functions in an Agile Organization -category: Agile ---- - -In an Agile organization, where self-organizing teams are the core of the delivery process, the function of managers shifts in such a way that their focus and efforts are geared towards supporting business objectives and values for the transformation. Managers get to highlight and utilize leadership skills such as facilitation, coaching and the support of enabling environments. Below, we explore examples of traditional management roles and the respective skillsets managers can translate to develop and grow an agile organization. - -## Program / Project Management - -In an Agile environment, the primary skillsets and functions required from Program managers shift from monitoring and controlling teams and portfolios to leading product / portfolio vision. - -{{
}} - -**Vision and Direction:** Program Managers use their leadership and communication skills to drive high-level strategies, develop project/product roadmaps and set priorities based on long-term vision and business objectives. The program manager gets to emphasize on their management functions when it comes to effective resource allocation, design and development of working environments, management of risk and dependencies across teams and the removal of impediments. - -**Managing Portfolios and Stakeholders:**Program managers can leverage their portfolio management and governance skillsets to reinforce agile values - create frequent portfolio planning cycles and delivery where goals are set on a rolling basis, and facilitate the environmental ability to make frequent decisions regarding which projects to stop, start, or continue. Additionally, agile managers develop their lean skills such as value stream analysis and minimum viable product development (MVP) to achieve a deeper understanding of customer needs and guide the end-to-end processes based on notion of embracing early and frequent feedback to maximize project value to their internal partners. - -**Project-based Engagements:** Because the project management function is shared and/or distributed across all Agile team members, an agile manager can focus on their expertise in formulating a new process and resource management model that helps teams succeed and scale their efforts towards continued value delivery. For instance, the requirements management function of the project manager shifts to the Product Owner and the task / work assignments will be self-assigned by the self-organizing team. However, the project manager continues to oversee project objectives, milestones, strategy and project governance, project finances, Risk and change management and coordination for the Agile team. - -**Managing Resources and Teams:** Applying management and communications skills provides managers the required tools in assessing team health, removing cultural and resource impediments and having the ability to measure, reward, coach and nurture team growth and development sustainability in the long term. - -## Functional Management - -The skillsets required of Functional Managers in Agile shifts from thinking tactical to strategic. -As part of this shift, functional managers can employ the following important skillsets and play an integral role in Agile environments. - -{{
}} - -**Subject Matter Expertise:** Can serve as Technical or Business Leads who are subject matter experts advising the team and who can translate the business vision into a technical vision. This means focusing on setting a clear vision, defining acceptance criteria and letting the team figure out the ‘how’ by providing guidance and direction when needed, in addition to coaching and transferring knowledge. - -**Resource Management:** Their experience and skillsets developed working with other departments and resource-allocation skills, enables functional managers to support Scrum Masters and the team by responding to resource needs and removing dependencies and impediments. - -**Process Improvement:** In the spirit of continuous improvement, functional and middle managers can utilize their organizing and people management skills to serve as great leaders in bringing individuals and teams together. Functional managers can facilitate the platform for sharing knowledge, developing standards, identifying and resolving impediments, etc. to continuously improve the processes for their teams. Additionally, because of these managers’ proximity to employees and knowledge of core technologies, initiatives instigated by functional and middle managers rather than top managers wins greater employee support. To this end, a bigger emphasis of the skill required of functional managers in Agile shifts from doing to deliver behavioral changes through coaching with individuals or teams. - -## Technical Design Management - -Agile design development shifts the notion of a single person is in charge of design. Instead the responsibility is shared by the entire technical team, whereas the design and development processes are intertwined. - -{{
}} - -**Systems Design:** Architectural designers utilize their technical skills on developing the high-level system design and strategy, while guiding the development team on the architecture design that is to be created during the coding process. - -**Technical Standards and Requirements:**In terms of technical design requirements, architecture and design managers can successfully employ their technical skills and evolve into the role of a technical product owners in order to guide technical excellence and strategy throughout the development process. This position requires a unique skill set where the technical Product Owner carries technical knowledge into strategic conversations about the product to support long-term roadmapping that require an understanding of technical capabilities. - -## Additional Reference -* [Manager 2.0: The Role of the Manager in Scrum](https://www.infoq.com/articles/scrum-management-deemer/) -* [The Role of Functional Managers in Agile: From Tactical to Strategic](https://blog.versionone.com/the-role-of-functional-managers-in-agile-from-tactical-to-strategic/) -* [Middle Managers Matter](http://www.epe.admin.cam.ac.uk/middle-managers-matter) -* [How Agile Led to the Creation of the Technical Product Owner](https://www.techwell.com/techwell-insights/2013/09/how-agile-led-creation-technical-product-owner) diff --git a/content/guides/agile_adoption.md b/content/guides/agile_adoption.md deleted file mode 100644 index 1e7eb9c6..00000000 --- a/content/guides/agile_adoption.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Agile Adoption -category: Agile ---- - -## First, What is Agile? - -**Agile** is considered an alternative approach to traditional project management or product development. It can be summarized as a value-based, iterative approach under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. Success in Agile is based on an attitude of “[servant leadership](https://www.greenleaf.org/what-is-servant-leadership/)” and focuses on the entire team, both Business and IT, not just developers. As teams work to solve large, complex problems, teams must *“be(come)”* Agile and not just *“do”* Agile. - -Though it arose out of software development practices, Agile is **not** just a software-development framework. It is neither methodological nor prescriptive; there is no exact way to become Agile. There are best practices and popular approaches, particularly [Scrum](https://www.scrum.org/). However, Agile is not synonymous with Scrum (or [Kanban](https://leankit.com/learn/kanban/what-is-kanban/), [TDD](https://www.agilealliance.org/glossary/tdd/), etc.) or even a specific tool (i.e. JIRA, Rally, etc.). The overall goal of Agile is to encourage [collaboration](../business_and_it_collaboration/), accountability and ownership across the team, and provide transparency and [visibility](/guides/visibility_and_status/) throughout the process. - -### Agile Values - -{{
}} -**Individuals and interactions** over processes and tools. Agile is more about transparent interactions than technology. - -{{
}} -**Working software** over comprehensive documentation. Create something usable quickly to enable faster customer feedback. - -{{
}} -**Customer collaboration** over contract negotiation. Ensure customer buy-in between Business & IT, with marketable visibility. - -{{
}} -**Responding to change** over following a plan. Leave room for emergent solutions and better respond to change. - -### Agile Principles -While the [Agile Manifesto](http://agilemanifesto.org/) lists the **Agile Principles** in full, they are best summarized as: - -- *Satisfy the customer* -- *Working software is the primary measure of progress* -- *Welcome changing requirements* -- *Promote sustainable development* -- *Deliver working software frequently* -- *Continuous attention to technical excellence* -- *Business people and developers must work together daily* -- *Maximize amount of work not done* -- *Build projects around motivated individuals* -- *Self-organizing teams* -- *Face-to-face conversation* -- *Reflect...and tune* - -### Common Agile Terms -Some common Agile terms include: - -* **Iterations** : duration; often used synonymously with **Sprint**; typically 2 week increments -* **Epics** : refers to a group of features; also a term used in the tool JIRA -* **User Stories** : requirement, or feature; referred to as “Story” in JIRA -* **Vertical Slicing** : “chunks” of related features -* **MVP (or MMP)** : Minimum Viable Product (or Minimum Marketable Product) - -Additional terms can be found in our [**Glossary**](/guides/glossary/). - -## Benefits of an Agile Culture -Many other areas outside of Technology have found success in developing an Agile culture, including [Manufacturing](http://www.fujitsu.com/global/documents/about/resources/publications/fstj/archives/vol43-1/paper16.pdf), [Marketing](http://agilemarketingmanifesto.org/), [Legal](http://www.abajournal.com/legalrebels/article/the_rise_of_the_agile_lawyer/), Customer Support, and more recently, [Learning Design](http://www.bottomlineperformance.com/what-is-agile-learning-design/) and [Human Resources](http://hr-gazette.com/hr-agile-manifesto/). The benefits of an Agile culture provide more customer-focused efforts, increase communication, enable change, improve quality of delivery, provide a more responsive environment, and increase both transparency and visibility. - -The result, or the answer to **“[What’s in it for me?!](https://hbr.org/2016/05/embracing-agile)”** rather - is additional cost-savings and more informed spend; greater visibility with executive leadership; empowered, self-organized teams; work that is broken down into smaller, achievable increments; and shared responsibility between Business and IT. - -In GSA IT, we are currently pursuing Agile adoption through the formation of Scrum pilot teams that support the Agile Investment process. **“[Agile Investment](/guides/agile_investment_overview/)”** is a phased approach to piloting potential solution investments that create a stronger partnership between the Business and IT; thereby increasing collaboration, providing faster solution delivery, increasing transparency, reducing risk, improving overall GSA IT investment spend, and increasing business value. - -## How Do We “Be”-come More Agile? -Agile adoption begins with a top-down approach; it must be fully supported by the entire organization. While it can be challenging, there are [best practices](/guides/agile_adoption_challenges_and_best_practices/) that can serve as a guide throughout transition. As we develop an enterprise-wide strategy, we will continue to focus on project-level implementations through our Agile Investment approach. - -Through Agile Investment, the CTO Office introduces business and development team members to Scrum (and Kanban). We coach pilot teams in developing agile processes, establishing working agreements for delivery, and in creating a supportive infrastructure with tools and standards that can be leveraged enterprise-wide. - -### Agile Behavior Adaptation -Here are just some of the ways we can support Agile adoption: - -**Stop the Jargon!** -Be informed & know the proper terminology to better support Agile adoption and reduce confusion. - -**Shift the Mindset** -Be open, flexible, responsive, & transparent in developing a more Agile mindset, but know that transition takes time and patience. - -**Change Management** -Be flexible as new processes are implemented, but call pain points and issues so that they can be addressed. - -**Communication** -Be a reliable source for & encourage open communication. - -**Accountability** -Be reliable & responsible to the Team and with assigned work. - -**Transparency** -Be honest & transparent with the Team and assigned work. - -And finally, as we learn from each experience, we celebrate and share the success through "storytelling." In GSA IT, our current successes include the OMB endorsement of Agile, the introduction of standards, and each Agile Investment project-level implementation. Moreover, the collaboration we continue to build between Business and IT leads to faster, more efficient product delivery and is a win towards Agile adoption! diff --git a/content/guides/agile_investment_approach.md b/content/guides/agile_investment_approach.md deleted file mode 100644 index 02d0ce0f..00000000 --- a/content/guides/agile_investment_approach.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Taking an Agile Investment Approach -category: Agile ---- - -[Agile Investment](/guides/agile_investment_overview/) is an agile, phased approach to piloting potential solution investments. The piloting process begins with a Business-approved concept. The Business identifies strong Product Owners with the available time commitment to work with the CTO Office in [managing requirements](/guides/managing_requirements/), facilitating a [Scrum Team](/guides/popular_approaches/), and encouraging [Agile adoption](/guides/agile_adoption/) throughout the pilot phases. The release of funding dollars is staggered in order to better inform investment decision-making and reduce IT spend. - -The goal of this approach is to create a stronger partnership between the Business and IT by [increasing collaboration](/guides/business_and_it_collaboration/), providing faster solution delivery, increasing transparency, reducing risk, improving overall GSA IT investment spend, and increasing business value. - -{{
}} - - -## Before we begin... - -The concept... -* Must be vetted and approved by the Business for investment with -* The "Problem," or opportunity, clearly defined with user input - -The potential Proof of Concept (PoC) must have... -* An assigned, dedicated, and committed Product Owner to represent the Business -* With committed Team Members dedicated to the success of the effort and -* Support needs identified and assigned from the CTO Office - - -## What do we need to be successful? - -The core Scrum Team Members must... -* Be committed to the success of the effort -* Prioritize attendance for Scrum Ceremonies -* Enter and update pilot tasks in JIRA -* Encourage strong user engagement for providing feedback and acceptance testing, when applicable. -* Attend introductory session for basic understanding of Agile and the Scrum methodology - - -## Understanding Pilot Team Roles - -Throughout the pilot phases, the Core Implementation Team leverages the Scrum approach to manage requirements and tasks. The roles include: - -{{
}} - -**Scrum Master** serves as facilitator for the Team; enables the Team to self-organize and make changes quickly; manages the agile process for how information is exchanged. The Scrum Master is essentially "The Coach" of the Team. - -**Product Owner** is responsible for communicating product vision; prioritizing the Product Backlog; clarifying requirements; accepting / rejecting each product increment; is empowered to decide whether the product increment is done or "shippable." - -**Scrum Team** is composed of cross-functional Team Members; they negotiate sprint commitments with the Product Owner and set the print goal. Scrum teams have autonomy regarding *how* to reach said commitments; should function in an intensely collaborative fashion; best practice is no more than three to nine members. - -**Stakeholders** include the Project Sponsor (i.e. ACIOs); Business Line Owners; key Business Line groups / customers; participate in Sprint Demos; may also provide User Acceptance Testing (UAT) throughout the pilot process. - - -## Pilot Team Ceremonies - -Throughout the pilot phases, the Team participates in a number of Scrum Ceremonies, including the following: - -* PoC Kickoff -* Standups -* Sprint Planning -* Sprint Demo -* Sprint Retrospective -* Lessons Learned throughout the PoC - -The Scrum Ceremonies are short, focused meetings that revolve around targeted information. The goal is to ensure as little time as possible is taken away from development and business activities. While other commitments may arise, Team Members are expected to prioritize their attendance for these ceremonies. diff --git a/content/guides/agile_investment_discovery_phase_checklist.md b/content/guides/agile_investment_discovery_phase_checklist.md deleted file mode 100644 index 3b3112e1..00000000 --- a/content/guides/agile_investment_discovery_phase_checklist.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Agile Investment - Discovery Phase Checklist -category: Agile ---- - -## During the Discovery Phase - -* Approved 'concept' gains definition -* High-level analysis leveraging concept/problem definition and business case -* Specific user-focused and, possibly, technology-focused problems are defined for exploration -* Strategic direction and platform capabilities, e.g. analysis on strategic direction of IT investment, leveraging existing solutions, etc. -* High-level wireframes, user engagement, interviews, etc. - -## Outputs from the Discovery Phase - -* Problem Statement -* Completed Proof of Concept (PoC) request form - * PoC scope defined - * Approach defined for PoC - * PoC Measures of Success - * High-level features prioritized - * Technical requirements to conduct PoC are identified and acquired, if PoC is to be pursued -* Key personnel resources and skill sets identified and secured - * Committed Team Member & Stakeholder participation - * Product Owner from the Business Team identified and committed - * Assigned Scrum Master - * Agile coaching support and guidance approved -* Users - * Types of users of the new request identified (e.g. Employees only, employees and contractors, partners and public, etc) - * Number of people the request will serve is estimated? - * Type of user roles defined (e.g. One type of user, user and administrators, more than 2 types of users, etc.) -* Data - * Type of data the request will work with identified? (e.g. No Data, Structured Data OR/AND Unstructured Data) - * Condition of the data specified? (e.g. format, data size, frequency of capture, current storage) -* Security - * PII or Payment Card Information secutiry need determined (e.g. credit card numbers) -* Environment and Integration - * Need for integration with other systems identified diff --git a/content/guides/agile_investment_overview.md b/content/guides/agile_investment_overview.md deleted file mode 100644 index af42e498..00000000 --- a/content/guides/agile_investment_overview.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Agile Investment Overview -category: Agile ---- - -## What is Agile Investment? - -* An [Agile](http://agilemanifesto.org/), phased approach to prototyping potential solution investments -* Identify strong product owners (business-side) with available time commitment -* Stagger release of funding dollars - - -## Why an Agile Investment Approach? - -[Learn more about the Agile Investment Approach](/guides/agile_investment_approach/). - -* Reduced risk and improved IT investments -* Increased collaboration among IT & Business Owners -* Provide faster solution delivery & increase transparency - -{{
}} - - -## What is the Agile Investment Process? - -All pilots begin with an approved Business concept. Once the Product Owner and Scrum Team members are identified, the CTO Office then engages the right resources for [Discovery](/guides/agile_investment_discovery_phase_checklist/) that will lead into the [Proof of Concept (PoC)](/guides/agile_investment_proof-of-concept_phase_checklist/) phase and beyond. - -* All projects derive from approved Business concepts -* All projects engage the right resources for success -* Not all pilots lead to prototype / scalable solutions - -{{
}} - - -## What is the role for GSA organizations? - -To work together collaboratively in solution delivery! The GSA Office of the CTO is available to provide Agile coaching and development resources through Digital Services and an Agile BPA, as needed. Get in touch and work with us! - -{{
}} diff --git a/content/guides/agile_team_working_agreement.md b/content/guides/agile_team_working_agreement.md deleted file mode 100644 index 2ae31f01..00000000 --- a/content/guides/agile_team_working_agreement.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Establishing an Agile Team Working Agreement -category: Agile ---- - -## Forming an Agile Team - -When forming a new Agile team, particularly one implementing a Scrum or Kanban approach, we know that it will take some time to develop their optimal productivity flow. In Tuckman’s [stages of group development](https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development), a team must adapt through several phases as they “find their groove:” - -{{
}} - -In the **Forming** phase of an Agile Team, they must set the foundation for building trust, facilitating open communication, and defining their working disciplines that will guide self-organization throughout additional phases. These working disciplines, or “ground rules,” are the Team’s agreement as to how they will interact with one another and plan, set, and achieve common goals. - - -## Defining Team Disciplines - -The purpose of the **working agreement** is to ensure the Agile Team shares responsibility in defining expectations for how they will function together and enhance their self-organization process. It creates an awareness of both positive (and negative) behaviors that can impact the Team and empowers the Scrum Master to keep them accountable. - -The process of defining the Team’s working agreement is straightforward. The Scrum Master facilitates a session with the Agile Team and Product Owner, where they generate a number of team disciplines together. A working agreement should be recalled easily, so they will then vote on the top five to ten disciplines. Once the Team has agreed upon a set of disciplines, they should be posted in their designated area and/or stored in a virtual folder that is accessible to all members. - - -## Examples of Team Disciplines - -Here are some examples of Agile Team disciplines included in a working agreement: - -{{
}} - - -Other examples: - -* ALL changes to the Sprint / Backlog must be approved by the Product Owner -* Use the Impediment Backlog (or swimlane) for blocked issues -* Define and adhere to ‘DONE’ criteria for stories -* Define and adhere to Version Control rules -* Adhere to code documentation standards -* Update Backlog before Standup daily -* Respect your team member’s time - - -## Maintaining Team Disciplines - -Success of the working agreement is based on the Team’s commitment to their established disciplines, so it is essential that they are agreed upon by the *entire* Agile Team. As they continue through the stages of group development, the Team will begin to hold themselves and each other accountable. - -The working agreement should be reviewed periodically, especially when the Team experiences change (i.e. new member joins or leaves the Team) or a member breaks one of the ground rules. [Retrospective meetings](/guides/agile_meetings_goals_and_benefits/#sprint-retrospective) can provide a vehicle for regular review, so as the Team reflects on their processes, they can also identify lacking or problematic disciplines in their working agreement. If team members find that a specific discipline is consistently broken, they should examine whether it is a reasonable expectation or whether it should be removed due to influences or variables outside the team’s control (e.g. team members are not 100% dedicated so they are unable to consistently meet their ‘DONE’ criteria for stories). - - -## Good Reads - -These are good references for understanding Agile Team Working Agreements: -* [Agile Team Working Agreements How To Guide](https://web.archive.org/web/20191208130941/https://payton-consulting.com/agile-team-working-agreements-guide/) -* [Creating a Team Working Agreement](https://web.archive.org/web/20200802085143/http://www.gettingagile.com/2008/05/02/creating-a-team-working-agreement/) -* [Forming, Storming, Norming, and Performing: Understanding the Stages of Team Formation](https://www.mindtools.com/pages/article/newLDR_86.htm) -* [Team ground rules and working agreements](https://web.archive.org/web/20181208070736/https://nomad8.com/team-ground-rules/) -* [What is a team ground rule or team working agreement](https://agilefaq.wordpress.com/2007/11/21/what-is-a-team-ground-rule-or-team-working-agreement/) diff --git a/content/guides/applying_agile_practices.md b/content/guides/applying_agile_practices.md deleted file mode 100644 index 1154f9ee..00000000 --- a/content/guides/applying_agile_practices.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: Applying Agile Practices to Business Teams -category: Agile ---- - -## If Not Software Development, Then “Who…?” - -Agile practices have proliferated into business lines such as [Marketing, Human Resources, Legal](/guides/agile_adoption/#benefits-of-an-agile-culture), and beyond. Agile can not only transform an organization’s approach to software development, but also its enterprise departmental functions, project management practices, and product development. Moreover, in order to survive an ever-changing environment, creating more innovative, cross-functional, and multidisciplinary teams that generate growth and increased skillsets has become paramount - across the _**entire**_ organization. Taking an Agile approach can boost self-organization and employee engagement among business teams while breaking organizational silos that present barriers to communication and collaboration. - -As self-organization and skillsets grow, barriers are broken down, collaboration increases, and a business team’s agility matures. As Rigby, et al. state in Embracing Agile, “as an organization progresses in Agile adoption, they must extend beyond the vocabulary and create a supportive environment that embolden the “[conditions for Agile](https://hbr.org/2016/05/embracing-agile).” The favorable conditions for Agile - based on the *market environment, customer involvement, innovation type, modularity of work, and impact of interim mistakes* - extend beyond developing software. While they affect many development functions, the authors also note these conditions apply to “marketing projects, strategic-planning activities, supply-chain challenges, and resource allocation decisions.” - - -## Adapting Agile Behavior - -The key to broadening Agile adoption is the adaption of new mindsets and behaviors of the individuals that make up the business team. It begins with creating visibility and transparency of work, systems-based or otherwise. Over time, mindsets change as individuals continue to adapt more Agile behaviors, such as: - -* Breaking down project work, or initiative-based tasks, into iterations (i.e. sprints), -* Creating a backlog of prioritized projects and tasks, -* Setting and working in iterations, or sprints, with agreed goals, -* Creating a “working board” of projects and tasks, (which can be supported by a tool), -* Scheduling daily 15-minute check-ins (instead of holding lengthy staff meetings), and -* Focusing on velocity / capacity, versus speed. - -First, Agile behaviors are not beholden to any one framework (i.e. Scrum, Kanban, etc.) and can conceivably be implemented without one. These behaviors simply help establish a more transparent, collaborative Agile environment, even beyond software development. - -Second, Agile behaviors not only accommodate visibility of the business team’s work, but allow for better prioritization and breakdown of project work and tasks. They also support the setting and achievement of short, targeted goals and increase collaboration among team members. Finally, Agile behavior encourages communication of progress within and outside the team, without adding lengthy meetings that take away from prioritized work. - - -## Creating a Responsive Environment - -In addition to changing the mindsets and behaviors of the business teams, the organization itself must also adapt. As Agile adoption progresses, the organization must champion a supportive environment that enables its individuals to better respond to change and shifts the measurement of success and business value to meeting customer needs. According to the [Agile Alliance](https://www.agilealliance.org/agile101/), **Agile is “the ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”** That responsiveness is matured over time through the incorporation of customer-focused, cost-effective Agile practices. - -Like software development, an organization’s business departments, project management offices, and product development also face complex problems - often with many unknowns or changing requirements that can only be addressed as more information becomes available. By breaking efforts down, partnering with end users / customers to obtain rapid feedback, and eliminating silos through cross-functional collaboration, these groups can leverage an Agile approach in order to face challenges in a more responsive manner. Organizations can support the agility of these groups through encouraging the adaption of Agile behaviors and by creating a responsive environment. - -For more information on how specific domains are applying Agile practices to their business, check out the following: - -* [Applying Agile Practices - Agile Human Resources (HR)](/guides/applying_agile_practices_hr/) -* [Applying Agile Practices - Agile Legal](/guides/applying_agile_practices_legal/) -* [Applying Agile Practices - Agile Marketing](/guides/applying_agile_practices_marketing/) - - -## Good Reads - -These are good references for understanding the application of Agile practices to Business Teams: - -* [6 agile principles that apply to everything](http://www.cio.com/article/2971822/agile-development/6-agile-principles-that-apply-to-everything.html) -* [7 aspects of Agile HR](https://hrtrendinstitute.com/2015/02/14/7-aspects-of-agile-hr/) -* [Agile Alliance: Agile 101](https://www.agilealliance.org/agile101/) -* [Agile HR: Transforming a Human Resources Team Using Scrum](http://www.slideshare.net/seedbox/hr-programspublic?next_slideshow=1) -* [Agile Marketing Manifesto](http://agilemarketingmanifesto.org/) -* [Agile Marketing Manifesto Explained](http://theagilemarketer.net/agile-marketing-manifesto-explained/) -* [Bring Agile to the Whole Organization](https://hbr.org/2014/11/bring-agile-to-the-whole-organization) -* [Building the Agile Enterprise](http://www.slideshare.net/jbersin/impact-2012-keynote-josh-bersin) -* [Embracing Agile](https://hbr.org/2016/05/embracing-agile) -* [How NPR benefits from agile project development & you can too](http://www.poynter.org/2012/how-npr-benefits-from-agile-project-development-you-can-too/175487/) -* [How to apply Agile practices with your non-tech team or business](http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/) -* [Organisational agility: How business can survive and thrive in turbulent times](https://www.cfoinnovation.com/organisational-agility-how-business-can-survive-and-thrive-turbulent-times) -* [Scaling Agile at Spotify](https://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/) -* [The Dawn of the Agile Attorney](http://www.lawpracticetoday.org/article/dawn-agile-attorney/) -* [What is Agile HR? And is it right for you?](http://www.hrsg.ca/what-is-agile-hr-and-is-it-right-for-you/) diff --git a/content/guides/applying_agile_practices_HR.md b/content/guides/applying_agile_practices_HR.md deleted file mode 100644 index baf8fdb8..00000000 --- a/content/guides/applying_agile_practices_HR.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Applying Agile Practices - Agile Human Resources (HR) -category: Agile ---- - -Human Resources (HR) also manages complex projects and serves multiple stakeholders, often times with competing priorities that require consistent, effective strategies in their approach to communication, programs, administration, and talent management. Since 2012, “**[Agile HR](http://www.bersin.com/Lexicon/details.aspx?id=15373)**” (Deloitte) has emerged as a popular discipline with the goal of empowering HR professionals to better “manage volatility, enhance adaptability, and strengthen the organization by applying Agile methodologies to their talent-management processes.” - -According to the [HR Trend Institute](https://hrtrendinstitute.com/), “Agile HR” refers to: - -* a way of working and organizing of the HR function that facilitates responsiveness and adaptiveness of activities and structures, -* facilitating the flexibility in matching workforce fluctuations to demand, and -* the way the HR function supports the organization in becoming more responsive and adaptive. - -With Agile HR, the traditional focus on control and alignment has shifted to a more Agile focus on speed of responsiveness and customers. - -{{
}} - -Human Resources is no longer limited to just implementing controls and standards to drive execution, but rather to facilitate programs and strategies that improve organizational agility, innovation, collaboration, and enhance decision-making. [HRSG](http://www.hrsg.ca/what-is-agile-hr-and-is-it-right-for-you/) provides a few examples of how traditional approaches to HR must shift when using an Agile approach: - -| Traditional Approach | Agile HR Approach | -|-|-| -| Underperforming employee in a current role, or needs to prepare for a new role, is assigned training to achieve a specific performance level. | Employees are given a myriad of opportunities to learn and stretch themselves independent of a specific, job-related goal. | -| As jobs become available, the search for candidates begins. Once the best candidate is identified, the talent acquisition process is complete. | Organizations invest in their employer brand and cultivate ongoing relationships with talent across multiple channels, including social. | -| Talent management is *owned* by HR, and the process by which talent is acquired, evaluated, and developed are proprietary and inaccessible. | Talent management is facilitated by HR, which empowers employees to take ownership of their own development. Employees understand and are active participants in talent acquisition, evaluation, and development processes. | -| Jobs are discrete elements in a complex system. Job requirements are related to specific workplace tasks. | All jobs directly support the mission and values of the organization, and all employees understand how their on-the-job performance supports these elements of the organizational culture. | -| Large-scale systems are carefully researched, resourced, and deployed over the course of many months or even years. | Small-scale initiatives are piloted within a specific team, job family, or business unit. Feedback is gathered early and often to determine whether the initiative should be expanded or scrapped. | -| The HR function is focused on record-keeping and defensibility. Employee files and records of HR activities and outcomes track progress and note issues. HR success is measured in the completeness of documentation. | The HR function is focused on engaging employees to enhance self-motivation and encourage collaboration. HR success is measured in terms of retention, employee satisfaction levels, innovation levels, and organization goodwill and trust. | - -*Source: HR Trend Institute* - - -## Good Reads - -These are good references for understanding Agile practices used in Human Resources (HR): - -* [6 agile principles that apply to everything](http://www.cio.com/article/2971822/agile-development/6-agile-principles-that-apply-to-everything.html) -* [Agile Alliance: Agile 101](https://www.agilealliance.org/agile101/) -* [Embracing Agile](https://hbr.org/2016/05/embracing-agile) -* [How to apply Agile practices with your non-tech team or business](http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/) -* [Organisational agility: How business can survive and thrive in turbulent times](https://www.cfoinnovation.com/organisational-agility-how-business-can-survive-and-thrive-turbulent-times) -* [7 aspects of Agile HR](https://hrtrendinstitute.com/2015/02/14/7-aspects-of-agile-hr/) -* [Agile HR: Transforming a Human Resources Team Using Scrum](http://www.slideshare.net/seedbox/hr-programspublic?next_slideshow=1) -* [Agile Model of HR, Bersin by Deloitte](https://www.linkedin.com/pulse/agile-model-hr-bersin-deloitte-laurence-romeo) -* [What is Agile HR? And is it right for you?](http://www.hrsg.ca/what-is-agile-hr-and-is-it-right-for-you/) diff --git a/content/guides/applying_agile_practices_legal.md b/content/guides/applying_agile_practices_legal.md deleted file mode 100644 index afe510e5..00000000 --- a/content/guides/applying_agile_practices_legal.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Applying Agile Practices - Agile Legal -category: Agile ---- - -In his article, *[Lean Legal: Three Techniques for the Agile Lawyer](https://files.clio.com/marketo/ebooks/lean-legal-three-techniques-for-the-agile-lawyer.pdf)*, John Grant states that a growing number of attorneys and Legal teams are using Agile methods (Scrum, Kanban, etc.) to manage litigation projects and support transactional practices in immigration, business formation, and family law. - -While many lawyers struggle with the idea of incorporating traditional project management within legal matters due to the amount of up-front planning, Agile practices make Legal project management easier by breaking the project down and enabling rapid delivery of value to the customer. John Grant; a lawyer, Agile Legal consultant, and creator of [The Agile Attorney Network](http://agileattorney.net/#front-page-3); has identified three techniques attorneys can implement to become more Agile: - -* Technique #1: Make Your Work (and Your Workflow) Visible -* Technique #2: Trade in Tasks for Stories -* Technique #3: Be Retrospective - -| Technique | Agile Legal Example | -|-|-| -| Make Your Work (and Your Workflow) Visible | Create a "working board" (i.e., task wall or kanban board) to ensure visibility (To Do; Doing; Done). Additional columns can be added to represent key workflow phases/dependencies (Prospects, Waiting on Client, Waiting on Third Party, To Do, Doing, Delegated, Holding Pattern, Filed, Done). | -| Trade in Tasks for Stories | Write a "User Story" to describe the problem that needs to be solved: "As a \_\_\_\_, I need to be able to \_\_\_\_, so that I can \_\_\_\_." In short, it is a snapshot of the customer need and explains the reason behind that need. Example: "As a person whose marriage is failing, I need to be able to dissolve my legal ties to my spouse, so that I can get on with my life." | -| Be Retrospective | The Retrospective is about the process for doing the work. It typically follows a three question format: What went well that we should keep doing? What didn't go well that we should stop doing? What should we try that is different? By conducting a periodic retrospective, you and your team can capitalize on your strengths and reduce your shortcomings. | - -*Source: The Agile Attorney & Sound Immigration* - -Using an Agile Legal approach makes work visible, encourages collaboration, enables responsiveness, supports consistency of communication, and can even create a competitive advantage with clients that “speak Agile.” - -### Good Reads - -These are good references for understanding Agile practices used in Legal: - -* [6 agile principles that apply to everything](http://www.cio.com/article/2971822/agile-development/6-agile-principles-that-apply-to-everything.html) -* [Agile Alliance: Agile 101](https://www.agilealliance.org/agile101/) -* [Embracing Agile](https://hbr.org/2016/05/embracing-agile) -* [How to apply Agile practices with your non-tech team or business](http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/) -* [Organisational agility: How business can survive and thrive in turbulent times](https://www.cfoinnovation.com/organisational-agility-how-business-can-survive-and-thrive-turbulent-times) -* [How lawyers can use Agile project management and kanban](https://www.soundimmigration.com/agile/) -* [Lean Legal: Three Techniques for the Agile Lawyer](https://files.clio.com/marketo/ebooks/lean-legal-three-techniques-for-the-agile-lawyer.pdf) -* [The Dawn of the Agile Attorney](http://www.lawpracticetoday.org/article/dawn-agile-attorney/) -* [Using the Kanban System to Become a More Agile Attorney](https://www.rocketmatter.com/news/using-the-kanban-system-to-become-a-more-agile-attorney/) diff --git a/content/guides/applying_agile_practices_marketing.md b/content/guides/applying_agile_practices_marketing.md deleted file mode 100644 index 4f8b8eaa..00000000 --- a/content/guides/applying_agile_practices_marketing.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Applying Agile Practices - Agile Marketing -category: Agile ---- - -Like software development, Marketing efforts must balance a customer-focused approach along with the ability to respond quickly, continuously improve, provide shorter delivery timeframes, capture feedback, “fail fast” and learn from mistakes early. In an effort to address this need, many marketers began experimenting with Lean and Agile practices. Through the success of these endeavors, a group of marketers compiled what is now the [Agile Marketing Manifesto](http://agilemarketingmanifesto.org/). The Agile Marketing Manifesto is composed of seven core values, which are elaborated by ten principles, and encourages marketers to focus on creating value for their customers while discovering new approaches to marketing operations. The Agile Marketing Manifesto values include: - -* Validated learning over opinions and conventions -* Customer-focused collaboration over silos and hierarchy -* Adaptive and iterative campaigns over Big-Bang campaigns -* The process of customer discovery over static prediction -* Flexible versus rigid planning -* Responding to change over following a plan -* Many small experiments over a few large bets - -As the [Agile Marketer](http://theagilemarketer.net/agile-marketing-manifesto-explained/) explains, there are many traditional approaches used in marketing campaigns and efforts that should be modified to avoid potential delays and/or adverse impacts. As marketers examine current practices, taking a more Agile approach can help them overcome such challenges. For example: - -| AMM Value | Traditional Approach | Agile Marketing Approach | -|-|-|-| -| Validated learning over opinions and conventions | Often suffer "death by best practices" (i.e., too much focus on how others have done something while ignoring the opportunity to do it better). | Start with the conventional design, but try to validate it through experimentation. Strive for lessons backed by data. | -| Customer-focused collaboration over silos and hierarchy | Silos facilitate "knowledge hoarding" (i.e., what one group or individual learns doesn't get shared with others). | Remove silos and ensure collaboration distributes knowledge freely. | -| Adaptive and iterative campaigns over Big-Bang campaigns | Plan "big bang" campaigns that take way too long. | Use adaptive campaigns that require fewer resources to complete, shorter timeframes, and audience interaction that evolves based on changing circumstances. | -| The process of customer discovery over static prediction | Static prediction of customer needs. | Ongoing discovery of our customers. | -| Flexible versus rigid planning | Married to a plan and sticks to it in the face of overwhelmingly negative evidence. | Plan with a little bit of "give" built in so if circumstances change, new data comes in, or the market changes, the plan can adapt. | -| Responding to change over following a plan | Once the plan steps are locked in, they are followed no matter what. | Respond to change as it happens rather than blindly follow a plan. Learn from your mistakes. | -| Many small experiments over a few large bets | Large bets can result in "big wins" - or they can blow up in your face. | Focus on small projects over large campaigns. Small experiments: can be completed and released faster, leading to a more rapid iteration cycle; require fewer resources, therefore less risky; conduct enough small experiments to make a "big bet" with confidence. | - -*Source: The Agile Marketer* - -### Good Reads - -These are good references for understanding Agile practices used in Marketing: - -* [6 agile principles that apply to everything](http://www.cio.com/article/2971822/agile-development/6-agile-principles-that-apply-to-everything.html) -* [Agile Alliance: Agile 101](https://www.agilealliance.org/agile101/) -* [Embracing Agile](https://hbr.org/2016/05/embracing-agile) -* [How to apply Agile practices with your non-tech team or business](http://www.techrepublic.com/article/how-to-apply-agile-practices-with-your-non-tech-team-or-business/) -* [Organisational agility: How business can survive and thrive in turbulent times](https://www.cfoinnovation.com/organisational-agility-how-business-can-survive-and-thrive-turbulent-times) -* [Agile Marketing Manifesto](http://agilemarketingmanifesto.org/) -* [Agile Marketing Manifesto Explained](http://theagilemarketer.net/agile-marketing-manifesto-explained/) diff --git a/content/guides/building_devsecops_culture.md b/content/guides/building_devsecops_culture.md deleted file mode 100644 index 362d4b9a..00000000 --- a/content/guides/building_devsecops_culture.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Building a DevSecOps Culture - from a Technical Perspective -category: DevSecOps ---- - -GSA IT continues to cultivate its own DevSecOps strategy. Originally we began with **DevOps** - which differs from other well-known lean approaches, like Agile, in that it focuses on improving *delivery outcomes* versus the *process of delivery*. Granted, even if the engaged software development team is *not* practicing an Agile approach, DevOps can still be successfully implemented in any environment. Further, it promotes a more cohesive collaboration between Development and Operations teams as they work towards continuous integration and delivery. - -{{
}} - -*Example* - -* *Developers develop the code and this source code is managed by **Version Control System** tools like Git, etc.* -* *Developers send this code to the Git **repository** and any changes made in the code is committed to this Repository.* -* *Jenkins **pulls this code** from the repository using the Git plugin and build it using tools like Ant or Maven.* -* ***Configuration management tools** like puppet deploys & provisions testing environment and then Jenkins **releases this code on the test environment** on which testing is done using tools like Selenium.* -* *Once the code is tested, Jenkins **sends it for deployment on the production server** (even production server is provisioned & maintained by tools like puppet).* -* *After deployment it is **continuously monitored** by tools like Nagios.* -* *Docker containers provides **testing environment** to test the build features.* - - -## Utilizing DevOps - -[DevOps](/guides/what_is_devops/) is a composition of enhanced “engineering” practices that reduce lead time and increase the frequency of delivery. The primary goal of DevOps is to ensure Operations team members are engaged and collaborating with Development from the very beginning of a project / product development. As [Edureka!](https://www.edureka.co/blog/interview-questions/top-devops-interview-questions-2016/) states, *“Gartner believes that rather than being a market per se, DevOps is a philosophy, a cultural shift that merges operations with development and demands a linked toolchain of technologies to facilitate collaborative change.”* It requires pushing past departmental lines for more effective planning, design, and release of projects / products. - -{{
}} - -Moreover, as we continue to build upon automated delivery, we find there are opportunities to test for issues beyond typical bugs - potential security flaws, design defects, and code weaknesses. Imagine being able to identify and and fix flaws earlier in delivery process, **before** they are exposed to the public. - - -## DevOps + Security = DevSecOps - -To this end, there’s a growing movement, called [DevSecOps](http://www.devsecops.org/), to incorporate Security into the coding process. Its primary focus is to ensure loopholes and weaknesses are exposed early on through monitoring and analytics, so that remediation actions can be implemented efficiently. - -{{
}} - -Checkmarx quotes DevOps advocate Shannon Lietz, *“The purpose and intent of DevSecOps, is to build on the mindset that ‘everyone is responsible for security’ with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.”* - -In GSA IT, we are actively pursuing a **DevSecOps** model that will not only engage Security throughout the development and operations processes, but more specifically, ensure their involvement as we align the Authority to Operate (ATO) / Lightweight Authority to Operate (LATO) process with the cloud delivery process. - - -### Automation - -Automation is an imperative in any DevSecOps environment, at least where it makes sense. A strong DevSecOps environment should employ tools that automate the following: -* Version Control System -* Continuous Integration -* Continuous Testing -* Configuration Management & Deployment -* Continuous Monitoring -* Containerization -* Orchestration - - -### GSA IT-Approved Tools - -GSA IT currently uses the following approved tools to support DevSecOps delivery: - -| Build (Plan) | Build (Code) | Test (CI) | Deploy (CD) | Operations (Security & Monitoring) | -|-|-|-|-|-| -| JIRA, Slack, Trello | Ansible, GitHub, Jenkins | Jenkins, Selenium, CircleCI | Ansible, Jenkins, Terraform, CloudFormation | AMI, ClamAV, CloudWatch, Nessus, OSSEC | - - -## Measuring DevSecOps Success - -When utilizing DevSecOps practices, success is often measured by the efficiency of continuous development, threat detection, and release cycles. Metrics include: - -* deployment frequency -* lead time -* detection of threats, security defects, and flaws -* mean time to repair -* and mean time to recovery. - -Delivery efficiency is gained through [Continuous Integration](/guides/glossary/#continuous-integration-ci) and [Continuous Delivery](/guides/glossary/#continuous-delivery-cd) activities that encourage and support frequent code check-in, version control, sensible test automation, continuous low-risk releases and feedback. Security issue detection gains are achieved through “[threat modeling, code reviews, and red teaming](https://techbeacon.com/3-most-crucial-security-behaviors-devsecops).” Over time, Jez Humble says these metrics lead to “[the top five predictors of IT performance](https://newrelic.com/blog/best-practices/devops-jez-humble):” - -* Peer-reviewed change approval process -* Version control everything -* Proactive monitoring -* High-trust organizational culture -* A win-win relationship between dev and ops - - -## Benefits of a DevSecOps Environment - -DevSecOps provides a number of benefits between Development, Security, and Operations - it eliminates silos, promotes collaboration and teamwork, identifies vulnerabilities early, and provides better, faster delivery. However, be wary of creating a departmental silo from Business team members. The Business can provide valuable support by engaging DevSecOps team members upfront and ensuring Development team members’ time is accounted for and visible. - -DevSecOps also contributes business value through dollars and resources saved, improved operations, diminished security threats, reduction of re-work and increased quality through automated testing, as well as the delivery of projects / products early and often with less cycle time to the customer. As [Edureka!](https://www.edureka.co/blog/interview-questions/top-devops-interview-questions-2016/) further notes, the benefits of a DevOps (or DevSecOps) environment include: - - -### Technical Benefits: - -* Continuous software delivery -* Less complex problems to fix -* Faster resolution of problems - - -### Business Benefits: - -* Faster delivery of features -* More stable operating environments -* More time available to add value (rather than fix/maintain) - - -## Good Reads - -These are good references for understanding DevSecOps culture and tools: - -* [5 Popular Devops tools every devops should know about](http://www.actoncloud.com/blog/devops-tools/) -* [9 Open Source DevOps Tools We Love](https://devops.com/9-open-source-devops-tools-love/) -* [10 Deep DevOps Thoughts From Chef’s Jez Humble](https://newrelic.com/blog/best-practices/devops-jez-humble/) -* [Agile Vs. DevOps: 10 Ways They're Different](http://www.informationweek.com/devops/agile-vs-devops-10-ways-theyre-different/d/d-id/1326121) -* [Beyond agile: Reorganizing IT for faster software delivery](http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/beyond-agile-reorganizing-it-for-faster-software-delivery) -* [DevOps.com](https://devops.com/) -* [DevSecOps Manifesto](http://www.devsecops.org/) -* [Continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) -* [How are DevOps and Agile different?](https://www.quora.com/How-are-DevOps-and-Agile-different) -* [How are Lean, Agile, and Devops related to each other?](http://www.agileweboperations.com/lean-agile-devops-related) -* [Principles of DevSecOps](http://www.devsecops.org/blog/2015/2/21/principles-of-devsecops) -* [ShiwaForce: What is DevOps?](https://www.shiwaforce.com/mi-az-devops/) -* [The 3 most crucial security behaviors in DevSecOps](https://techbeacon.com/3-most-crucial-security-behaviors-devsecops) -* [The Agile Admin: What is DevOps?](https://theagileadmin.com/what-is-devops/) -* [The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3/ref=dp_kinw_strp_1) -* [Top DevOps Interview Questions You Must Prepare For in 2017](https://www.edureka.co/blog/interview-questions/top-devops-interview-questions-2016/) -* [Top DevOps Tools: 50 Reliable, Secure, and Proven Tools for All Your DevOps Needs](https://stackify.com/top-devops-tools/) diff --git a/content/guides/cloud-gov-pages.md b/content/guides/cloud-gov-pages.md deleted file mode 100644 index 2d0599c5..00000000 --- a/content/guides/cloud-gov-pages.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: cloud.gov Pages -category: Development ---- - -cloud.gov Pages is a static website hosting platform built by 18F. It supports the following types of websites: - -* Jekyll -* Hugo -* Static HTML files diff --git a/content/guides/cloud.gov.md b/content/guides/cloud.gov.md deleted file mode 100644 index 0af70f43..00000000 --- a/content/guides/cloud.gov.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Cloud.gov -category: Development ---- -[Cloud.gov](https://cloud.gov/) is a platform-as-a-service (PaaS) provided by [Technology Transformation Services](https://tts.gsa.gov/). It is designed for use by federal agencies. The Office of the CTO is targeting cloud.gov as our primary hosting platform. - -As a GSA user, you automatically have access to cloud.gov and the GSA `sandbox-gsa` organization, where you can experiment with test deployments. The best place to get started is the cloud.gov docs. Whenever the documentation refers to an "organization" or "org", you can use `sandbox-gsa`. You also have a personal sandbox space named after your email address. For instance, if your email address is harry.truman@gsa.gov, then your space name is `harry.truman`. - -Since cloud.gov is built with [Cloud Foundry](http://cloudfoundry.org/), the Cloud Foundry [documentation](http://docs.cloudfoundry.org/) is also an useful resource. \ No newline at end of file diff --git a/content/guides/conducting_agile_project_kickoff.md b/content/guides/conducting_agile_project_kickoff.md deleted file mode 100644 index b02f248b..00000000 --- a/content/guides/conducting_agile_project_kickoff.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Conducting an Agile Project Kick-off & Sprint 0 Session -category: Agile ---- - -A common misconception about Agile projects is that they lack planning and documentation when conversely, planning in Agile projects occurs continuously throughout each sprint. Additionally, when kicking off a new Agile project, it too requires preparation and supporting documentation for sign-off. Any information that will ensure all team members, subject matter experts (SMEs), key stakeholders, and sponsors are on the same page in terms of the goals to be achieved and the criteria by which success will be measured - should be incorporated. Moreover, to ensure a successful start to the Agile project, a well-prepared kick-off meeting is a must. - - -## Agile Project Kick-off Agenda - -The Agile Project Kick-off agenda should convey the high-level project overview and overarching strategy, project vision and scope, team roles and responsibilities, as well as the Agile approach and supporting ceremonies to be used. At the end of the kick-off meeting, the team should have an action plan for next steps. - -_If **any** of the team members, SMEs, key stakeholders, and sponsors are unfamiliar with Agile or the approach, time should be allotted for a light introduction and plans made to provide formalized (group) training of team members at a later date._ - -The following information should be covered during the Agile Project Kick-off: - -| Agenda Item | Content | Goal | -|-|-|-| -| **Project Overview** |
  • Goals / Introduction to Effort
  • Project Vision / Scope
  • Deliverables
  • Success Criteria
  • Assumptions
  • Expectations
  • Risks
  • Design / Architectural Review
  • Test Environment
  • Technical / Business Dependencies
  • Sponsor
  • Key Stakeholders
  • Escalation Points
| Discuss a high-level project summary and requirements of the effort. Include any supporting documentation. *(e.g. Agile project charter, mindmap, architectural / design, etc.)* -| **Team Roles** |
  • Product Owner
  • Scrum Master
  • Team Members
| Introduce the team, their roles and responsibilities, and provide the chain of communication. *(i.e. requirements and changes flow through the Product Owner)* -| *Introduction of Approach* | *
  • Agile Values & Principles
  • Scrum Values, Roles, & Ceremonies
  • DevSecOps (Technical Efforts)
* | *Light introduction to Agile values and principles and the approach the Team will use. (i.e. Scrum, Kanban, DevSecOps, etc.)* -| **Scrum Ceremonies** |
  • Daily Standup
  • Sprint Planning
  • Sprint Grooming
  • Sprint Review (Demo)
  • Sprint Retrospective
| Introduce the supporting ceremonies and how they will be used to reinforce communication throughout the effort. *(i.e. reiterate to the audience the need for prioritization and attendance)* -| **Team Norms** |
  • Working Board (JIRA)
  • Folders / Confluence Site
| Ensure all parties have access to the working board and supporting resources of information. -| **Next Steps** |
  • Action Plan
| Determine sprint start date for the team. Schedule Sprint 0 session. Identify any items that require follow-up. - - -## Sprint 0 Session - -Further, as either an extension of the Agile Project Kick-off, or as a scheduled separate meeting to kick off the team’s effort, the Sprint 0 session should focus on the needs of the Team. Other attendees can be relieved or the Scrum Master can schedule the separate session with the Product Owner and team members. The following information should be covered during the Sprint 0 Session: - -| Agenda Item | Content | Goal | -|-|-|-| -| **Scrum Ceremonies** | Identify Schedule
  • Daily Standup
  • Sprint Planning
  • Sprint Grooming
  • Sprint Review (Demo)
  • Sprint Retrospective
| Re-cap and discuss the schedule for the team’s ceremonies. -| **Team Norms** |
  • Working Board (JIRA)
  • Folders / Confluence Site
  • Definition of Ready
  • Definition of Done
| Discuss how the working board is organized and how supporting resources will be used. Establish the team norms for the flow of information / story cards. *(e.g. working board status columns, what defines ready-to-work and ready-to-test story cards, etc.)* -| **Story Cards** |
  • User Story Writing
  • Estimation & Story Pointing
| Discuss the needs for writing story cards and what is required for “ready” status. Walk the team through process of estimating and pointing story cards. *(e.g. Description, Acceptance Criteria, Story Points, etc.)* - - -## Good Reads - -These are good references for conducting an Agile Project Kick-off & Sprint 0 Session: - -* [8 Agenda Items for a Successful Project Kickoff Meeting](http://projectnewstoday.com/agenda-project-kickoff-meeting/) -* [How to Get Your Agile Development Projects Off to the Best Start Possible](https://www.koombea.com/blog/agile-development/) -* [Kickoff meetings in waterfall and agile methodologies](https://www.linkedin.com/pulse/kickoff-meetings-waterfall-agile-methodologies-mohammed-ajaz-pmp) -* [The Agile Project Kick-off Kit](http://www.boost.co.nz/blog/2017/03/project-kick-off-kit) -* [Scrum Kickoff Planner](http://weisbart.com/wp-content/uploads/woocommerce_uploads/2017/03/ScrumKickoff-1_0.pdf) - -### Agile Misconceptions - -* [7 Common Misconceptions About Agile](https://dzone.com/articles/what-is-agile-and-some-common-misconception-about) -* [ReQtest: 10 Common Misconceptions About Agile Project Management](http://reqtest.com/agile-blog/10-common-misconceptions-about-agile-project-management/) -* [QAT: 10 Common Misconceptions about Agile Software Development](http://www.qat.com/10-misconceptions-agile-software-development/) -* [The top 10 myths about agile development](http://www.computerweekly.com/opinion/The-top-10-myths-about-agile-development) -* [Top 5 Misconceptions with regard to Agile Methodology](https://www.simplilearn.com/agile-methodology-5-misconceptions-article) diff --git a/content/guides/conducting_an_agile_project.md b/content/guides/conducting_an_agile_project.md deleted file mode 100644 index 77e36170..00000000 --- a/content/guides/conducting_an_agile_project.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Conducting an Agile Project -category: Agile ---- - -If a project has been reviewed and [deemed fit for Agile development](/guides/how_to_determine_projects_fit_for_agile), these are the steps to consider when starting an Agile project at GSA: - -| Steps | Helpful Links | -|-|-| -|Review the Agile methodology and various frameworks || -|Conduct Agile IT Investment & Technical Sprint Framework Reviews with Product Owner, Key Stakeholders, and Subject Matter Experts (SMEs)|| -|Prepare for Project Kick-off & Conduct Sprint 0 Planning Session with the (Core) Development Team, Product Owner, and Scrum Master || -|Set up a “working board” to document user stories, sprint tasks, and the Team members responsible (and assess Team burndown). _

GSA IT Recommended Tools to document user stories & sprint tasks:

  • JIRA
  • Trello
  • GitHub / API
_ Conduct Daily Scrum Meetings for 10 - 15 minutes with the (Core) Development Team, Product Owner, and Scrum Master| | -|Engage end users throughout the effort via follow-up, scheduled discussions, or user acceptance testing || -|Deliver useable increment at the end of Sprint 0 and review progress to garner feedback from Key Stakeholders

Feedback should be reviewed & prioritized by the Product Owner for incorporation into future sprint(s)

| | -|Conduct a Sprint Retrospective with (Core) Development Team and Scrum Master

Product Owner, Management, and / or Key Stakeholder attendance are at the discretion of the (Core) Development Team

| | -|Continue consistent sprint planning and activities until project is complete. || diff --git a/content/guides/conducting_backlog_refinement.md b/content/guides/conducting_backlog_refinement.md deleted file mode 100644 index 116841e7..00000000 --- a/content/guides/conducting_backlog_refinement.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Conducting a Backlog Refinement (Grooming) -category: Agile ---- - -During **Backlog Refinement (Grooming)** the Scrum Master facilitates as the Product Owner and Scrum Team review the user stories at the top of the [Product Backlog](/guides/glossary/#backlog) in order to prepare for the upcoming sprint. - -Backlog Refinement (Grooming) provides the first input to [Sprint Planning](/guides/conducting_sprint_planning/). To start, it assures the Product Owner properly conveys the project / product objectives to the Scrum Team that will inform the sprint goal. Further, it ensures the Product Backlog remains populated with user stories that are relevant and detailed. Finally, it defines the “feature set” for the next [Sprint Backlog](/guides/glossary/#sprint-backlog); user stories that are appropriately refined, estimated, prioritized, and meet the [Definition of Ready (DoR)](/guides/glossary/#definition-of-ready). - - -## Create and Refine - -In preparation of the Backlog Refinement (Grooming), the Product Owner should remove user stories that are no longer relevant and create new ones based on the Scrum Team’s discoveries from the previous sprint. Grooming can then begin with the goal of refining the set of user stories the Product Owner has initially prioritized at the top of the Product Backlog. - -The Scrum Team should ask questions and clarify any requirements so they can better break down larger user stories into more manageable, smaller ones for easier, more accurate story point estimation. This may also lead to the Product Owner and Scrum Team re-assessing and negotiating the relative priority of the user stories as the Team refines them. - - -## Estimate - -Once the Scrum Team has refined the feature set, they should begin assigning estimates to the user stories and correcting those for any existing in light of newly discovered information. However, everyone (i.e. the Scrum Team, Product Owner, and Scrum Master) should understand that estimates are **not final** until those user stories have been accepted into the Sprint Backlog. - - -## Prioritize - -Before the Backlog Refinement (Grooming), the Product Owner should conduct some informal backlog refinement with their subject matter experts (SMEs) and stakeholders to affirm they are focusing on the user stories with the _most important business value_. Thus further ensuring the Product Backlog is prepped with the highest priority user stories for Backlog Refinement (Grooming). - -Following the user story refinement and estimation, the Scrum Team and Product Owner should begin prioritizing the user stories that will eventually fill the Sprint Backlog. The Scrum Team should provide feedback that will help determine the best order for accomplishing the sprint goal. However, if during Backlog Refinement (Grooming) additional questions or risks arise, the Scrum Team should assign action items to the Product Owner (or other Team members) to clarify. Additionally, the Scrum Team and Product Owner may negotiate the creation of “[spikes](/guides/glossary/#spike)” (a time-boxed investigation) to resolve unknowns that hamper user story estimation. - - -## Good Reads - -These are good references for conducting a Backlog Refinement (Grooming): - -* [Agile Alliance: Backlog Grooming](https://www.agilealliance.org/glossary/backlog-grooming/) -* [Cheat Sheet for Product Backlog Refinement (Grooming)](https://www.leadingagile.com/2013/11/cheat-sheet-backlog-refinement/) -* [MountainGoat: Product Backlog Refinement (Grooming)](https://www.mountaingoatsoftware.com/blog/product-backlog-refinement-grooming) -* [Product Backlog Refinement in Scrum](https://www.knowledgehut.com/blog/agile-management/product-backlog-refinement-scrum) -* [Scrum Inc.: Product Backlog Refinement](https://www.scruminc.com/product-backlog-refinement/) -* [Scrum.org: Product Backlog Refinement explained (1/3)](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-13) -* [Scrum.org: Product Backlog Refinement explained (2/3)](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-23) -* [Scrum.org: Product Backlog Refinement explained (3/3)](https://www.scrum.org/resources/blog/product-backlog-refinement-explained-33) diff --git a/content/guides/conducting_daily_standup.md b/content/guides/conducting_daily_standup.md deleted file mode 100644 index e5987f6f..00000000 --- a/content/guides/conducting_daily_standup.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Conducting a Daily Scrum / Stand-up -category: Agile ---- - -The **Daily Scrum / Stand-up** allows the Scrum Team to highlight what they are working on and any impediments to progress. It provides the opportunity for rapid communication and decision-making; ensuring issues don’t "fall through the cracks" and eliminating the need for lengthy status meetings that may drag on. - -While the Scrum Master may facilitate the Daily Scrum / Stand-up, it is the Scrum Team who conducts the session, “inspecting and adapting” as they work to achieve the sprint goal. The Product Owner and management may attend, but only as “silent observers” - available to provide clarification on user stories or to assume responsibility for impediments that need escalation. - - -## Daily Scrum / Stand-up Best Practices - -The Daily Scrum / Stand-up gets it name from the huddle-like appearance of a rugby scrum. Similarly, Scrum Team members “huddle” in-person, or virtually, around their working board or electronic tool (i.e. JIRA, Trello, GitHub, etc.). Team members are encouraged to stand in order to keep the meeting timeboxed to *no more* than 15 minutes. Any member can start the Daily Scrum / Stand-up as the Team should be prompt (i.e. no need to wait for stragglers) and respectful of each other’s time. **Only** individuals working directly on the effort should participate. The Scrum Team should communicate their updates using the following three questions: - -* What did you do yesterday? -* What are you doing today? -* Do you have any blockers / impediments? - - -## Fostering Communication - -While the Daily Scrum / Stand-up should never be the sole means of communication, it is an effective ceremony for promoting team collaboration. When the ability to have face-to-face conversation is impeded, Stand-ups can also be conducted via collaboration tools, with some even offering “Stand-up bots” that remind the Scrum Team to add their updates (e.g. Slack). Remember, the Daily Scrum / Stand-up is **not** a status meeting. The goal is for the Scrum Team to *quickly* communicate progress, unearth obstacles, and make needs for assistance or additional work known - not belabor issues or introduce new topics. If necessary, follow-up discussions can scheduled with the appropriate parties by the Scrum Master or Product Owner. - - -## Good Reads - -These are good references for conducting a Daily Scrum / Stand-up: - -* [5 Scrum Meeting Best Practices: Master the Daily Stand-Up](https://sprint.ly/blog/scrum-meeting-best-practices/) -* [7 Big Mistakes during Agile Stand Up meetings](https://www.linkedin.com/pulse/7-big-mistakes-during-agile-stand-up-meetings-nima-ghahremani-pmp) -* [Agile Alliance: Daily Meeting](https://www.agilealliance.org/glossary/daily-meeting/) -* [Effective Scrum](https://www.slideshare.net/SndorZoltaSzkelySipo/effective-scrum) -* [It's Not Just Standing Up: Patterns for Daily Standup Meetings](https://martinfowler.com/articles/itsNotJustStandingUp.html) -* [What’s the role of the Product Owner at the Daily Scrum?](https://medium.com/serious-scrum/whats-the-role-of-the-product-owner-at-the-daily-scrum-64e3ab693e3a) -* [Top 10 Best Practices for Productive Stand Ups](https://www.solstice.com/blog/top-10-best-practices-for-productive-stand-ups) -* [What is a Daily Scrum?](https://www.scrum.org/resources/what-is-a-daily-scrum) -* [Why the Three Questions in the Daily Scrum Meeting?](https://www.scruminc.com/why-three-questions-in-daily-scrum/) diff --git a/content/guides/conducting_release_planning.md b/content/guides/conducting_release_planning.md deleted file mode 100644 index 71339fc9..00000000 --- a/content/guides/conducting_release_planning.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Conducting a Release Planning -category: Agile ---- - -During **Release Planning**, the Scrum Master facilitates as the Product Owner, Delivery Team (_Core Agile Team, Network, Security, Operations, etc._), and Stakeholders collaborate and commit to a plan for delivering a product increment by a given deadline. The Product Owner presents the product vision, business objectives, and prioritized backlog while the Delivery Team provides valuable insights into the technical feasibility, known velocity, and dependencies. - -Release Planning presents the opportunity for the Delivery Team, Product Owner, and Stakeholders to reach a common goal about what needs to be achieved (_scope_) and when (_date_), based on the available resources (_budget_). It creates a platform for cross-functional collaboration; thus enabling participants to identify cross-team dependencies that inform decision-making in line with capacity and available skillsets regarding the sequence of work. - - -## Preparing for Release Planning - -When preparing for Release Planning, consider the logistics of the **entire** Delivery Team; ensure the room size and / or breakout rooms can accommodate the complete number of participants as well as schedule online video conferencing for distributed team members. More specifically with distributed team members, be considerate when coordinating across time zones and working hours. Employ supplemental forms of communication (e.g. Slack) and ensure team members have access to any tools, applications, or files that will allow them to fully participate and have a voice in the session. - -Further, create an agenda in advance to help ensure team members are prepared for the conversation and it can remain on the intended release(s). Leadership and (key) Stakeholders should plan to be present and engaged, focusing on minimizing dependencies that might impact the Team’s progress. For smaller teams, the complete cross-functional Delivery Team should attend for both input and accountability purposes. However, for larger teams, a subset of team members may be elected to represent the Team for release planning. - -As the Delivery Team plans the release(s), they should use the established “[Definition of Ready (DoR)](/guides/glossary/#definition-of-ready)” and baseline for sizing estimates of Backlog items (this is typically defined by the Agile Team prior to the start of development). This is the gauge by which user stories can be planned for assignment to various sprints and to limit sizes of the various release deadlines, which usually range between (2 - 12) months. - - -## Good Reads - -These are good references for conducting a Release Planning: - -* [Agile Development Release Planning](https://www.versionone.com/agile-101/agile-management-practices/agile-development-release-planning/) -* [CA Technologies: Release Planning](https://help.rallydev.com/release-planning) -* [Quickscrum: Release Planning](https://www.quickscrum.com/Help/185/sg-Release-Planning) -* [Scrum and Release Planning](http://www.leanagiletraining.com/release-planning/scrum-and-release-planning/) -* [Scrum Release Planning](http://www.scrum-institute.org/Release_Planning.php) -* [The Product Roadmap and the Release Plan](http://www.romanpichler.com/blog/product-roadmap-vs-release-plan/) -* [Tips for Release Planning with Distributed Scrum](https://www.infoq.com/news/2010/10/distributed-scrum-planning) -* [XP: Release Planning](http://www.extremeprogramming.org/rules/planninggame.html) diff --git a/content/guides/conducting_scrum_of_scrums.md b/content/guides/conducting_scrum_of_scrums.md deleted file mode 100644 index aa61f4a2..00000000 --- a/content/guides/conducting_scrum_of_scrums.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Conducting a Scrum of Scrums -category: Agile ---- - -A **Scrum of Scrums**, or Meta-Scrum, may be used in environments that have multiple Scrum Teams. The purpose of the Scrum of Scrums is to provide a platform for cross-team collaboration and planning, highlighting dependencies, and addressing points of integration or conflict. - -The Scrum of Scrums is a time-boxed session in which a representative from each Team shares high-level updates on their respective team’s work and articulates their progress and impediments. Ideally, it should follow the various teams’ Daily Stand-ups, so that the latest information is communicated. - -While Daily Scrum meetings are used for [quick updates](/guides/conducting_daily_standup/), _**not**_ problem-solving, the Scrum of Scrums is not bound by the same rule. If a problem is identified in the Scrum of Scrums and all parties needed to make a decision are in attendance, the issue can be addressed at that time (just be sure scheduling permits). - - -## Conducting a Meta-Scrum - -Team Representatives attending the Scrum of Scrums may be technical contributors, and / or the Team’s Scrum Master or Product Owner. Teams should also alternate their representatives over the course of the project. Often times the Scrum Master will attend **with** an alternating team member to ensure they are not only able to represent the Team, but are also better able to resolve issues that come up during the session. - -During the Scrum of Scrums, each Team Representative answers the following questions: - -* What has your Team done since we last met? -* What will your Team do before we meet again? -* Is anything slowing your Team down or getting in their way? -* Are you about to put something in another Team’s way? - -While it may be suggested to have the session on a daily basis, the frequency of the Meta-Scrum should be determined by the Teams and scheduled as it will add the most value (i.e. daily, 2x per week, etc.). - - -## Benefits of a Meta-Scrum - -The Scrum of Scrums is also an approach to scale Scrum up to larger groups (typically over a 12+ people), where the groups will be divided into Agile Teams of 5 - 10 members. While the various individual Teams are able to focus on their work, the Meta-Scrum also ensures cross-coordination and communication. - - -## Cross-Team Standups - -Cross-Teams Stand-ups are also used in scaled Agile approaches. While often confused with Scrum of Scrums (Meta-Scrums), Cross-Team Stand-ups differ in that instead of (one) representative attending the cross-functional stand-up from each Team, **all** team members from each Team participate. - - -## Good Reads - -These are good references for conducting a Scrum of Scrums: - -* [5 Must-Have Agenda Items in a Scrum of Scrum Meeting](http://aits.org/agile/2016/03/5-must-have-agenda-items-in-a-scrum-of-scrum-meeting/) -* [Advice on Conducting the Scrum of Scrums Meeting](https://www.mountaingoatsoftware.com/articles/advice-on-conducting-the-scrum-of-scrums-meeting) -* [AgileAlliance: Scrum of Scrums](https://www.agilealliance.org/glossary/scrum-of-scrums/) -* [Daily Standup and Scrum of Scrums - what should be the order of meetings?](https://www.scrum.org/forum/scrum-forum/5723/daily-standup-and-scrum-scrums-what-should-be-order-meetings) -* [Making A Cross-Team Standup Work](https://medium.com/@devemail17/making-a-cross-team-standup-work-69237ebf8789) -* [Scrum in practice: the Scrum of Scrums meeting](https://manifesto.co.uk/scrum-of-scrums-meeting/) -* [Using Scrum of Scrums with Agile Teams to Coordinate and Collaborate](https://www.infoq.com/news/2014/03/scrum-of-scrums) diff --git a/content/guides/conducting_sprint_planning.md b/content/guides/conducting_sprint_planning.md deleted file mode 100644 index 9a5cc08c..00000000 --- a/content/guides/conducting_sprint_planning.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Conducting a Sprint Planning -category: Agile ---- - -During **Sprint Planning**, the Product Owner and Scrum Team discuss the [sprint goal](/guides/glossary/#sprint-goal) and agree to the amount of work to achieve it. The Product Owner describes what needs to be achieved during the sprint while the Scrum Team assesses and provides feedback on the prioritized user stories in question from the Product Backlog. - -The agreed-upon user stories are estimated based on the level of effort (from development to testing), then prioritized and tasked by the Scrum Team for the Sprint Backlog. If needed, the Product Owner provides additional clarification regarding the stories and their respective acceptance criteria. The Team then assumes responsibility for the work based on their experience levels and expertise. - - -## Considerations - -In order to finalize the sprint goal, there are several inputs that should be considered regarding the amount of work selected for a sprint. The Team should communicate their availability, as it may change sprint to sprint based on vacations, public holidays, and other responsibilities. Additionally, time should also be allotted for Scrum ceremonies as they reduce the Team’s capacity. Any constraints to the project or environment, dependencies, or the Team’s capabilities (i.e. technical skillsets) should also be considered as they directly impact estimates and overall velocity. - -Once the Product Owner and Scrum Team select the user stories for the Sprint Backlog, the next highest priority items should be ready in the Product Backlog - either for the next sprint planning session or in the event the team has bandwidth to bring it in. - - -## “Scope Creep” vs Adding Work - -In the Scrum process, “scope creep” occurs when the Product Owner, or any other Scrum Team member, brings additional work (e.g. “gold-plating” or sneaking in Technical Debt) into the sprint without discussing it with the Team. The **_entire_** Team should always negotiate taking a user story out of the Product Backlog and bringing it into the current Sprint Backlog. However, if the Team has finished all of the work they committed to in the current sprint, and there is no way a developer can assist another or tester, they can raise the issue at the next daily stand-up and request to bring in new work. - -_If this continually happens, the Scrum Team may need to review their [estimation and story pointing](/guides/estimation_and_storypointing) process._ - -Sprint Planning ensures the Product Owner and Scrum Team collaborate and negotiate the work for the sprint - not just aim for optimal “resource utilization” - as it creates a platform to communicate dependencies, identify the Team’s capacity, and further ensures daily productivity. - - -## Good Reads - -These are good references for conducting a Sprint Planning: - -* [Agile 101: Effective Sprint planning meetings](http://www.continuousautomation.com/agile-101-effective-sprint-planning-sessions/) -* [Confused about modifying the sprint backlog during a sprint](https://softwareengineering.stackexchange.com/questions/149871/confused-about-modifying-the-sprint-backlog-during-a-sprint) -* [How To Do Effective Capacity Planning on The Scrum Team](http://www.agilebuddha.com/agile/how-to-do-effective-capacity-planning-on-the-scrum-team/) -* [How to Run a Sprint Planning Meeting (the Way I Like It)](https://nomad8.com/how-to-run-a-sprint-planning-meeting-the-way-i-like-it/) -* [Should We Or Shouldn’t We – Accept Requirement Changes Within A Sprint?](https://www.izenbridge.com/blog/accept-requirement-changes-within-a-sprint/) -* [Sprint Planning Meeting](https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-planning-meeting) -* [Three Options When the Boss Changes Priorities Mid-Sprint](http://itsadeliverything.com/three-options-when-the-boss-changes-priorities-mid-sprint) -* [Understanding the Agile Release and Sprint Planning Process](https://www.slideshare.net/johnaderrico/app-16195057) diff --git a/content/guides/conducting_sprint_retrospective.md b/content/guides/conducting_sprint_retrospective.md deleted file mode 100644 index a7d5eb02..00000000 --- a/content/guides/conducting_sprint_retrospective.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Conducting a Sprint Retrospective -category: Agile ---- - -During a **Sprint Retrospective**, the Scrum Master facilitates an hour-long session as the Scrum Team reviews their previous sprint’s activities and processes (e.g. milestones, dependencies, etc.) in an effort to continuously improve and address potential risks or concerns for the upcoming iteration. - -The Sprint Retrospective is not intended to be a gripe session, but an opportunity for the Scrum Team to “**inspect and adapt**” their work with open, honest, and constructive feedback. This is why *all* other invitees - including the Product Owner and / or management - should **only** attend the retrospective at the discretion of the Scrum Team. - - -## Inspect - -The Scrum Team should gather information / data based on facts (i.e. impersonal, impartial) and use the retrospective to generate relevant insights (i.e. ideas, actionable commitments, etc). While the Scrum Master may use a variety of exercises or phrasing, the overall goal is for the Team to explore: - -* What went well during the sprint cycle? -* What went wrong during the sprint cycle? -* What could we do differently to improve? - -Or focus on the processes or behaviors that the Team should: - -* Stop _(cease)_ -* Start _(add)_ -* Continue _(emphasize)_ - -... in order to continuously improve. Following a respectful, introspective discussion (i.e. “conversations over accusations”), the Scrum Team prioritizes and determines the idea or action item(s), within the Team’s control, to be implemented. The item should be assigned to a team member with a specific timeline to accomplish (ideally in the upcoming sprint). During future retrospectives, the Scrum Team should revisit the remaining items and check-in on the status of those in progress. - - -## Adapt - -Remember, the retrospective is an opportunity to continuously improve and evolve. The Scrum Team should reflect on their process and agree upon a way of working, collectively find ways to improve productivity and reach goals, and determine / review the Definition of Done so they can continue building upon the Team's sense of ownership and its self-management. - - -## Good Reads - -These are good references for conducting a Sprint Retrospective: - -* [5 Steps To Better Agile Retrospectives](https://blog.trello.com/the-5-steps-to-better-team-retrospectives) -* [A Simple Way to Run a Sprint Retrospective](https://www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective) -* [Atlassian Playbook: Retrospectives](https://www.atlassian.com/team-playbook/plays/retrospective) -* [Do’s and Don’ts: How to Conduct Effective Retrospectives](https://www.inloox.com/company/blog/articles/do-s-and-don-ts-how-to-conduct-effective-retrospectives/) -* [Effective Sprint Retrospectives](https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/jj620912(v=vs.120)?redirectedfrom=MSDN) -* [Key Elements of a Successful Agile Retrospective: Preparation and Participation](https://www.infoq.com/news/2009/09/key-elements-agile-retrospective/) -* [Scrum Inc: Sprint Retrospective](https://www.scruminc.com/sprint-retrospective/) -* [Sprint Retrospective](https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-retrospective) -* [The Product Owner in a Sprint Retrospective](https://www.mountaingoatsoftware.com/blog/the-product-owner-in-a-sprint-retropsective) -* [Valuable Agile Retrospectives: How to Do Them?](https://blog.versionone.com/valuable-agile-retrospectives-how-to-do-them/) -* [Why Agile Teams Need to Know How to Inspect and Adapt](https://www.agileconnection.com/article/why-agile-teams-need-know-how-inspect-and-adapt) diff --git a/content/guides/conducting_sprint_review.md b/content/guides/conducting_sprint_review.md deleted file mode 100644 index 10d86e9a..00000000 --- a/content/guides/conducting_sprint_review.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Conducting a Sprint Review (Demo) -category: Agile ---- - -A **Sprint Review (Demo)** provides the platform for the Scrum Team to showcase what they accomplished during the sprint while creating the opportunity for key stakeholders to [inspect the increment and adapt the Product Backlog](https://www.scrum.org/resources/what-is-a-sprint-review), if necessary. - -The Sprint Review (Demo) is **not** a status meeting - it is an opportunity to elicit feedback and foster [collaboration](https://www.scrum.org/resources/what-is-a-sprint-review) between the Product Owner, Scrum Team, and stakeholders and identify the next incremental effort that can be done to optimize business value. It is recommended the meeting be timeboxed to **_one hour per week of Sprint length_** (i.e. two week sprint is a maximum 2-hour Sprint Review) and to focus on acceptance criteria that meets the team’s [Definition of Done (DoD)](/guides/glossary/#definition-of-done). If a demonstration of functionality is required, it should center around a realistic user experience that displays the product / prototype and how the user will interact with its features, not the system source code or logic. - - -## Preparing a Sprint Review (Demo) Presentation - -The best way for the Product Owner to summarize which items are accepted and considered "done," demonstrate features completed, and review the team’s commitments, is to use a presentation-style format. Sprint Review presentations can be stored in an accessible team folder and provide a convenient, informative summation for stakeholders who are unable to attend the review. The Product Owner, or team member presenting, should always prepare and practice before the meeting. While the Scrum Master should ensure the reviews for the upcoming few sprints are scheduled ahead of time to enable stakeholders to plan their attendance. - -[Download this Sample Sprint Review Presentation](/assets/cms/files/SampleSprintReviewPresentation.pptx) - - -## Good Reads - -These are good references for conducting a Sprint Review (Demo): - -* [6 Common Misconceptions and Anti-Patterns of the Sprint Review Meeting](https://www.solutionsiq.com/learning/blog-post/6-common-misconceptions-and-anti-patterns-of-the-sprint-review-meeting/) -* [It’s a Sprint Review Not a Sprint Demo!](http://www.innolution.com/blog/its-a-sprint-review-not-a-sprint-demo) -* [Sprint Review](https://www.scruminc.com/sprint-review/) -* [Sprint Review Meeting](https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting) -* [Stop Calling Your Sprint Review a Demo—Words Matter!](http://aits.org/agile/2015/02/stop-calling-your-sprint-review-a-demo-words-matter/) -* [What is a Sprint Review?](https://www.scrum.org/resources/what-is-a-sprint-review) diff --git a/content/guides/database.md b/content/guides/database.md deleted file mode 100644 index d22ffb50..00000000 --- a/content/guides/database.md +++ /dev/null @@ -1,297 +0,0 @@ ---- -layout: single-toc -title: Database Transformation Playbook -description: This playbook is designed to help you transform your database technology and overcome any obstacles on the way. -category: Database -aliases: - - /playbooks/database/ ---- - -## Introduction - -This playbook is designed to help you **transform your database technology** and overcome any obstacles on the way. - -* Each play is an **integral** part of database transformation decisions. -* All these plays in total are essential to the **success** of these decisions. -* **Note:** GSA will continue to publish updates to the playbook with best practices and lessons learned. -* GSA will publish an updated case study article/playbook detailing some of the challanges and lesssons learned from the TMF Database Transformation Project. We expect to publish the case study NLT September 2019. Thanks and stay tunned! -* Last Updated on 8/6/2019 - - - - -## The Plays... - -**1. Know your inventory** - -Know what databases and data you have. Know the producers and consumers of the data - -**2. Prioritize** - -Weigh options against business priorities to see which projects will make the biggest impact - -**3. Set goals** - -Set achievable, focused goals that move you towards your priorities - -**4. Pilot solutions** - -Start with smaller, engagements and you will learn from those as you scale - -**5. Build up your team and systems** - -This is an opportunity to take your enterprise to the next level, don't let this modernization opportunity go to waste - -**6. Iterate** - -Double down on what works, stop doing the things that aren't producing results - -**Let’s get started…** - - -## Know your inventory - -The more you understand what you are currently maintaining, the more you can understand project needs and risks. - -Database transformations can be **complex** and **resource** intensive. They may require: - -* Various teams and personnel -* Comprehensive migration and implementation plans -* Mitigating risk to mission-critical business operations - -As such, agencies should know what tools and services are available internally, and when to apply them in developing an **enterprise architecture-based database strategy.** - -Before you begin developing your database transformation strategies, it’s important to understand what’s incorporated in your **legacy database portfolio** and any **complexities** tied to that portfolio. - -* To do so, assess the extent to which the portfolio currently meets your agency’s **business needs**. - -The portfolio inventory and assessment will provide a **snapshot** of both the current and future environment, and the complexities associated with those environments. - -* It should include: security, functional health, technical health, strategic alignment, and financial impact of the portfolio. -* Technological complexity should take into account information types, product-specific implementations, and the architecture of the legacy solution. - - - -Examining these topics will provide the **data-driven insight** needed to make **defensible decisions**, **reduce risk**, and **prioritize**. - - -## Prioritize - - - -While these are all compelling reasons to transform, the key to a successful database transformation is to **align the business value** with the database **transformation** strategy and **implementation** strategy. - -To preserve and structure the business knowledge and functions residing in legacy systems, your strategy should: - -* Allow users to easily get **actionable** and **unified** information the way they want it, and at the **speed** their business needs it. - - - -This will improve the overall **efficiency** and **effectiveness** in performing the functions that support mission priorities, and revitalize IT investments. - -Having clear priorities will help you set meaningful goals. - - -## Set Goals - -Transforming “**everything under the sun**” can be highly risky, time consuming, extremely costly, and burdensome on resources. As a result, the scope of your database transformation should be **well-defined**. - -Your goals might be a combination of: - -* cost avoidance -* maintainability -* security -* performance -* modernization - - - -Set achievable goals that move you towards your priorities. Focus on a **few core goals** and define them. - -For example, modernization in the context of databases might mean: - -* database code is in source control -* continuous integration and testing -* the underlying system can be patched quickly -* database code is documented - -Once you define your goals it’s important to establish well thought out **metrics** to gauge your level of **success**. - -IT modernization architecture should include **defined performance measures** and **outcomes** that support your organization’s objectives. - -Clear goals and metrics will enable you to establish the **project scope** and **roadmap** of your database transformation. Be sure you capture a valid baseline of performance and network typology that can be used to compare the perfomance of the to-be architecture. - - -## Pilot Solutions - -Once you have made a decision on your specific scope and have a good grasp of your database portfolio, you can start looking at projects more granularly. - -The first thing to ask, for each project, “**Do I need to directly maintain a database?**” Investigate SaaS solutions and see if there is existing tools for frameworks that meet your goals. - -When you determine a database migration will best support your goals, you can begin the **database technology selection**. This is one of the most important decisions when designing **data-driven systems**. - -Database transformations allow you to transform to more **modular systems**: - -* Avoiding **monolithic** systems and **proprietary** technologies with **shrinking** talent pools -* Improving **business value** to customers -* Yielding operational **efficiencies** -* Enabling simple **integrations** with other systems -* Lowering **total cost of ownership** associated with licenses and maintenance/sustenance costs of legacy environments -* Providing greater **agility**, **resiliency**, **scalability**, and **performance** - -In implementing a database transformation, you should **start small and scale fast**. Use an **agile approach** to reduce **risk** and drive **quality**. Deliver modernized components **incrementally**, transforming the bare minimum necessary to: - - - -* **deploy** faster -* obtain **feedback** from users -* create technical architecture **validation** - - -## Build Up Your Teams and Systems - -### Build Your Team - -A robust workforce is the key to any successful business transformation. In-house talent is especially useful for database systems, since data persists longer than individual contracts. - -Make sure that your modernization plan involves training that exposes people to new technologies early. When new systems and tools are chosen, make sure the people that will be developing and maintaining those systems have sandboxes to test the new technologies- this could be on their own laptops or virtual environments. Send FTEs to get relevant skills training as early as possible. - -Consider using this training as an opportunity to instill best practices so that the teams are modernizing along with the systems they support. Set up source control for your database code, which is any code that interacts with the database. Make sure the assets in the system are documented and that documentation is maintained. Leverage automated migrations. Evaluate that your operational security is up to standards. - -Making sure your team is supported during a transition will make managing the changes easier on them. Likewise, support from key leaders will give confidence to new processes and dissuade people from resisting changes. - - -### Build your systems - -After you understand your current systems and have clear priorities and goals, building your systems will be much more straightforward and meaningful. - -For your pilot project and subsequent projects make sure your solutions fit the goals and needs. - - -### Choosing a database to fit your goals - -A database is an intricate part of an application. As such, changing the database technology may require **changes to other layers of the overall application**. - -For example, there may be **refactoring** and/or **re-engineering** of your system’s backend. - - - -To make the most informed decision when selecting a database technology, you should know what your **database criteria** are. - -**Considerations** and **Requirements** include: - -* Security -* Robustness and reliability -* Scalability -* Analytics -* Operational and querying capabilities -* Availability -* Distributability -* Amount of data -* Type and structure of data -* Talent pool and availability of relevant skills -* Database vendor support funding, stability, and community -* Level of establishment -* Cost of licenses -* Ease of data transfer -* Easy to patch and maintain -* Good documentation for future development -* Infrastructure costs -* Platform specific features and limitations - - -### Which Database Is Right For Each Project? - -It is normal to have more than one database technology in satisfying your database needs. - -Certain databases are popular for their **speed** and **scalability**, while other databases are preferred for being **highly structured**. - -You should understand your specific **use case** in selecting the right database technology. - -No matter what database or service you use. Make sure you own your own data. - -When it comes to database technologies, there’s **no one-size-fits-all solution**. Although different database technologies serve different tasks, your database technology should support all data types - **structured** and **unstructured**. - -To this end, consider **open-source** database technologies to “**future proof**” your strategy. - -Open-source databases are more **modular**, promote **open standards** and **APIs**, and extend **foundational elements** essential to: - - - -* **Avoiding** a one-size-fits-all feature set -* **Shifting** from low-value work to **high-value** work -* **Robustness** of code -* **Flexible** and **scalable** platform for the future -* **Scaling** up or out without direct cost/license restrictions - -By implementing open-source databases, you can yield a **lower total cost of ownership**, and shift the **cost burden** from upfront licensing to **implementation** and **customization**. - -Also consider any **encryption requirements** when selecting a viable open source database engine. Applications with Personally Identifiable Information (PII) or Payment Card Information (PCI) data may have Transparent Data Encryption (TDE) or Cell-Level Encryption (CLE) requirements. Thoroughly research which encryption features are supported by the to-be database engine. - - -## Iterate - -Maintain **control over quality** by combining your iterations with **incremental releases**, early **prototyping**, and **testing**. - -Leverage the phased approach below in executing incremental funding and incremental development. - - - -* _**Phase 1 / Proof-of-Concept:**_ - * Identify **prototype candidates**, and test various database records to see if a target technology meets your specific needs. - -* _**Phase 2 / Pilot:**_ - * Pilot a database technology with **pilot candidates** to uncover legacy technology obstacles, increase confidence, and gain user buy-in. - * Evaluate the success of your pilot based on the goals and metrics you established. - * Report out on what strategies worked and what experiments failed - -* _**Phase 3 / Scalable Execution**_ - * Fully execute your selected database transition - this may go beyond just transitioning the database, but application transformation. Have a detailed **design**, **building**, and **configuration** of the new environment, system, and application. - * **Test** to ensure all requirements have been met. - * **Deploy** the new database solution. - -* _**Continue iterating**_ - * **Apply** what you have learned to new projects - * Continue to **Test**, **Deploy**, **Patch and Maintain** your solutions - - - - -## Database Modernization Case Study - -Database transformations always require communication and agreement at the top levels. Without leadership buy-in, teams may push back due to other competing priorities. - -When GSA’s Identity and Access Management System reached the end of its lifecycle, GSA needed to begin a database transformation. All the impacted executive system owners were involved and on-board before diving into the work. With top-level buy-in, integrated security, application and business teams were able to organize in DevSecOps structures and were also able to assist and participate in a smooth transition to the new system. - -**Lessons Learned:** - -* Communication from the executive application teams to customers is essential for impact, changes, and future direction. -* Expect push back from certain contracts and contractors. Including extra time early on in your contracting process will help mitigate potential problems down the line. -* Handle risks and change management through the normal process rather than introducing a new process to the mix. -* Regularly communicate with application directors and executive system owners. - * Too many emails and meetings can become overbearing and inefficient. - * One-on-one chats can be forthcoming, and provide both good and bad insight to the process. -* Don't forget the closeout activities such as updating ATOs and properly decommissioning any hardware or you will be answering for it in years to come. It's not as critical but it still needs to be completed. -* It’s better to tackle a database transformation earlier in a system’s lifecycle than later. - - -## Case Study Update - -GSA is wrapping up the Pilot phase of a project where we are partnering with the TMF to modernize our application and database infrastructure: [Application Modernization Integrating Flexible Architectures](https://tmf.cio.gov/projects/#application-modernization-integrating-flexible-architectures). Please refer to the link for the details and goals of the project. - -We are updating the playbook based on our experience from this project to ensure we are providing teams with lessons learned and best practices. The team will host retrospectives later this month (August 2019) once we closeout Pilot Phase deliverables. Thanks and stay tuned! - ---- - -Icon Credits - -* _“Boost” by Dev Patel from thenounproject.com_ -* _“Bow and Arrow” by faisalovers from thenounproject.com_ -* _“Archery” by Oliviu Stoian from thenounproject.com_ -* _“Flask” by NOPIXEL from thenounproject.com_ -* _“Telescope” icon by Eucalyp, from thenounproject.com_ -* _“Sabotage” by Krisada from thenounproject.com_ -* _“Integration” by Tokka Elkholy from thenounproject.com_ -* _“Delivery Man” by Виталий Плут from thenounproject.com_ -* _“Jet Fighter Pilot” by Gan Khoon Lay from thenounproject.com_ -* _“Rocket” by Nikita Tcherednikov from thenounproject.com_ diff --git a/content/guides/databaselessonslearned.md b/content/guides/databaselessonslearned.md deleted file mode 100644 index 99a061be..00000000 --- a/content/guides/databaselessonslearned.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -layout: single-toc -title: Database Transformation Lessons Learned -description: This case study will highlight the lessons learned from the GSA Application Modernization Integrating Flexible Architecture project. -category: Database -aliases: - - /playbooks/databaselessonslearned/ ---- - -## Introduction - -The intent of this case study is to share the challenges that surfaced and the steps we took to mitigate and/or resolve those challenges. We hope to save teams' valuable time during their database migration journeys! - - -## Context - -Database migration is not easy and GSA fully understands the challenges and complexities that accompany such an effort. For this reason, we hope this document will help teams **proactively identify and mitigate challenges**. GSA recently completed a 6 month pilot for migrating databases from proprietary software to open source software. A high level description of the project can he found on the Technology Modernization Fund (TMF) website under Application Modernization Integrating Flexible Architecture. GSA conducted an end of phase retrospective with all team members and represents the basis for the information shared throughout this document. - - -## Team Construct - -GSA IT did not assemble a dedicated team for planning, project management and implementation. Instead, GSA IT employed a matrix team structure with representation from 3 primary GSA IT business lines (which also represented the development teams), budgeting, enterprise and cloud infrastructure, database and middleware, security, privacy, enterprise architecture and the office of the chief technology officer (OCTO) - a total of about 20 team members. - - -## Implementation - -* Tools - * AWS Schema Conversion Tool (SCT) - * AWS Data Migration Services (DMS) -* Technology - * AWS RDS - * PostgreSQL Database - - -## Pilot Phase Outcome - -GSA IT **developed a repeatable database migration service** that will be used to facilitate future database migrations of any database engine type. We also developed an API that decouples a database from the application. The API will be leveraged to further decouple databases that fall within that GSA portfolio. - - -## Product Management and Communication - -Team members from the office of the OCTO facilitated product management activities, coordination and overall monitoring and status reporting to GSA IT leadership, the TMF PMO office, and OMB. The Pilot Phase meeting cadence consisted of 1 weekly 30 minute stand up on Mondays with the overall team and 1 bi-weekly 45/60 minute session with each of the development teams. - -* The **30 Minute weekly stand ups** were helpful for sharing information and statuses across the team. It provided a consistent and recurring means for each team to interact directly with other teams to coordinate tasks, clear blockers, and further define requirements and dependencies. -* The **bi-weekly 45/60 minute sessions** provided each of the development teams the opportunity to meet with team members providing core-IT services from security, enterprise infrastructure, enterprise architecture, database and middleware, privacy, and cloud services. Each of the support staff had an opportunity to clarify requirements and dependencies to ensure tasks were well understood. -* In addition, the team operated on a two week sprint cycle (scrum) and consolidated activities on a master Trello board to tracking tasks. - - -## Budget and Contract Support - -Dedicated budget support was essential for tracking budget execution activities and contracting actions. GSA IT did not execute a new contract for database transformation, much of the technical and support related work were already in scope throughout several GSA IT contracts with multi-year renewals remaining on the contract. By leveraging existing contracts, GSA IT was able to begin work shortly after the TMF Board awarded the initial disbursement of funds. - - -## Collaboration - -GSA migrated to Google Suite (G-Suite) several years ago, so the team primarily used G-Suite tools for content creation and consolidation, instant messaging, group chats, email and video calls. - -**Note:** Although the Google Hangouts application does support history retention within an established group, the team sparsely used the tool and relied on communicating through email and status updates applied directly to the Trello board. In the next phase of the project we are exploring using Slack to help drive better collaboration across teams. - - -## Challenges - -* GSA performed heterogeneous database migrations for all three pilot phase systems and experienced a few initial challenges with data migration and validation across database engine for special characters and delimiters. -* We performed both a cloud-to-cloud database migration and an on-prem-to-cloud-to-on-prem (two of the applications were not ready for full migration to the cloud). The databases that were migrated back to on-prem required colocation with the applications for performance considerations. The benefit of this approach, the database is already cloud-ready and can easily migrate to the cloud if and when the application moves as well (and not to mention it also helps to reduce cost). -* We also noticed a skills gap in cloud and open source database technology experience. We were able to overcome the gap by augmenting the team with experienced staff that helped train and familiarize team members with the technology stack. -* Although data encryption was not in-scope for any of the pilot phase databases, we started to look at possible solutions for file and field level data encryption given the additional GSA databases with PCI/PII data that are within scope of the overall project. We are exploring a SQL Proxy Cluster solution for encrypt/decrypt. GSA will provide an update of the solution once finalized and working in production. - - -## Recommendations - -* Ensure your security personnel are included in all relevant conversations to ensure all security compliance requirements and documentation are drafted, updated and finalized within the timelines required to fulfill specific security tasks - have those conversations frequently and often! ATO reviews can take weeks/months, ensure there is enough lead time for a full and proper review by security. -* When possible, use existing contract vehicles. This will save your team months of valuable time and will allow you to begin work quickly. -* Consider **standardizing sprint schedules and task boards** for tracking deliverables and dependencies across all teams. - - -## Next steps - -* GSA has started the next phase of the project and targeting a total of eight databases. GSA will continue to post updates of our progress. -* Thank you for reviewing this post, stay tuned! - -Please contact the GSA OCTO with any questions at [cto@gsa.gov](mailto:cto@gsa.gov). diff --git a/content/guides/dev_sec_ops_guide.md b/content/guides/dev_sec_ops_guide.md deleted file mode 100644 index 570933d1..00000000 --- a/content/guides/dev_sec_ops_guide.md +++ /dev/null @@ -1,359 +0,0 @@ ---- -title: DevSecOps Guide -category: DevSecOps ---- - -## Standard DevSecOps Platform Framework - -Goal: Safer Software Sooner - -The following document describes, at a high-level, the expectations, scope of responsibilities, maturity model, and metrics associated of any DevSecOps platform at GSA. - -### Baseline Definitions - -**DevSecOps:** A cultural and engineering practice that breaks down barriers and opens collaboration between development, security, and operations organizations using automation to focus on rapid, frequent delivery of secure infrastructure and software to production. It encompasses intake to release of software and manages those flows predictably, transparently, and with minimal human intervention/effort. - -### Common Expectations - -Successful DevSecOps teams have processes characterized by repeatability, low redundancy, high collaboration with dispersion of collective efforts; in order to achieve this most efficiently, automation and auditability is prized above subjective decision-making. The decisions that would drive successful release should be codified in code. If it is not feasible to capture in code, checklists with clear yes/no decision points are preferred to heavily documented standard operating procedures (SOPs). SOPs can be subjectively interpreted more so than these first options. - -This does not mean that there aren’t scenarios in which that process can be disrupted and replaced by subjective decision-making; but those scenarios should be rare and driven by extreme conditions rather than the norm. - -All of the components described below are going to imply the necessity for some foundational elements; for example, infrastructure-as-code, source control, automation, clear communication pipelines, and many others. Individual platforms may implement these differently, but we will see those common elements emerge as designed. - -## How to Use This Document - -This document is not a framework describing any specific implementation. It describes the requirements that need to be met by any specific implementation before it can be considered a Standard GSA DevSecOps Platform. It should be used by owners of platforms in conjunction with the CTO, Deputy CIO, and CISO to define an implementation of the requirements described in this framework. It should be used by application developers to understand and find platform implementations. This framework is set alongside a [template](/assets/cms/files/DevSecOps_Platform_Template.docx) that captures the requirements for any platform implementation. - -A **platform** can be anything from an IaaS-driven pipeline of software delivery to a PaaS to a SaaS-driven application deployment scheme. Applications are deployed on platforms and provide services to our users. **Applications** are accepted onto platforms via an **intake** process. In GSA, that could mean that our delivery of applications on Salesforce can (and should) align to the framework described below. - -When a DevSecOps platform meets a certain level of maturity, it qualifies for a streamlined delivery and ATO process. - -The DevSecOps platform standard is categorized into domains of responsibility. Each domain of responsibility has four components: - -* **Description:** A short description of the scope of that domain. -* **Maturity Model:** A set of differing levels of maturity within that domain and their differentiators. In many cases, being below a certain level of maturity would preclude the platform from being considered a Standard DevSecOps Platform. -* **Metrics:** Key metrics that any platform implementing the framework should be collecting (note: given GSA’s current level of maturity in DevSecOps, these metrics may not be immediately feasible to collect, but any platform owner should have a plan to begin that collection at the outset). -* **Artifacts:** A list of artifacts (or artifact types) that should be provided by the platform owner to describe the implementation. The description, as mentioned above, is preferred to be executable, documented code. Platform owners should work expressly to keep textual artifacts minimal. - -Each platform will assign responsibilities at the domain level and then the artifact level to ensure that individuals and organizations have clear understanding of who owns what. - -## Platform Domains and Responsibilities - -### Overarching DevSecOps Platform Considerations - -#### Description - -This domain encompasses the holistic nature of DevSecOps around the platform itself, capturing the flow of work into the environment and release of software out of it. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** The platform is characterized by manual efforts, is not transparent about state, is not standardized across teams, and is heterogeneously configured on a per-project basis. -* **Level 2:** Application developers have a pipeline that they can use to deploy software which is considerate of security and visible to operations. Intake into the platform may be manual or unpredictable. Steps to deploy or maintain operations may require manual effort or assessment. -* **Level 3:** Application developers have a clear, self-service intake onto the platform and the ability to deploy and run security-compliant code in production through automation. The platform services are centralized in its infrastructure and pipeline implementation. - -#### Metrics - -There are countless possible metrics in a DevSecOps platform. The decision of which metrics to track is largely based on business need and compliance requirements. This framework labels individual metrics as “High-Value” or “Supporting”. High-Value metrics are those that provide the most critical insight into the performance of a DevSecOps platform, and should be prioritized for implementation. Supporting metrics are those that a team may find useful to improve their DevSecOps platform. - -#### High-Value Metrics - -These metrics should be implemented first in a new platform. Not all platforms will have these metrics immediately available, but a fully mature environment typically will have all of these metrics. - -| Metric | Description | Associated Domain(s) | -|-------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------| -| Deployment frequency | Number of deployments to production in a given time frame | Application Deployment; Authority to Operate Processes | -| Change lead time (for applications) | Time between a code commit and production deployment of that code | Overarching; Authority to Operate Processes; Patch Management | -| Change volume (for applications) | Number of user stories deployed in a given time frame | Overarching | -| Change failure rate | Percentage of production deployments that failed | Application Deployment | -| Mean time to recovery (MTTR) (for applications) | Time between a failed production deployment to full restoration of production operations | Application Deployment; Backup and Data Lifecycle Management; Patch Management | -| Availability | Amount of uptime/downtime in a given time period, in accordance with the SLA | Availability and Performance Management; Network Management | -| Customer issue volume | Number of issues reported by customers in a given time period | Overarching | -| Customer issue resolution time | Mean time to resolve a customer-reported issue | Overarching | -| Time to value | Time between a feature request (user story creation) and realization of business value from that feature | Overarching; Authority to Operate Processes | -| Time to ATO | Time between the beginning of Sprint 0 to achieving an ATO | Overarching; Authority to Operate Processes | -| Time to patch vulnerabilities | Time between identification of a vulnerability in the platform or application and successful production deployment of a patch | Authority to Operate Processes | - -#### Supporting Metrics - -These metrics provide useful information and it is recommended that metrics in this category be implemented after the High-Value metrics have been implemented. - -| Metric | Description | Associated Domain(s) | -|-----------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------| -| Test coverage | Percentage of code that is covered by automated tests | Application Development, Testing, and Operations | -| Change types | Percentage of features vs fixes vs security patches | Change Management; Patch Management | -| Time to availability of event information | Time from an event to information about the event being available to the DevSecOps team or end users | Logging, Monitoring, and Alerting | -| Developer onboarding | Time from a developer joining the team to ability to commit code for production deployment | Application Development, Testing, and Operations | -| Change resolution time | Time between a change proposal and closing (implementation or rejection) | Platform Governance | -| Change lead time (for the DevSecOps platform) | Time between a change (e.g., code commit) and platform deployment of that change | Change Management; Patch Management; Network Management; Platform Governance | -| Change volume (for the DevSecOps platform) | Number of user stories deployed in a given time frame | Change Management; Platform Governance | -| Change failure rate (for the DevSecOps platform) | Percentage of platform deployments that failed | Change Management; Platform Governance | -| Mean time to recovery (MTTR) (for the DevSecOps platform) | Time from a failed platform deployment to full restoration of platform operations | Change Management; Patch Management; Platform Governance | -| Change lead time for images | Time from identification of need for a new/updated image to its availability for production use | Image Management | -| Image publishing frequency | Number of new/updated images published in a given time frame | Image Management | -| Logging availability | Amount of uptime/downtime of the logging system in a given time period | Logging, Monitoring, and Alerting | -| Number of monitoring alerts | Amount of monitoring alerts triggered in a given time period | Logging, Monitoring, and Alerting | -| Number of unit/integration tests | Number of automated unit or integration tests for an application | Application Development, Testing, and Operations | -| Number of functional/acceptance tests | Number of automated functional or acceptance tests for an application | Application Development, Testing, and Operations | -| Mean recovery point | Mean time range of data that is lost due to an incident | Backup and Data Lifecycle Management | -| Retention control compliance | Percentage of retention-related controls (e.g., AU-11, SI-12) that are automated | Backup and Data Lifecycle Management; Authority to Operate Processes | -| Image instantiation | Time between when a developer requests image instantiation and its actual instantiation | Image Management | -| Security benchmark deviation | Deviation between security benchmarks applied to an image and security benchmarks on an instantiated image | Image Management, Authority to Operate Processes | -| Technical controls | Number of technical security controls partially or fully in place | Authority to Operate Processes | -| Vulnerability patching frequency | How often vulnerability patches are regularly deployed to production | Authority to Operate Processes | -| Vulnerability patching lead time | Time between discovery of a new vulnerability (i.e., its publication) and patching in production | Authority to Operate Processes | -| A&A lead time | Time between initiating a security compliance assessment and completion of A&A processes | Authority to Operate Processes | -| SAR findings count | Number of findings in the Security Assessment Report (SAR) | Authority to Operate Processes | -| POA&M count | Number of POA&Ms | Authority to Operate Processes | -| New architecture security review lead time | Time between initiating a request for security review of a new architecture, and completion | Authority to Operate Processes | -| Experiments and alternatives | Number of technological experiments and alternative components tested | Overarching | -| System logging count | Number of systems (application, OS, services) in a DevSecOps platform that are logging | Logging, Monitoring, and Alerting | -| AU security control compliance | List and percentage of AU security controls that are satisfied via DevSecOps platform logging practices | Logging, Monitoring, and Alerting | -| CM approval lead time | Time between submitting a change request and its approval | Change Management | -| Deployment approval lead time | Time between requesting deployment of an approved change and the actual deployment to production | Change Management | -| Notification lead time | Time between any given step of the CM process and notification of all interested parties | Change Management | -| User provisioning lead time | Time between request for a new user on the platform and the user being able to log in | Accounts, Privileges, Credentials, and Secrets Management | -| AC security control compliance | List and percentage of AC security controls that are satisfied via DevSecOps platform account management practices | Accounts, Privileges, Credentials, and Secrets Management | -| Privilege auditing frequency | Number of times in a given time period that users and their privileges are audited | Accounts, Privileges, Credentials, and Secrets Management | -| Administrator count | List and number of users that have administrator-level privileges | Accounts, Privileges, Credentials, and Secrets Management | -| Secret rotation frequency | Number of times in a given time period that secrets are changed and updated where affected | Accounts, Privileges, Credentials, and Secrets Management | -| Onboarding lead time | Time between a request for a new application to use the DevSecOps platform and the application being deployed on the platform | Agreements and Financial Management | -| Expense lead time | Time between an expense and reporting of the expense | Agreements and Financial Management | - -#### Artifacts - -* Platform description -* Platform responsibilities allocation - -### Image Management - -#### Description - -*Note:* This is relevant to IaaS and PaaS capabilities, not necessarily SaaS-driven capabilities. - -An **image** in the context of this framework is the definition of a component of computing infrastructure that can be instantiated for use by the platform or by application owners on that platform. Concretely, an image could be a VM image, AMI, a container image or definition, or similar products. **Image management** refers to lifecycle around the creation, maintenance, and delivery of those images to application developers. - -#### Maturity Model - -* **Level 1 (Not considered viable for DevSecOps):** Application developers must make and secure all of their images from scratch or nearly so (e.g., they use their own AMIs which can vary from team to team). -* **Level 2:** Application developers are provided base OS images; the owner of the image management process hardens those OS images, and includes any necessary agents. The application team cannot change the underlying hardened image, except to add application code and components. -* **Level 3:** Applications developers are provided base OS images and images that provide component-level functionality that has also been hardened (e.g., standard images pre-packaged with hardened components i.e. databases or web/application servers). Images and components undergo automatic testing and are pre-approved by security and operations groups. - -#### Artifacts - -* Repository of images (preferably a link to an open source repository to create image) -* Process (code, checklist, and/or SOP) for adding a new image into the repository - the process should cover developer request, addressing of security considerations, and delivery to the platform -* Process (code, checklist, and/or SOP) for instantiating an image in an application - -### Logging, Monitoring, and Alerting - -#### Description - -Logging, monitoring and alerting covers the domain of understanding and managing the health and security of an application’s operational state. This includes capturing what events have occurred (logging), providing information about those events (monitoring) and informing the appropriate parties when those events indicate issues to be resolved (alerting). Application teams need significant autonomy to manage the health of their own applications, but the enterprise at large also needs awareness of the health of applications within it. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Event capture is not existent, not granular, or not available to either application developers or platform owners -* **Level 2:** Platform owners have awareness of platform health and perhaps health of individual applications. Application teams must create their own methods of health management, perhaps with some guidance from the platform owners. -* **Level 3:** Application owners have full access to their application event information with monitoring and alerting flexibility for their own use. An enterprise-wide application logging and monitoring system is available. - -#### Artifacts - -* Guide (code and/or document) to application owner access to logging, monitoring, and alerting services; use of the guide should suffice for an application owner to configure and manage their logs, monitoring, and alerts. The guide should also cover logging configuration for centralized security monitoring by SecOps. - -### Patch management - -Is the process by which the operating system, software, and supporting services are upgraded. This is a key element of maintaining the security of systems. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Patching is both manual and is not enforceable as a requirement nor is the state of patches running machines discoverable -* **Level 2:** Security teams inform the application owners of patches, and it is application owners’ responsibility to both be aware of those patches and implement them. -* **Level 3:** Application owners are automatically notified when there are new security-related patches, and the platform owners are able to identify which applications are using which version of the relevant software via the platform. -* **Level 4:** The platform automatically tests new patches on applications which run on it, informing the appropriate parties if decision points are reached (e.g., if a CVE is raised on an existing piece of software, the platform can automatically update that software, test it, and inform the application developers of the change if the tests pass or indicate that the patch needs to be applied in a particular timeframe). No downtime for patching. - -#### Artifacts - -* Process (code, checklist or SOP) for patching a running system -* Process (code, checklist or SOP) for introducing a patch into the platform [Note: This may overlap with image management] - -### Platform Governance - -#### Description - -Platform governance consists of the processes around and advertisement of changes to the platform, inclusive of managing the security and availability of the platform. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Changes are conducted ad hoc, without transparency, and unadvertised to users of the platform. -* **Level 2:** Platform change is conducted through defined processes with significant manual components required to conduct, especially relying on consensus over objective criteria for making change -* **Level 3:** Platform change is conducted through strictly defined processes with clear criteria defined that allow for rapid change; the platform automates changes and endeavors to impact the minimum number of application developers through that automation. - -#### Artifacts - -* Change proposal intake process (intake form, process description, or SOP) -* Change proposal evaluation process (process description or SOP) -* Change proposal execution process (code, process description, or SOP) -* A forum for communication between the platform owner and application users - - -### Change Management - -#### Description - -Change management consists of all the standards and norms around version control of applications and the platforms itself. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** No version control or standards related to version control -* **Level 2:** Application teams are required to have version control, but there is no standard method of using version control or version control is entirely distinct from application management on the platform. -* **Level 3:** Version control is a key method of managing application lifecycle, has well-defined standards for use such that any user of the platform has a baseline that is shared across all applications. - -#### Artifacts - -* Version control repository (open source, unless there’s a good reason for it not to be, which is rare) -* Version control standards for branching, merging, etc. - -### Application Development, Testing, and Operations - -#### Description - -These areas encompass the development of software by an application team, the unit and integration testing of that software, and the ability to manage that software in operation. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Application development has a poor user experience in which developers and operators of a system are strictly separated, development environments and operational environments differ, and manual processes to manage and release software are required. Testing is not implemented or required as part of release. Operators can make direct changes to the running system that may not be repeatable. -* **Level 2:** Application teams have a set of tools that are provided to them that allow them to develop and test software. The development and operational environment may differ. Operators make changes to the system that can be scripted or manual, but all are documented. -* **Level 3:** Development and operational environments are identical and immutable. Environments can be stood up and torn down via automation. All changes to the running system are logged and broadly conducted through scripting rather than actual access to the running system. All necessary tests, including security tests, are run as part of the deployment process. Development environments may be instantiated and torn down as needed. - -#### Artifacts - -* Developer environment (code or image) that is usable by developers which aligns them as much as feasible to the operational environment, but does not require connecting to a database with real data -* Operational procedures for updating running system -* Testing tools (code) usable by developers for different project types -* Testing standards best practices for the platform - -### Application Deployment - -#### Description - -Application deployment consists of the processes by which an application in development reaches production, most likely going through multiple environments to evaluate the correctness of deployment. Deployed products must be compliant with the relevant security and infrastructure considerations. Deployment should be performed with no downtime. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Deployment is manual, requires significant collaboration and consensus to release, and does not leverage any shared artifacts to facilitate compliant deployment. Getting an ATO and first deployment are independent processes, meaning assessments happen after development rather than during. -* **Level 2:** Deployment has minimal manual steps and uses shared artifacts to facilitate deployment and compliance. ATO processes are independent rather than embedded in deployment. -* **Level 3:** The only manual steps to deployment are those explicitly designed to meet application expectations (e.g., not every push to the master branch necessarily indicates a release, but a product that could be released, if there is a business reason to not automatically update). - -#### Artifacts - -* Deployment pipeline (link to running pipeline, code for launching a pipeline, checklist for deployment and/or SOP) -* Deployment playbook (code, checklist, or SOP) - -### Accounts, Privileges, Credentials, and Secrets Management - -#### Description - -This domain covers broadly the ability for user accounts to be created, given permissions to access, create, and destroy resources, and share secrets securely between the platform and the application as appropriate. This can, for example, include both the creation of user accounts but also the sharing of a database username and password between a provisioned database and the application using it. -Maturity Model - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** User management is done manually and secrets are shared via person-to-person or person-to-platform information exchange without necessary consideration for least privilege access to those secrets. Secrets are hard-coded into configuration files or code in plain text. -* **Level 2:** User management is done through automation with a fixed set of user types. Secrets are stored/passed through secure methods. Secrets are not required to be accessed by people in order to be useful, but could still be seen by people if necessary. -* **Level 3:** User management is self-service with appropriate security limitations. Secrets are created/shared between parts of the platform, without people needing to set/interact with them. - -#### Artifacts - -* User onboarding and offboarding guides -* IAM definitions (code and/or documentation) -* Secret management practices (tools and/or documentation) - -### Availability and Performance Management - -#### Description - -Availability and performance management covers the processes that allow application owners to be assured that the applications will be available, potentially in the face of disaster, and be responsive to user interactions. In order to achieve those goals, the application may deploy redundant capabilities, deploy across different hardware instances, or deploy into multiple regions. Further, application owners may need to manage specific performance characteristics of their applications. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** The platform has no explicitly defined availability for itself. Application owners have little or no insight into the performance and health of their applications. Application owners have no tooling to support automated availability management and potentially no way to support true high availability requirements. -* **Level 2:** The platform itself has defined availability expectation that is advertised to its users. Tenants are notified when there are downtime events, updates to those events, and resolution with port-mortems. Application owners have insight into application health and performance through tooling, but have to design their own architectures to support high availability. -* **Level 3:** The platform manages availability for the application owners through automation based on application need. The platform provides direct insight into application health and performance. Applications can be seamlessly moved between hosting regions/zones in reaction to DR or threat activity. - -#### Artifacts - -* Platform availability metrics -* [If appropriate] Guide to configuring availability for applications -* Method of accessing performance information - -### Network Management - -#### Description - -Network management consists of the creation, maintenance and management of the network structures (such as ingress and egress points, virtual private cloud construction) on which the platform resides and in which the applications are launched. -Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** Each application defines and manages its network structures, inclusive of security assessments. -* **Level 2:** The platform governs the overarching network infrastructure supporting the applications, with defined and assessed separation of network concerns. Application deployment and development requires frequent update of the network configuration. -* **Level 3:** The platform governs the overarching infrastructure supporting the applications, with defined and assess separation of network concerns. Application owners can make limited changes to their network environment sufficient to self-manage the deployment of their applications and creation of new components of their application, on their own, with appropriate compliance checks. - -#### Artifacts - -* Network structure definition, ideally as code -* Request process for network changes - -### Authority to Operate Processes - -#### Description - -The authority to operate (ATO) is the authority given by an authorizing official after assessment by the Chief Information Security Officer (CISO) that a system can “go live” with government data. It takes into consideration the holistic security posture of the application. Traditionally, ATO processes have come at the end of application development, but a DevSecOps environment requires that ATOs are achieved concurrently with development. Hence, the most mature environments will equate deployment with successful receipt of an ATO as the platform itself provides significant security assurances. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** The ATO processes are distinct from the ability to deploy code. System security plans, assessments, and other artifacts are constructed manually. Existing security-approved code and process isn’t adopted. -* **Level 2:** ATO processes are aligned with sprints, meaning partially developed systems can be launched into production. The deployment pipeline will provide notification if manual ATO processes need to be invoked. The first ATO may take longer than subsequent ATOs. -* **Level 3:** ATO processes are highly automated. Compliant code and process is reused by multiple teams. All ATOs take the same amount of time for the same system and frequent deployment is only interrupted when specific risk triggers are raised through automation. Controls can be continuously monitored and measured with automation. - -#### Artifacts - -* Process for achieving an ATO (code, checklist, or SOP) - this process should also dictate the constraints on the application which will break this process and turn it back into a traditional ATO -* Templates for ATO artifacts with appropriate sections already filled in (code [e.g., OpenControl] or document template) - -### Backup and Data Lifecycle Management - -#### Description - -Backup and data lifecycle management allows application developers to ensure that their data is maintained over time and, in the case of failure of any subsystems, that it can be recovered with potentially some gap in transactional data. Lifecycle management of the data includes capabilities to archive and manage data over a long lifetime. - -#### Maturity Model - -* **Level 1:** Manual management of data with little or no tooling provided by the platform directly. -* **Level 2:** Backups are managed through automation with little intervention required from the application owner. -* **Level 3:** The full data lifecycle is owned by the platform through automation. - -#### Artifacts - -* Documentation on use of backup and data lifecycle management -* Template policies or documentation for data retention - for example: - * Log retention policies - * Deployed image snapshot retention scripts/policies - -### Agreements and Financial Management - -#### Description - -Agreements and financial management consists of all the processes which allow new customers of the platform to come onboard through agreements (intake), allowing funding to be allocated by the customers for use, and tracking expenditures over time for both the platform owner and application owners. - -#### Maturity Model - -* **Level 1 (Not considered viable for a DevSecOps platform):** No clear cost model, tracking of expenditures is manual. Onboarding a new customer is a laborious process. -* **Level 2:** The cost model is defined and consistent and application owners get regular reports on expenditures to ensure they are within budget. -* **Level 3:** Onboarding is largely self-service (within appropriate legal limits), and application owners have full access to their expenditures at any time. Application owners can set triggers on expenditures to manage their costs appropriately - -#### Artifacts - -* Canonical documentation (ideally, a public web page) explaining the pricing and onboarding process -* Links to spending dashboards -* Process for onboarding -* Process for allocating budget diff --git a/content/guides/develop_an_agile_product_roadmap.md b/content/guides/develop_an_agile_product_roadmap.md deleted file mode 100644 index 06a228c5..00000000 --- a/content/guides/develop_an_agile_product_roadmap.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: 3 Steps to Develop an Agile Product Roadmap -category: Agile ---- - -A product roadmap is a high-level plan that serves as a tool to map an idea, develop the strategy for a product, align customers / stakeholders and the funds required to develop the product. Creating an effective roadmap becomes a challenge when changes occur frequently and product ideas evolve continuously. Below are quick steps to develop a product roadmap that is enables timely response to change and facilitates learning. - -## 1. Complete the Groundwork - -### Define and Validate the Product Vision - -The first and most important step prior to developing an effective roadmap is articulating the objective and communicating how the product will support the organization’s overarching goals. A clearly defined product vision enables the team delivering the project to understand the product direction and contribute towards its realization and success. - -An effective product vision: - -* Identifies clear and focused product goals -* Relates the product value to organization strategy -* Defines the users of the product -* Is compelling - -### Acquire Buy-in - -The roadmap will define the strategy and high-level plan to develop the product. It should progress and be socialized in such a way that it represents and addresses the needs or concerns of stakeholders, sponsors or those who may be impacted by product decisions. Treating stakeholders like customers, securing their representation to address their concerns throughout the development process of the roadmap, facilitates buy-in and acquires the necessary support for overarching vision of the product and development efforts. - -Tips for acquiring stakeholder support: - -* Identify specific concerns for each stakeholder -* Create a prioritization scheme (e.g. customer satisfaction vs. complexity) that aligns stakeholder customer goals with product objectives. -* Make the process transparent - clearly communicate decisions, changes and timeline - - -## 2. Develop an Objective-Based Roadmap - -### Focus on Product Objectives, Not Features - -Typically, product roadmaps contain a mix of functional features that map against timelines dictating *how* to achieve product objectives. The challenge of this approach limits the team from exploring all potential avenues to deliver the most viable solution. Instead, if we shift the focus of a roadmap from specifying features to emphasizing the user or business problems, we articulate the *what* and the *why*. Enabling product teams to understand the reasons for the product/service needs that will achieve the strategic goals of acquiring/retaining users, generating revenue, increasing engagement, etc. - - -### Sample Traditional Product Roadmap - -{{
}} - - -### Sample Agile Product Roadmap - -{{
}} - - -## 3. Communicate, Review and Adjust Regularly - -### Make the Roadmap Visible - -Once a roadmap is completed, communicate the project objectives / milestones by sharing the roadmap with the product team to better understand the vision and direction for the product. The product owner or manager should continue updating the roadmap to the team completes development over time. - - -### Respond to Change - -The product strategy roadmap is developed to guide and keep customers, agile teams and business stakeholders aligned with developments. In order for the roadmap to continue effectively serving its purpose, it needs to developed in such a way that it is evenly focused on short-term tactics as well as strategic, long-term goals, and be supported by a framework that allows to track and address customer feedback. One approach is to setup frequent review and prioritization periods to update the product roadmap to reflect the most up-to-date state for the product. The frequency of review can be set monthly, quarterly or tagged to the performance of a specific release, depending on the maturity of the product and the pace of change in the industry or market. Additionally, the product lead can utilize various [visibility and collaboration tools](/guides/visibility_and_status/) to communicate these changes and ensure the team continues to build relevant features that respond to new product milestones and move the organization closer to towards the overarching vision. - -[Download this Agile Product Roadmap Template](/assets/cms/files/TemplateAgileProductRoadmap.docx) and apply the three tips to build a goal-oriented, articulate and responsive strategy for delivering your next product / service. - - -## Additional Reference - -* [10 Tips for Creating an Agile Product Roadmap](http://www.romanpichler.com/blog/10-tips-creating-agile-product-roadmap/) -* [Goals vs. Features: How to Choose the Right Product Roadmap Format](https://dzone.com/articles/goals-vs-features-how-choose) -* [Agile roadmaps: build, share, use, evolve](https://www.atlassian.com/agile/roadmaps) -* [How to Communicate Your Roadmap to Stakeholders ](https://www.productplan.com/communicate-roadmap-stakeholders/) -* [Product Roadmap Failure: Stop Setting Them Up To Fail](https://age-of-product.com/product-roadmap-failure/) diff --git a/content/guides/digital_services_playbook.md b/content/guides/digital_services_playbook.md deleted file mode 100644 index e51e0e28..00000000 --- a/content/guides/digital_services_playbook.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Using the U.S. Digital Service Playbook -category: Agile ---- - -The [U.S. Digital Service Playbook](https://playbook.cio.gov/) is a great reference for starting and managing projects and solutions. - -## Digital Service plays - -1. [Understand what people need](https://playbook.cio.gov/#play1) -2. [Address the whole experience, from start to finish](https://playbook.cio.gov/#play2) -3. [Make it simple and intuitive](https://playbook.cio.gov/#play3) -4. [Build the service using agile and iterative practices](https://playbook.cio.gov/#play4) -5. [Structure budgets and contracts to support delivery](https://playbook.cio.gov/#play5) -6. [Assign one leader and hold that person accountable](https://playbook.cio.gov/#play6) -7. [Bring in experienced teams](https://playbook.cio.gov/#play7) -8. [Choose a modern technology stack](https://playbook.cio.gov/#play8) -9. [Deploy in a flexible hosting environment ](https://playbook.cio.gov/#play9) -10. [Automate testing and deployments](https://playbook.cio.gov/#play10) -11. [Manage security and privacy through reusable processes](https://playbook.cio.gov/#play11) -12. [Use data to drive decisions](https://playbook.cio.gov/#play12) -13. [Default to open](https://playbook.cio.gov/#play13) diff --git a/content/guides/embracing_agile.md b/content/guides/embracing_agile.md deleted file mode 100644 index 54ba1dd5..00000000 --- a/content/guides/embracing_agile.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Embracing Agile -category: Agile ---- - -The GSA is fully embracing Agile as a core methodology for not only developing new IT capabilities, but also how it operates and executes the development of policy, practice, and other elements of our business. These guides are focused on how we invest and build software and systems, primarily. - -Our intent is to be descriptive at an agency level through policy and best practice and proscriptive at a program and team level, tuning the specifics agile implementations to the needs of the business and implementation teams. - -We start each pilot with the same processes and intake, to create standardized approaches to how we are doing Agile and using those to create a culture of delivery and agility across the agency. diff --git a/content/guides/estimation_and_storypointing.md b/content/guides/estimation_and_storypointing.md deleted file mode 100644 index 95aa3b40..00000000 --- a/content/guides/estimation_and_storypointing.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Estimation and Story Pointing -category: Agile ---- - -Generally, in order for a requirement to fully meet its [Definition of Ready (DoR)](/guides/glossary/#definition-of-ready), the level of effort to complete the work must be estimated. The Product Owner and **ALL** members of the Team; not only development, but testers, user interface designers, database administrators, etc.; that are needed to complete the requirement should work together to identify the level of effort and establish an estimate. - - -## What is Estimation? - -An estimate is a rough calculation of the value, number, quantity, or extent of something. When used in Scrum (or Kanban), it is a point-based, valuation system for estimating the level of effort it takes to deliver a requirement, or user story. While estimates account for the level of effort to deliver “the product,” they are relative to the Team providing the estimate and will typically vary across teams. The valuation scale for estimates is usually reflected in terms of size, but most often as story points. - -Assigning a numerical value (i.e story points) to relative estimates allows Teams (especially newly formed ones) to reach consensus about the level of effort needed to complete a requirement, or user story. By removing the implied precision of the numerical score, they increase the accuracy of capacity estimates and measurement for planning. - - -## What are Story Points? - -Story Points are an arbitrary measure used by Teams to measure the effort required to implement a user story, or requirement. The story points tell how hard the story is, the level of complexity, account for unknowns, and provide an indication of effort. - -{{
}} - -In terms of sizing, story points can range from extra small to extra large, but mostly commonly used is the Fibonacci series. - - -## Fibonacci - -The Fibonacci series is a mathematical sequence where each number is the sum of the previous two, with the scale being 1, 2, 3, 5, 8…and as a best practice, usually work that is an 8 or beyond should be further decomposed into more manageable chunks that can be accomplished within a sprint. - -{{
}} - -The Fibonacci series uses a range to help recognize uncertainty and removes the “emotional attachment” to hours and dates. Using the Fibonacci series guides estimation in “being roughly right over being precisely wrong.” - - -## Estimation for Your Team - -When estimating for your Team, there is no standardized approach other than the level of effort you think it will truly take to complete the requirement, or user story. Typically, most Teams will begin by using an estimation exercise to identify the “relative size” of stories in their Backlog. - -Begin with a single user story and then compare each story in the Backlog to determine if it is relatively smaller or larger. As you compare the stories, a scale will begin to evolve. The stories with the smallest level of effort should be assigned a 1-point estimate while the largest should be a 5-point estimate (ideally, stories that are larger than a 5-point estimate should be decomposed further.) - -{{
}} - -While a consensus should be reached for each estimate, the level of effort should be reflective of the overall effort - experience of all team members, development, quality testing, user acceptance testing, etc. - in order to achieve the established [Definition of Done (DoD)](/guides/glossary/#definition-of-done). - -{{
}} - -Estimation and story pointing identifies the level of effort to complete a requirement, or user story, but avoids bias and influence. It should drive the Team’s discussion and understanding of a requirement. Story points should be updated accordingly as additional information becomes available. Understand that in the initial stages, estimates may be all over the map, but over time the Team will begin to produce an average velocity and burndown. - - -## Good Reads - -These are good references for estimation: - -* [Secrets of Agile Estimation](https://www.atlassian.com/agile/estimation) -* [Estimation Exercise (TastyCupcakes)](http://tastycupcakes.org/tag/estimation/) - -These are good references for story pointing and the Fibonacci series: - -* [How You Should Create User Stories & Give Story Points](https://hackernoon.com/following-agile-this-is-how-you-should-create-user-stories-and-give-story-points-bdffba0cfe5a#.1qcc949on) -* [Story Points Are Still About Effort](https://www.mountaingoatsoftware.com/blog/story-points-are-still-about-effort) -* [The Main Benefit of Story Points](https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points) -* [What is a Story Point?](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) -* [Image Source](https://agilewarrior.wordpress.com/tag/estimation/) diff --git a/content/guides/managing_requirements.md b/content/guides/managing_requirements.md deleted file mode 100644 index 669ddce7..00000000 --- a/content/guides/managing_requirements.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Managing Requirements in an Agile Environment -category: Agile ---- - -In many ways, the manner of capturing requirements in an Agile project management environment is similar to a *“waterfall,”* or traditional project management environment - numerous meetings with subject matter experts, end users, walkthrough / documenting the current business workflow, creating mockups, etc. However, Agile and traditional project management approaches contrast in how requirements are managed over time. - -Some fundamental differences in managing requirements include: - -| Traditional Requirements Management | Agile Requirements Management | -|-|-| -| In a “waterfall” project management environment, the approach is to capture and define **all** of the end-state requirements upfront. | In an Agile project management environment, while high-level requirements are also captured upfront, it is understood that requirements may evolve over the course of the effort. | -| Requirements are documented in a business requirements document (BRD) or business specifications document (BSD) for the purpose of designing the end state of a product. | The effort begins with a high-level scope agreement where initial business requirements are translated into user stories. Those user stories specify the needs of the product based on the information at the time given. | -| The goal is to understand the “as-is” state of the existing product or the business gaps that define the lack, so that the “to-be” state of the desired product can be defined. | The goal is no longer focused on eliciting the “as-is” in order to the define the “to-be,” but to clarify and ensure understanding of the business need for all users. | -| By defining the end-state of the application from the beginning, there is little room for change once development begins. | As more information becomes known over time, the team is better able to adjust and make changes accordingly. | - -Managing requirements in an Agile project management environment is to think through the full life cycle of the requirement; to consider the full user experience and even beyond the defined stakeholders. Business requirements should be broken down in such a way that supports iterative development and enables flexibility to respond to potential changes as each increment is delivered and reviewed by business users and / or customers. - -Further, requirements should produce [strong, testable user stories](/guides/effective_user_stories/) that are clarified and reviewed often with the customer, end users, and development. User stories should promote a consistent conversation with the team that not only strengthens understanding of the business need, but results in more informed [estimation](/guides/estimation_and_storypointing/) and prioritization. As both the business users and the development team are engaged throughout the project, it builds trust and encourages [collaboration](/guides/business_and_it_collaboration/) across the board. Finally, it ensures faster, better delivery of requirements that truly convey and meet the business need. diff --git a/content/guides/measures-agile-success.md b/content/guides/measures-agile-success.md deleted file mode 100644 index d52bafe9..00000000 --- a/content/guides/measures-agile-success.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Measures of Success in an Agile Organization -category: Agile ---- - -Successful product / project delivery requires a framework and processes that embrace new and responsive ways of completing work and driving collaboration in order for the organization to thrive in this fast-paced world. For many organizations, an Agile transformation decision is driven by high-level objectives such as, increased efficiency, quick implementation to gain faster return on investment, or building the right / quality products to satisfy customers. One of the most common [challenges in these Agile organizations](/guides/agile_adoption_challenges_and_best_practices/) is the pressure to follow legacy measures and metrics to determine if new processes are achieving the desired results. Traditional metrics (e.g. fixed scope) that evaluate progress by meeting predetermined requirements and scheduled delivery, regardless of potentially evolving customer needs, fall short in effectively assessing the organization's delivery performance against its set objectives. - -In order to track and measure if the organization is making progress, redefining what is considered “success” against the new organizational values and objectives becomes an important step. Implementing new success factors and metrics that support Agile values and the customer need become the cornerstones of defining successful delivery. So how can an organization that has envisioned Agile benefits and set desired outcomes measure success against the same? - - -## Measuring Business Value - -Below are some examples of measures and metrics that could be used to facilitate and track approaches to evaluate Agile success in light of organizational values. - -| Business Value | Example Metrics | Measurement Examples | -|-|-|-| -| Customers / stakeholders engagement | Projects implemented have approaches to ENGAGE customers | Focus groups, User persona development sessions, Wireframing and sprint demo, feedback, etc. | -| User representation throughout the delivery process | Projects have approaches implemented to ASSESS customer satisfaction % of projects that have committed Product Owners | Delivery meets agreed-upon high priority items / success criteria | -| Continuous prioritization and communication of user needs and responsiveness to change | Customer satisfaction against product / service delivered increased by % | Number of feedback loops, ongoing communication | - - -## Measuring Improved Efficiency / Productivity - -One of the primary benefits of adopting Agile frameworks is enhanced process improvement through a greater emphasis on [continuous communication, collaboration, transparency](/guides/visibility_and_status/) and shared responsibilities. The result is improved productivity, efficiency, and increased performance which can be measured by tracking progress made against the reduced amount of time it takes for a product / service to reach the market in addition to the improvement in quality of delivery. Organizations can eliminate duplicative handoffs across cross-functional roles and systems, align budgeting and investment funding based on performance, and significantly reduce waste and time-to-market for a given product / project or service. Below are examples of relevant metrics that will enable to track progress against this Agile milestone: - -| Organizational Productivity | Metrics | Measurement Examples | -|-|-|-| -| Eliminating waste | Promotes efficiency and smart spending by utilizing shared platforms and organizational standard to avoid redundancy and minimize waste | # of applicable projects utilizing the Standards request process or assessment of existing systems against enterprise needs and scalability | -| Efficiency in spend | Resource allocation and project approaches utilize Agile delivery models and templates | % of Agile Contract [templates](/guides/agile_contracts_pws_template/) | -| Expediting quality and continuous delivery | Engineering and development practices utilize the DevSecOps delivery models and tools | Capture # of applicable processes / workflows identified vs. actually automated Survey assessment of development environment setup and access to development team % of reported defects against a system/product | -| Resources allocated to high priority and business value items only | Encourage development of strategic and high-priority work (e.g. build based on need, ensure just-in-time development to effectively respond to user needs) | Projects approval time report for kick-off vs. actual work begin date % or number of used items captured via customer survey, Web analytics, # of Stories – Planned vs. Stories – Actual | - -Additionally, the organization can utilize these measurement examples to create a clear picture of how these new success measures are performing in the current state in order to establish a baseline that will enable it to draw an accurate before-and-after comparison. - - -## Summary - -While traditional project management intends to track the exact delivery of upfront specifications as efficiency and direct project success, Agile frameworks respond to non-traditional success factors such as speed and delivering a product that maximizes business value. The spending and return in Agile however, can not be achieved by minimizing change to requirements and measuring success by following and delivering set specifications to a T. In an Agile organization, success is better realized through fast delivery of solutions that engage the business to incorporate evolving requirements that meet the business needs as quickly as possible. Applying the right balance of investment and return expectation through delivering the right / quality result within the allowable risk factors is what will ultimately lead to optimal returns and project / product success. - - -## Additional Reference - -* [How to Measure Scrum Success](https://www.scrumalliance.org/agile-resources/how-to-measure-scrum-success) -* [An Operating Model for a Company-wide Agile Development](http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/an-operating-model-for-company-wide-agile-development) -* [Agile & DevOps Management: Agile Metrics – Measuring What Actually Matters](https://blog.versionone.com/agile-metrics-measuring-what-actually-matters/) diff --git a/content/guides/meeting_norms.md b/content/guides/meeting_norms.md deleted file mode 100644 index 00775cd7..00000000 --- a/content/guides/meeting_norms.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Meeting norms -category: Team ---- - -"In any collaborative work environment, the meeting is the main component of office life. But -although meetings are the primary mechanism through which decisions get made, they are also the -standard complaint of many \[employees\]*." - -Here are few norms to consider: - -1. The default meeting time limit should be 25mins allowing for a 5min buffer to get to the next meeting, take a break, check messages, etc. -2. All meeting invites should include a room and virtual option (Google Hangout is easiest but Adobe works too). Cameras on should be first option, then turn off later if bandwidth is a concern. There is a way to add a dial-in to Google Hangouts. -3. Meetings should have purpose. What is it you want to discuss and what is expected of each member? If there is something to do before the meeting, then let people know. -4. Meetings should have actionable output. What are we taking away from this and who is going to do it? (For #3 and #4, the meeting owner should create an agenda, but put it in the notes. Don't over do this, keep it simple, and use it in the meeting to stay on task.) -5. Not everyone needs to come to meetings, so determine who the important players are and try to keep the size to around five to seven people. Consider meetings as team collaboration events, not just speaking engagements or open-ended discussion (unless stated up front, but still set boundaries). -6. No meeting invites should be sent without all of the previous five items in the invite. - -\* [Further reading](https://hbr.org/2016/09/use-subtle-cues-to-encourage-better-meetings) diff --git a/content/guides/onboarding.md b/content/guides/onboarding.md deleted file mode 100644 index 5fa1d6b7..00000000 --- a/content/guides/onboarding.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Onboarding -category: Team ---- - -New CTO team members will want to consider the following when onboarding: - -| Task | Description | -|-|-| -| Attend GSA Orientation | This is scheduled by your HR contact. -| Receive your laptop, badge, and phone | You'll receive these at orientation if attending in person. -| Change your ENT (enterprise) password | This is your password for signing into systems administered by GSA, including your email, calendar, and Google Drive. You'll receive instructions via email. -| Login in to your email| GSA uses Gmail to send and receive email. Access this at [email.gsa.gov](http://email.gsa.gov/). -| Setup 2 Factor Authentication | 2FA is setup to increase security with GSA applications. You may need to contact the Access Card Team to update your contact info so that access codes are sent using the best delivery method for you. -| Register for Horizon VDI | Horizon gives you access to your GSA network drives, email, and most GSA resources when you're not in the office. Visit the Horizon page on GSA Insite. -| Setup GitHub account | Follow GSA's [implementation and administration guide](https://github.com/GSA/GitHub-Administration) and 18F's [Open Source Style Guide](https://pages.18f.gov/open-source-guide/). | -| Get JIRA access | JIRA is used to manage project visibility within the CTO's team. Access is granted by an administrator. -| Confirm CHRIS account | CHRIS allows you to access your employee records. Your CHRIS account lets you access your personnel file. This may take 4-6 weeks. -| Sign in to Employee Express | This allows you to access your payroll information and will be available after your first paycheck. -| Review benefits | GSA requires that you enroll in many of the benefits offered to you within the first 60 days of work. Otherwise, you’ll have to wait for Open Season. | -| Login to ALOHA | Please use ALOHA to request sick leave and annual leave. -| Obtain access to Salesforce | Salesforce is used to access a wide variety of GSA services. Access information will be emailed to you. -| Create performance standards | Work with your supervisor to establish a set of standards for your performance plan. -| Create an IDP | Create an IDP to identify training that will help you achieve your long-term professional goals. This is done in Salesforce. -| Complete mandatory training in OLU | All General Services Administration (GSA) employees are required to take mandatory training courses providing critical information about how we work in the federal space. To take these courses, please log into GSA’s Online University (OLU). -| Apply for a travel card | After completing GSA Travel Card Training, apply for a travel card. You’ll use your travel card to pay for expenses incurred during government travel. -| Request access to Concur | Concur is the system GSA employees use to book official travel and pay for flights. diff --git a/content/guides/opensource.md b/content/guides/opensource.md deleted file mode 100644 index a456b0ee..00000000 --- a/content/guides/opensource.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: Open Source Code -category: Development ---- - -We are currently developing our internal policy and inventorying all of our code repos for publication on [code.gov](https://code.gov/). More information will be posted here soon on our progress in complying with [M-16-21](https://sourcecode.cio.gov/) and contributing to an open coding ecosystem. - -The [Open Source website](https://open.gsa.gov/code/) will be a site to spread our knowledge of Open Source Software (OSS) when possible with recently being asked to share our policy with all CFO Act agencies. Agencies are considering our policy as they develop theirs. - -We believe in being "open first" with working to realize 100% open source code across the Agency. While we may be a little ways away from being fully 100% open source, we take pride in being the government (and industry) standard for open sourcing. - -We have a few things underway, including the automation of OSS inventory and review [files in the repository](https://open.gsa.gov/oss-implementation/) diff --git a/content/guides/popular_approaches.md b/content/guides/popular_approaches.md deleted file mode 100644 index 2b201c3f..00000000 --- a/content/guides/popular_approaches.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: Popular Approaches to Agile Adoption -category: Agile ---- - -While Agile itself is a mindset, there are a number of popular approaches to creating an Agile environment. DevOps, Extreme Programming (XP), Kanban, Lean frameworks, SAFe, Scrum, Test-driven Development (TDD), as well as many others are used extensively to promote Agile practices primarily within software development. In GSA IT, we are actively using both Scrum and Kanban. - - -## What is Scrum? - -Scrum provides a process, or framework, for complex projects and can be “deceptively simple.” Currently, it is the most popular Agile approach in use and encourages high-performing, cross-functional teams. While it was originally formalized for software development projects, Scrum works well for any complex, innovative scope of work. - -Scrum is neither synonymous with Agile nor with an "[increment](/guides/glossary/#increments)" (i.e. a Sprint / Iteration); it is not a tool (i.e. JIRA, Rally, etc.), but the Scrum process can be supported by one. - - -### Scrum Values - -**Focus.** Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. - -**Openness.** As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed. - -**Courage.** Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. - -**Commitment.** Because we have great control over our own destiny, we are more committed to success. - -**Respect.** As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect. - - -### Scrum Ceremonies - -Typical team Scrum Ceremonies include: - -* Release Planning (also Pilot / Project Kickoff) -* Sprint Planning -* Sprint Review -* Sprint Retrospective -* Daily Standup -* Sprint (or Iteration) Demo -* Lessons Learned - -Most ceremonies are specifically for the core Scrum Team, however, Release Planning and Sprint Demos should include key Stakeholders and SMEs (as needed). - - -### Common Scrum Terms - -Some common Scrum terms include: - -* Release Trains -* Sprint -* Product Backlog -* Sprint Backlog -* Story Cards (depends on the tool) -* Potentially Shippable Product - - -### Scrum Roles - -The **Scrum Master** is the facilitator of the Agile process and protects the team; they allow the team to self-organize and make changes quickly. The Scrum Master also manages the process for how information is exchanged, helps the team by removing impediments, and essentially functions as “The Coach” of the team. - -The **Product Owner** is responsible for communicating product vision. They prioritize the Product Backlog and clarify requirements for the team. The Product Owner makes the decision to accept or reject each product increment and whether or not it is “shippable." - -The **Scrum Team** is a cross-functional team. They negotiate commitments with the Product Owner and have autonomy regarding how to reach those commitments. The Scrum Team is intensely collaborative and should be composed of no more than three to nine members. - - -### Getting Started with Scrum - -According to [All About Agile](http://www.allaboutagile.com/), the following steps are recommended for “[getting started](http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps/)” with Scrum: - -**Step #1: Get your product backlog in order!** -Identify the high-level requirements for the effort and begin organizing them into Epics (groups of features) and Stories (a specific feature). - -**Step #2: How to estimate your product backlog** -Determine the relative size of your backlog items and estimate the level of effort. - -**Step #3: Sprint Grooming** -Clarify requirements that will be worked on in the upcoming sprint. - -**Step #4: Sprint Planning** -Task requirements and add pointed estimates. Ensure cards meet the [Definition of Ready (DoR)](/guides/glossary/#definition-of-ready) prior to adding them to the Sprint Backlog. - -**Step #5: Create a collaborative workspace** -This can be a shared folder space in Google Drive or a Confluence space in JIRA. - -**Step #6: Sprint!** -Go forth and iterate! Continuously refine and groom requirements as needed. Only bring in work that is achievable during the sprint. - -**Step #7: Stand up and be counted!** -Daily Standups should focus on “what you did yesterday, what you are doing today, and whether you have any blockers / impediments.” - -**Step #8: Track progress with a daily burndown chart** -Progress at the end of the sprint is reflected in the burndown chart and reviewed during the Sprint Demo. - -**Step #9: Finish when you said you would** -In the Sprint Review, reflect on the work accomplished and whether the work completed met the [Definition of Done (DoD)](/guides/glossary/#definition-of-done). - -**Step #10: Review, reflect, repeat…** -Conduct a Sprint Retrospective with the Scrum Team, Product Owner, and Scrum Master to reflect on what went well during the sprint and what can be improved. Check out [TastyCupcakes](http://tastycupcakes.org/category/agile/) for suggested Agile retrospective activities. - - -## What is Kanban? - -Kanban is a process that can be thought of as a pipeline; feature requests entering one end and improved products from the other, encouraging better communication through visual management. A Japanese term, Kanban means a “visual signal” or “card.” Most notably, Toyota line-workers used a Kanban (i.e. an actual card) to signal steps in their manufacturing process. The system’s highly visual nature allowed teams to communicate more easily on what work needed to be done and when. Through its standardized cues and refined processes, the line-workers were better able to reduce waste and maximize value / delivery. - -When setting up a Kanban Team, the Scrum Master and Product Owner roles can be leveraged to support and provide direction for the team. Additionally, the Kanban Team can also use Sprint Planning and Sprint Retrospective activities to aid continuous improvement. - -{{
}} - - -### Getting Started with Kanban - -According to the [Kanban Blog](http://kanbanblog.com/), the following steps are recommended for “[getting started](http://kanbanblog.com/explained/GettingStarted.html)” with Kanban: - -**Step #1: Map the value stream (or development process)** -Identify where feature ideas come from and what are all the steps that the idea goes through until it is sitting in the hands of the end user. - -**Step #2: Define the start and end points for the Kanban system** -Start and end points (i.e. Definition of Done) should preferably be where you have political control. Don't worry too much about starting with a narrow focus, as people outside the span will soon ask to join in. - -**Step #3: Agree** -Determine the initial WIP limits and policies for changing or temporarily breaking them (i.e. “Team Norms”). Define the process for prioritizing and selecting features as well as the policies for different classes of service (e.g. "standard", "expedite", "fixed delivery date"). Determine estimates and when choosing work, define which will be selected first through prioritization. There should also be definition around the frequency of reviews. - -**Step #4: Draw up a Kanban board** -All you need is a whiteboard and some Post-It™ notes. Don't spend too much time making it look beautiful because it will almost certainly evolve. However, the Kanban process can be also supported through tools like JIRA, etc. - -**Step #5: Start using it!** -Be sure to keep work visible and communicate progress. Whether using a whiteboard or tool, ensure progress is continuously updated and reflective of current status. - -**Step #6: Empirically adjust over time** -Use your Sprint Retrospectives to identify areas of improvement for the Team. - - -## Good Reads - -These are good references when setting up Agile Teams: - -### Setting Up Agile Teams - -* [3 Key Steps to Building an Agile Team](https://www.cprime.com/2014/04/3-key-steps-to-building-an-agile-team/) -* [An Operating Model for Company-Wide Agile Development](http://www.mckinsey.com/business-functions/business-technology/our-insights/an-operating-model-for-company-wide-agile-development) -* [Building an Agile Team](https://www.infoq.com/articles/building-an-agile-team) -* [Top Ten Mistakes Made by New Agile Teams](https://help.rallydev.com/top-10-mistakes-teams) -* [Who is Watching After Your Agile Money?](http://www.cio.com/article/3085450/cio-role/who-is-watching-after-your-agile-money.html) - -### Scrum Teams - -* [Pigs & Chickens](http://searchsoftwarequality.techtarget.com/definition/pigs-and-chickens) -* [Scrum Framework](https://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/) -* [Scrum Is, Scrum Is Not](https://kenschwaber.wordpress.com/2011/08/11/scrum-is-scrum-is-not-2/) -* [Scrum Reference Card](http://scrumreferencecard.com/scrum-reference-card/) -* [Why Scrum?](https://www.scrumalliance.org/why-scrum) - -### Kanban Teams - -* [Everyday Kanban](http://www.everydaykanban.com/what-is-kanban) -* [Kanban Blog](http://kanbanblog.com/) -* [Kanban Explained](http://kanbanblog.com/explained/) -* [LeanKit](https://leankit.com/learn/kanban/what-is-kanban/) diff --git a/content/guides/requirements_complete.md b/content/guides/requirements_complete.md index 90518343..46a4ee63 100644 --- a/content/guides/requirements_complete.md +++ b/content/guides/requirements_complete.md @@ -25,7 +25,7 @@ Suggested user story criteria for meeting the [Definition of Ready (DoR)](/guide ## Definition of Done (DoD) -Once a requirement is ready, the Team must agree to the steps necessary to accomplish it. Throughout each [status](/guides/visibility_and_status/) phase of development (typically represented by a column on a whiteboard or in a tool), the “rules” for passing it along to the next phase should also be clearly defined (e.g. the need for work to be reviewed by a peer prior to being sent to the next phase). +Once a requirement is ready, the Team must agree to the steps necessary to accomplish it. Throughout each phase of development (typically represented by a column on a whiteboard or in a tool), the “rules” for passing it along to the next phase should also be clearly defined (e.g. the need for work to be reviewed by a peer prior to being sent to the next phase). Additionally, a Team may identify other needs based on the type of requirement that should be met, including specific testing needs (i.e. performance testing, penetration testing, etc.), that are necessary to call the user story done. diff --git a/content/guides/tiger_teams.md b/content/guides/tiger_teams.md deleted file mode 100644 index 902a7e55..00000000 --- a/content/guides/tiger_teams.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Running Tiger Teams -category: Team ---- - -Tiger Teams are cross-functional teams pulled together for a period of time to address a critical issue. They are often formed when an IT issue is impacting customers and the most likely solutions have already been tried without success. A typical example would be that a critical application is running slowly, and a team is formed with representatives from the network, infrastructure, development, and database groups. The team schedules a series of meetings to work through an issue until a root cause is determined and a solution is implemented. - - -## Potential Risks To Be Avoided - -If not planned properly, Tiger Teams can fall prey to some of these risks: - -* The symptoms of an issue are not clearly defined up front, and sometimes are understood differently by members of the team. -* The team immediately starts trying short term fixes -- sometimes multiple fixes at the same time. A common refrain is “Just a second...try it now.” (Think of Brent from the early chapters of _The Phoenix Project_.) -* Every meeting chases a different symptom, with no strategic direction. -* Once the initial emergency is over, everyone stops attending meetings and the team isn’t always sure what fixed the issue. -* There is no time spent to document the lessons learned or understand the root cause. -* Scope creep can occur: discussion wanders to other topics beyond the original purpose. - - -## A More Effective Approach - -Tiger Teams can be considered effective if the primary issue is resolved and the root causes are shared widely across the organization. The following is an approach to meet those ends. (Remember this assumes that the most likely solutions have already been tried without success.) - -1. Take time to observe the symptoms and their impacts. Agree to a consensus on the current condition (preferably from the perspective of the end user). - - **List of Symptoms** - - * Symptom - * Observed when - * Impact of the symptom - -2. Identify possible root causes. Sources of information include: - - * Previous documentation from using this process - * Bug tracking, help desk, and ticketing systems - * Collective memory of organization, Slack channels, and email listservs - * Online forums, books, articles - -3. Develop a list of tests to validate or invalidate the root causes. **Realize that these are tests, not solutions. It is possible that a test could be an actual fix, but the goal here is to identify the root cause.** - - **List of Possible Tests** - - * If the root cause is... - * ...We can perform this test - * Environment this can be tested in - * Result that confirms root cause - * Result that eliminates root cause - -4. **Decide which tests to perform.** Prioritize the list using some of the following factors: - - * Most likely to identify the root cause - * Quickest to perform - * Least expensive to perform - * Least impact to users to perform - * Can be performed in environment most closely matching production - * Biggest worry (most severe impact to the organization if it’s confirmed) - -5. **Begin testing.** Once the list is prioritized, go through the following cycle until the root cause is confirmed: - - * Run one test. - * Document the results of the test. - * Determine if test results confirm a root cause. - * If the root cause is not identified, back the changes out of the system and continue to the next item. - -6. Once the root cause is identified, develop a list of possible solutions: - - **List of Possible Solutions** - - * Because the root cause is... - * ...One possible solution is... - * Benefits - * Risks - * Monetary cost - * We will know this solution solves the root cause when... - * Period of time needed to validate - -7. As a group, review this list and agree to the solution. If a solution is left in place from the testing, it still needs agreement from the team that this is the correct solution. - -8. When the solution is identified, finish the process with these steps (following change management policies): - - * Allocate funding (if required). - * Perform appropriate backups and document rollback plan. - * Schedule the implementation. - * Implement the solution. - * Validate the results against the solution definition. This may include observation for a period of time identified in step 6. - * Consider how it can be implemented across the enterprise for maximum benefit and prevention of future emergencies through configuration and automation (or procedures as a last result). Assign an owner to get this applied and set a date for a follow up report to the team or management. - -9. Finally, document the result: - - **Solutions Documentation** - - * Root cause - * Symptoms observed - * Potential root causes evaluated and discarded - * Solution - * Value to the rest of the enterprise (reusability) - - -This information becomes the basis of a knowledge store to consult in the future before the next Tiger Team is formed. - - -## Related Methodologies - -This process is consistent with the [Improvement Kata](http://www.methodsandtools.com/archive/toyotakata.php), and its use of the Plan-Do-Check-Act (PDCA) cycle. - - -## Future Improvements - -This guide is a start, but there is plenty of room for improvement, including - * Sharing standardized templates for root cause analysis and other analysis in this process. - * Providing a searchable repository for the outcomes of this process. diff --git a/content/guides/understanding_differences_agile_devsecops.md b/content/guides/understanding_differences_agile_devsecops.md deleted file mode 100644 index 61ff1255..00000000 --- a/content/guides/understanding_differences_agile_devsecops.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Understanding the Differences Between Agile & DevSecOps - from a Business Perspective -category: DevSecOps ---- - -In GSA IT, we examine how Agile and DevSecOps address different aspects of the delivery process. In terms of software development, **Agile** improves the process of delivery; encouraging changes in the functions and practices of the Business and Development teams to better produce the project / product envisioned by the end-user, or customer. **DevSecOps** improves the lead time and frequency of delivery outcomes through enhanced engineering practices; promoting a more cohesive collaboration between Development, Security, and Operations teams as they work towards continuous integration and delivery. - - -## Understanding the Differences - -Both Agile and DevSecOps can be implemented to promote change and collaboration within their respective domains, resulting in a cultural shift in the practices of the individuals implementing them. In an ideal environment, an organization would employ *both* Agile and DevSecOps practices, however, it is important to note that DevSecOps can be implemented in ***any*** environment - Agile or otherwise. - -Remember, [Agile is a mindset](/guides/popular_approaches/); its encompassed values promote a cultural shift in the organization and its departmental functions, project management practices, and product development. Likewise, [DevOps](/guides/what_is_devops/) also requires a cultural shift. - -{{
}} - -It focuses primarily on the frequency of delivery, pushing past departmental lines and calling for collaboration between Development and Operations for more effective planning, design, and release of projects / products. Further, by incorporating [Security](http://www.devsecops.org/) into the coding process (i.e. DevSecOps), loopholes and weaknesses are exposed early on so that remediation actions can be implemented. - -{{
}} - -As with Agile frameworks, DevSecOps incorporates lean, synergistic practices, like [Continuous Integration](/guides/glossary/#continuous-integration-ci) and [Continuous Delivery](/guides/glossary/#continuous-delivery-cd), that encourage and support frequent code check-in, version control, sensible test automation, continuous low-risk releases and feedback, often through a number of electronic tools. Within a DevSecOps environment, the Business can benefit from such practices by saving dollars and resources through improved operations, reduced re-work, increased quality through automated testing and monitoring, and projects / products delivered early and often with less cycle time to the customer or end-user. - - -## Supporting a DevSecOps Culture - -Regardless of their differing focal points in the cycle of delivery, both Agile and DevSecOps share similar goals of eliminating silos, promoting collaboration and teamwork, and providing better, faster delivery. Though DevSecOps is driven by the “engineering” functions of Development, Security, and Operations, Business support can enhance the DevSecOps process. - -Business support begins with understanding how work flows throughout the organizational level. As [The Phoenix Project](https://uptakedigital.zendesk.com/hc/en-us/articles/115000524374-4-Types-of-Work-in-IT-The-Phoenix-Project-) states, there are **four types of work** - *“business projects, internal projects, operational changes, and unplanned work.”* As an organization builds their understanding of their work, they can better manage coordination and uncover the restraints that impact their efforts. - -At the Team level, that coordination ensures Operations and Security team members are engaged with Development from the *very beginning* of an effort; an engagement championed by the Business role leading the project / product. The organizational knowledge of potential restraints or impacts to an effort strengthens the team’s ability to: - -* Improve delivery of projects -* Better manage outages & compliance, and -* Limit work-in-progress (WIP) - -Moreover, by incorporating Agile practices, the Business can better ensure prioritized work is fed into DevSecOps continuous release cycles. They can better plan for and reflect Development team member’s engagement in coordinated efforts on the team’s working boards, further ensuring visibility and transparency of the entire delivery cycle. - - -## Good Reads - -These are good references for understanding Agile & DevSecOps: - -* [10 Deep DevOps Thoughts From Chef’s Jez Humble](https://newrelic.com/blog/best-practices/devops-jez-humble) -* [Agile Vs. DevOps: 10 Ways They're Different](http://www.informationweek.com/devops/agile-vs-devops-10-ways-theyre-different/d/d-id/1326121) -* [DevOps.com](https://devops.com/) -* [DevSecOps.org](http://www.devsecops.org/) -* [Continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) -* [How are DevOps and Agile different?](https://www.quora.com/How-are-DevOps-and-Agile-different) -* [How are Lean, Agile, and Devops related to each other?](http://www.agileweboperations.com/lean-agile-devops-related) -* [4 Types of Work in IT (The Phoenix Project)](https://uptakedigital.zendesk.com/hc/en-us/articles/115000524374-4-Types-of-Work-in-IT-The-Phoenix-Project-) -* [ShiwaForce: What is DevOps?](https://www.shiwaforce.com/mi-az-devops/) -* [The Agile Admin: What is DevOps?](https://theagileadmin.com/what-is-devops/) -* [The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3/ref=dp_kinw_strp_1) -* [The Phoenix Project](http://www.itrevolution.com/book/the-phoenix-project/) diff --git a/content/guides/us_web_design_system.md b/content/guides/us_web_design_system.md deleted file mode 100644 index 539e39dd..00000000 --- a/content/guides/us_web_design_system.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: U.S. Web Design System -category: Design ---- - -The [U.S. Web Design System](https://designsystem.digital.gov/) (USWDS)—formerly known as the U.S. Web Design Standards—is a library of design guidelines and code to help government developers and designers quickly create trustworthy, accessible, and consistent digital government services. - -Right now, when the American people go online to access government services, they're often met with confusing navigation systems, a cacophony of visual brands and inconsistent interaction patterns. Dedicated federal employees are striving to build helpful digital tools, but our work happens in silos, under unique brands and programs. As a result, we spend a lot of time "reinventing the wheel" - recreating common patterns such as buttons, forms, and search bars - over and over again. At the end of the day, we're creating poor user experiences, and wasting American taxpayer dollars in solving the same problems again and again. So we asked ourselves: **Could we create a shared set of tools to provide consistent, beautiful, and easy-to-use government websites?** Thus the Standards was born. - -USWDS allows designers and developers to have a leg-up in updating existing services, or quickly create new websites, to have a modern, consistent feel. They are open source, free to use, and comply with Section 508 and OMB guidance. Currently they are being used on **100 government sites** that collectively **reach more than 26 million users a month**! - -USWDS offers code and guidelines for forms, typography, buttons, alerts and more. The latest release, 1.0, is the culmination of more than a year and a half of design and development through more than 20 versions. And there are more than 3,400 folks, inside and outside government, [following the project on GitHub and contributing back to the code](https://github.com/uswds/uswds). - -[We're looking to expand](https://18f.gsa.gov/2016/12/22/charting-the-future-of-the-draft-us-web-design-standards/) with more mobile performance-optimized components and continued user research to guide our future product decisions. We’re also looking at building more advanced components like mapping and data visualizations. - -Our team is also available to work closely with you to develop custom features or train teams on implementing the System. If you'd like to talk to the team or explore a partnership, please contact us at [uswds@gsa.gov](mailto:uswds@gsa.gov). If you've got more general questions, you can join us in our new [public Slack channel](https://chat.18f.gov/) or if you have feature requests or find a bug, [please file an issue in our Github tracker](https://github.com/uswds/uswds/issues). This project is maintained by the [Office of Products and Programs](https://www.gsa.gov/about-us/organization/federal-acquisition-service/technology-transformation-services/office-of-products-and-programs), an office within the [Technology Transformation Services](http://www.gsa.gov/tts) (TTS) at GSA. diff --git a/content/guides/use_case_examples.md b/content/guides/use_case_examples.md deleted file mode 100644 index 905dc4e8..00000000 --- a/content/guides/use_case_examples.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Use Case Examples -category: Agile ---- -[Use Cases](/guides/glossary/#use-cases) can be effective when engaging business users / user groups to perform acceptance testing for a project’s [user stories](/guides/glossary/#user-stories). While the Product Owner must provide final sign-off on the work the Scrum Team completes within a sprint, they can leverage business users for acceptance testing by providing use cases to help expose defects and garner feedback. - -In acceptance testing, use cases provide a user (i.e. tester) direction without leading. Use Cases provide a sequence of steps in business terms, that describe the “happy path” for a specific interaction. Unlike system test cases, the use case interaction is defined in terms of the user, describing the user actions and experience versus the system inputs and outputs. The user compares their experience to the defined Success Criteria, documenting success or failure, along with any results. Results may expose bugs, defects, misspellings, updates to the user interface or process flow, or even new user stories identified. - -[Download this Sample Use Case Document](/assets/cms/media/draftusecasetemplate.xlsx) \ No newline at end of file diff --git a/content/guides/ux_design.md b/content/guides/ux_design.md deleted file mode 100644 index 6c5037f0..00000000 --- a/content/guides/ux_design.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: UX Design -category: Design ---- - -"User experience design most frequently defines a sequence of interactions between a user (individual person) and a system, virtual or physical, designed to meet or support user needs and goals, primarily, while also satisfying systems requirements and organizational objectives ([Wikipedia](https://en.wikipedia.org/wiki/User_experience_design))." - -UX Designers focus on meeting with the end users and trying to understand the world through the user's eyes as they wish to interact with a system. The CTO's office has largely been using UX Design to create [personas](https://en.wikipedia.org/wiki/Persona_(user_experience)) and [wireframes](https://en.wikipedia.org/wiki/Website_wireframe) although there are many more ways to get to end user needs (see [18F's design methods](https://methods.18f.gov/)). - -As we mature our Digital Service and modern development practices, we will continue to add more content here with instructions on how to carry-out UX design in the organization. No doubt a much needed service to address end user needs and the representations of such needs with front-end development. - -One thing to check out is the GSA-maintained [U.S. Web Design System](https://designsystem.digital.gov/), which enhance user experiences on government sites by offering a consistent, and trusted, look and feel. The Standards offer open-source, quick-to-download code and assets that comply with Section 508 guidance, support mobile first practices, and adhere to current OMB guidance. The Standards are currently operating on hundreds of government sites, with a combined monthly audience of more than 26 million users! If you have requests for features or find bugs, please submit them to the [GitHub repo](https://github.com/uswds/uswds), and join the conversation and community on our public [Slack channel](https://chat.18f.gov/). diff --git a/content/guides/visibility_and_status.md b/content/guides/visibility_and_status.md deleted file mode 100644 index 89d1fcd4..00000000 --- a/content/guides/visibility_and_status.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Visibility & Status in an Agile Environment -category: Agile ---- - -As organizations and teams work towards becoming more Agile, the nature of communication and reporting must change. In successful Agile environments, information must be readily available and visible in order to support working relationships and decision-making. - - -## How are visibility and status communicated differently? - -Visibility provides **transparency** into the development process. It is the ability to see progress at any point and determine the distance to completion of a goal. Visibility provides **status** of not only the progress of the project, but the product itself. - -In an Agile environment, **visibility** is not only privy to key stakeholders, but also end users as they engage in a continuous cycle of feedback, acceptance testing, and iteration demos. Insight into the development process enables “Responding to change over following a plan” ([Agile Manifesto](http://agilemanifesto.org/)) and is inherent to most Agile frameworks, like Scrum, Kanban, etc. - -**Communication** in an Agile environment should be consistent, not limited to a scheduled status report or meeting. Further, as Joseph Flahiff notes in [Integrating Agile into a Waterfall World](https://www.infoq.com/articles/agile-in-waterfall-world), we must “constantly communicate the boundary between the project and the product” so that we ensure value is clear and we remain focused on the “delivery of the project, within the context of the product.” - - -## What information is important in communicating status? - -Well, it depends. What information is needed to support the team? What information will convey the team’s internal, or external, impacts or dependencies? Most importantly, what information will drive management / executive decisions, including the project schedule, time to market, etc.? - -Central to Agile adoption is identifying what information is key for both team and executive decision-making as well as conveying it in an Agile format. An ongoing challenge is that executives are used to seeing project and product status via traditional artifacts (i.e. weekly or monthly status reports, etc.) and often waste time trying to define *how* to communicate status. [Ian Knox](http://www.networkworld.com/article/2183797/tech-primers/controlling-agile-development-in-a-project-portfolio-framework.html) says, “Instead, executives need to learn how to interpret project status from an Agile team rather than impose reporting requirements that are not consistent with Agile." Communication status should focus more on the progress of a working product increment, or software. Rigby, et. al further state that executives should “practice Agile at the top” by creating an environment that focuses on improving productivity and morale, empowering others, identifying how to overcome common challenges, in addition to recognizing and stopping behaviors that impede Agile teams. - -At the project level, status should revolve around the prioritization of tasks and quick resolve of impediments. The use of Scrum ceremonies can support consistent communication and transparency of day-to-day activities through standups, iteration demos, iteration reviews, and even visibility tools. Beyond that, status becomes more transparent as executives focus on removing functional silos, prioritizing backlog items, establishing and coordinating Agile teams elsewhere in the organization to address the highest priorities, and systematically eliminating barriers to their success ([Rigby, et al](https://hbr.org/2016/05/embracing-agile)). - - -## What tools can I use to support visibility and transparency? - -Remember, Agile is a mindset - it is not a process or tool. Attitudes, business processes, and approaches to projects, and products, must change first. Most importantly, C-suite executives should encourage the adoption process, keep the pace [for the organization], and identify management activities that can be supported through Agile adoption ([Rigby, et al](https://hbr.org/2016/05/embracing-agile)). Further, managers and executives should provide timely feedback and business decisions, and ensure appropriate removal of team impediments. - -With these supporting changes in place, Agile teams can incorporate a working board, using a whiteboard with post-it notes or index cards to convey status. Teams can also use virtual tracking or visibility tools such as JIRA, Rally, VersionOne, etc. to display their working boards in electronic format. While working boards should be updated as their status changes, communication regarding progress is guaranteed during standups, iteration demos and reviews ([Scrum](https://www.scrum.org/)). Whether on a specific wall, or in a room, or even a shared link, the team’s progress is visible and transparent to all. - - -## Good Reads - -These are good references for understanding the visibility and status in an Agile environment: - -* [4 Benefits of a Transparent Work Environment](https://www.liquidplanner.com/blog/why-transparency-matters-and-how-to-make-it-happen/) -* [Controlling agile development in a project portfolio framework](http://www.networkworld.com/article/2183797/tech-primers/controlling-agile-development-in-a-project-portfolio-framework.html) -* [Embracing Agile](https://hbr.org/2016/05/embracing-agile) -* [Integrating Agile into a Waterfall World](https://www.infoq.com/articles/agile-in-waterfall-world) -* [Why is visibility so important in scrum / any agile team?](https://charlenedickson.wordpress.com/why-is-visibility-so-important-in-scrum-any-agile-team/) diff --git a/content/guides/what_is_devops.md b/content/guides/what_is_devops.md deleted file mode 100644 index 0fa1ef6b..00000000 --- a/content/guides/what_is_devops.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: What is DevOps? -category: DevSecOps ---- - -DevOps is best described as the conventions and practices that create collaborative and communicative partnership between development and operation groups. These practices incorporate two concepts that contribute to the automation of the process of software delivery and infrastructure changes. - -{{
}} - -{{
}} - - -## Continuous Integration (CI) - -Continuous Integration (CI) is the practice of developers ensuring that code is frequently checked in and integration tested with its dependencies with each check-in. Based on the methods and practices developed by Rational (IBM) programmer, Grady Booth, continuous integration has provided the foundation for a number of subsequent frameworks, including Extreme Programming (XP). - -According to the [Agile Alliance](https://www.agilealliance.org/glossary/continuous-integration/), the goals of CI are “to minimize the duration and effort required by each integration episode and to be able to deliver a product version suitable for release at any moment.” Achievement of these goals is supported through not only automation, but also the use of version control tools (e.g. [SVN, GIT, Mercurial, etc.](https://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/)) and team working agreements that promote continuous code integration. - - -## Continuous Delivery (CD) - -Continuous Delivery (CD), according to [ThoughtWorks](https://www.thoughtworks.com/continuous-delivery), can also help large organizations become lean, agile, and innovative. “Through reliable, low-risk releases, Continuous Delivery makes it possible to continuously adapt software in line with user feedback, shifts in the market and changes to business strategy. Test, support, development and operations work together as one delivery team to automate and streamline the build, test and release process.” - - -## Common DevOps Terms - -[Mind the Product](http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/) has created an informative list of useful DevOps terminology. The definitions can be found in our [Glossary](/guides/glossary/). - -* Checking in -* CI server -* Development environment -* Deployment pipeline / pipeline -* Green build -* Incremental development -* Integration -* Iterative development -* Master/trunk/mainline -* Production environment -* Red build -* Source repository -* Test automation -* Unit tests - - -## Good Reads - -These are good references for understanding DevOps, Continuous Integration (CI), and Continuous Delivery (CD): - -* [12factor.net: The Twelve-Factor App](https://12factor.net/) -* [2016 Version Control Software Comparison: SVN, Git, Mercurial](https://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/) -* [Best Version Control Systems](https://www.g2crowd.com/categories/version-control-systems) -* [Cloud.gov](https://cloud.gov/) -* [Continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) -* [DevOps.com](https://devops.com/) -* [DevOps Handbook](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002) -* [Gartner and Software Advice examine Agile Lifecycle Management Tools](https://www.infoq.com/news/2015/02/agile-management-tools) -* [MartinFowler.com: ContinuousDelivery](https://martinfowler.com/bliki/ContinuousDelivery.html) -* [ShiwaForce: What is DevOps?](https://www.shiwaforce.com/mi-az-devops/) -* [The Agile Admin: What is DevOps?](https://theagileadmin.com/what-is-devops/) -* [The business case for continuous delivery](https://www.atlassian.com/continuous-delivery/business-case-for-continuous-delivery) -* [The Phoenix Project](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592) -* [The Product Managers’ Guide to Continuous Delivery and DevOps](http://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/) -* [Top 5 open source version control tools for system admins](https://www.getfilecloud.com/blog/2015/02/top-5-open-source-version-control-tools-for-system-admins/#.WHVSSVMrLIU) diff --git a/layouts/guides/list.html b/layouts/guides/list.html index 76ad1cba..4137990b 100644 --- a/layouts/guides/list.html +++ b/layouts/guides/list.html @@ -4,42 +4,17 @@

GSA Tech Guides

- {{ .Content }} - -
- -
-
-
-
- Filter by Category - {{ range .Pages.GroupByParam "category" }} -
- - -
- {{ end }} -
- -
+ {{ .Content }} + {{ range .Pages.GroupByParam "category" }} +
+

{{ .Key }} Guides

+
-
- -
- {{ range .Pages.GroupByParam "category" }} -
-

{{ .Key }} Guides

- -
- {{ end }} -
- -
- + {{ end }}
{{ end }} diff --git a/static/assets/img/guides/API_3_pillars.png b/static/assets/img/guides/API_3_pillars.png deleted file mode 100644 index 9ed52aea..00000000 Binary files a/static/assets/img/guides/API_3_pillars.png and /dev/null differ diff --git a/static/assets/img/guides/AgileOrgs_Location.PNG b/static/assets/img/guides/AgileOrgs_Location.PNG deleted file mode 100644 index 7c9be176..00000000 Binary files a/static/assets/img/guides/AgileOrgs_Location.PNG and /dev/null differ diff --git a/static/assets/img/guides/Agile_Benefits.png b/static/assets/img/guides/Agile_Benefits.png deleted file mode 100644 index 39c2bcc8..00000000 Binary files a/static/assets/img/guides/Agile_Benefits.png and /dev/null differ diff --git a/static/assets/img/guides/Agile_HR.png b/static/assets/img/guides/Agile_HR.png deleted file mode 100644 index a3c6edb4..00000000 Binary files a/static/assets/img/guides/Agile_HR.png and /dev/null differ diff --git a/static/assets/img/guides/Agile_In_PM.png b/static/assets/img/guides/Agile_In_PM.png deleted file mode 100644 index ff813cf5..00000000 Binary files a/static/assets/img/guides/Agile_In_PM.png and /dev/null differ diff --git a/static/assets/img/guides/Agile_Industries.PNG b/static/assets/img/guides/Agile_Industries.PNG deleted file mode 100644 index 72ae2954..00000000 Binary files a/static/assets/img/guides/Agile_Industries.PNG and /dev/null differ diff --git a/static/assets/img/guides/Agile_Methods_Used.PNG b/static/assets/img/guides/Agile_Methods_Used.PNG deleted file mode 100644 index e0e13d85..00000000 Binary files a/static/assets/img/guides/Agile_Methods_Used.PNG and /dev/null differ diff --git a/static/assets/img/guides/Agile_Projects.png b/static/assets/img/guides/Agile_Projects.png deleted file mode 100644 index 11917445..00000000 Binary files a/static/assets/img/guides/Agile_Projects.png and /dev/null differ diff --git a/static/assets/img/guides/Agile_Tools.png b/static/assets/img/guides/Agile_Tools.png deleted file mode 100644 index 9200cbdd..00000000 Binary files a/static/assets/img/guides/Agile_Tools.png and /dev/null differ diff --git a/static/assets/img/guides/AgilevsWaterfallOnepager.PNG b/static/assets/img/guides/AgilevsWaterfallOnepager.PNG deleted file mode 100644 index 6b7020bb..00000000 Binary files a/static/assets/img/guides/AgilevsWaterfallOnepager.PNG and /dev/null differ diff --git a/static/assets/img/guides/BusITCollaboration.png b/static/assets/img/guides/BusITCollaboration.png deleted file mode 100644 index 88b79192..00000000 Binary files a/static/assets/img/guides/BusITCollaboration.png and /dev/null differ diff --git a/static/assets/img/guides/Customer_Collaboration.png b/static/assets/img/guides/Customer_Collaboration.png deleted file mode 100644 index c4d54659..00000000 Binary files a/static/assets/img/guides/Customer_Collaboration.png and /dev/null differ diff --git a/static/assets/img/guides/DevOps_Continuous.png b/static/assets/img/guides/DevOps_Continuous.png deleted file mode 100644 index b36a561a..00000000 Binary files a/static/assets/img/guides/DevOps_Continuous.png and /dev/null differ diff --git a/static/assets/img/guides/DevOps_Integration.png b/static/assets/img/guides/DevOps_Integration.png deleted file mode 100644 index aab9d5bc..00000000 Binary files a/static/assets/img/guides/DevOps_Integration.png and /dev/null differ diff --git a/static/assets/img/guides/DevOps_Tools.png b/static/assets/img/guides/DevOps_Tools.png deleted file mode 100644 index c284022f..00000000 Binary files a/static/assets/img/guides/DevOps_Tools.png and /dev/null differ diff --git a/static/assets/img/guides/DevOps_Utilization.png b/static/assets/img/guides/DevOps_Utilization.png deleted file mode 100644 index e66b4513..00000000 Binary files a/static/assets/img/guides/DevOps_Utilization.png and /dev/null differ diff --git a/static/assets/img/guides/DevSecOps.png b/static/assets/img/guides/DevSecOps.png deleted file mode 100644 index 9943f77e..00000000 Binary files a/static/assets/img/guides/DevSecOps.png and /dev/null differ diff --git a/static/assets/img/guides/EK_Agile.png b/static/assets/img/guides/EK_Agile.png deleted file mode 100644 index 7d2351d1..00000000 Binary files a/static/assets/img/guides/EK_Agile.png and /dev/null differ diff --git a/static/assets/img/guides/EK_Waterfall.png b/static/assets/img/guides/EK_Waterfall.png deleted file mode 100644 index 4d86eb62..00000000 Binary files a/static/assets/img/guides/EK_Waterfall.png and /dev/null differ diff --git a/static/assets/img/guides/EK_Waterfall_Gnatt.png b/static/assets/img/guides/EK_Waterfall_Gnatt.png deleted file mode 100644 index faf39ce7..00000000 Binary files a/static/assets/img/guides/EK_Waterfall_Gnatt.png and /dev/null differ diff --git a/static/assets/img/guides/FSNP.png b/static/assets/img/guides/FSNP.png deleted file mode 100644 index 9eeabb01..00000000 Binary files a/static/assets/img/guides/FSNP.png and /dev/null differ diff --git a/static/assets/img/guides/Fibonacci_Sequence_1.jpg b/static/assets/img/guides/Fibonacci_Sequence_1.jpg deleted file mode 100644 index c17a8c4b..00000000 Binary files a/static/assets/img/guides/Fibonacci_Sequence_1.jpg and /dev/null differ diff --git a/static/assets/img/guides/Fibonacci_Sequence_2.jpg b/static/assets/img/guides/Fibonacci_Sequence_2.jpg deleted file mode 100644 index 971c61de..00000000 Binary files a/static/assets/img/guides/Fibonacci_Sequence_2.jpg and /dev/null differ diff --git a/static/assets/img/guides/FunctionalMgt.png b/static/assets/img/guides/FunctionalMgt.png deleted file mode 100644 index c841a381..00000000 Binary files a/static/assets/img/guides/FunctionalMgt.png and /dev/null differ diff --git a/static/assets/img/guides/Individuals_and_Interactions.png b/static/assets/img/guides/Individuals_and_Interactions.png deleted file mode 100644 index e3251048..00000000 Binary files a/static/assets/img/guides/Individuals_and_Interactions.png and /dev/null differ diff --git a/static/assets/img/guides/InexperiencewithAgile.png b/static/assets/img/guides/InexperiencewithAgile.png deleted file mode 100644 index c460822a..00000000 Binary files a/static/assets/img/guides/InexperiencewithAgile.png and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Backlog_Refinement.png b/static/assets/img/guides/Ken_Rubin_Backlog_Refinement.png deleted file mode 100644 index 32b8f908..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Backlog_Refinement.png and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Daily_Standup.png b/static/assets/img/guides/Ken_Rubin_Daily_Standup.png deleted file mode 100644 index 2271dcb0..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Daily_Standup.png and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Release_Planning.jpg b/static/assets/img/guides/Ken_Rubin_Release_Planning.jpg deleted file mode 100644 index 7d52bcdb..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Release_Planning.jpg and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Sprint_Planning.png b/static/assets/img/guides/Ken_Rubin_Sprint_Planning.png deleted file mode 100644 index 85aa811a..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Sprint_Planning.png and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Sprint_Retrospective.png b/static/assets/img/guides/Ken_Rubin_Sprint_Retrospective.png deleted file mode 100644 index eb3461e5..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Sprint_Retrospective.png and /dev/null differ diff --git a/static/assets/img/guides/Ken_Rubin_Sprint_Review.jpg b/static/assets/img/guides/Ken_Rubin_Sprint_Review.jpg deleted file mode 100644 index 841c913a..00000000 Binary files a/static/assets/img/guides/Ken_Rubin_Sprint_Review.jpg and /dev/null differ diff --git a/static/assets/img/guides/Klimov_FIGURE.png b/static/assets/img/guides/Klimov_FIGURE.png deleted file mode 100644 index cdf37f8a..00000000 Binary files a/static/assets/img/guides/Klimov_FIGURE.png and /dev/null differ diff --git a/static/assets/img/guides/LargeTeamCollaboration.jpg b/static/assets/img/guides/LargeTeamCollaboration.jpg deleted file mode 100644 index f0b39143..00000000 Binary files a/static/assets/img/guides/LargeTeamCollaboration.jpg and /dev/null differ diff --git a/static/assets/img/guides/LeanKit_Kanban_Board.jpg b/static/assets/img/guides/LeanKit_Kanban_Board.jpg deleted file mode 100644 index b04fe33f..00000000 Binary files a/static/assets/img/guides/LeanKit_Kanban_Board.jpg and /dev/null differ diff --git a/static/assets/img/guides/LegacyPMO.png b/static/assets/img/guides/LegacyPMO.png deleted file mode 100644 index 5dcd05ce..00000000 Binary files a/static/assets/img/guides/LegacyPMO.png and /dev/null differ diff --git a/static/assets/img/guides/Mind_the_Product_new_way.png b/static/assets/img/guides/Mind_the_Product_new_way.png deleted file mode 100644 index 63663f50..00000000 Binary files a/static/assets/img/guides/Mind_the_Product_new_way.png and /dev/null differ diff --git a/static/assets/img/guides/Mind_the_Product_old_way.png b/static/assets/img/guides/Mind_the_Product_old_way.png deleted file mode 100644 index 856a1417..00000000 Binary files a/static/assets/img/guides/Mind_the_Product_old_way.png and /dev/null differ diff --git a/static/assets/img/guides/New_Rules_HR.jpg b/static/assets/img/guides/New_Rules_HR.jpg deleted file mode 100644 index c2701803..00000000 Binary files a/static/assets/img/guides/New_Rules_HR.jpg and /dev/null differ diff --git a/static/assets/img/guides/NoMgtSupport.png b/static/assets/img/guides/NoMgtSupport.png deleted file mode 100644 index 229d42ac..00000000 Binary files a/static/assets/img/guides/NoMgtSupport.png and /dev/null differ diff --git a/static/assets/img/guides/OddswithAgile.PNG b/static/assets/img/guides/OddswithAgile.PNG deleted file mode 100644 index 225244c9..00000000 Binary files a/static/assets/img/guides/OddswithAgile.PNG and /dev/null differ diff --git a/static/assets/img/guides/Responding_to_Change.png b/static/assets/img/guides/Responding_to_Change.png deleted file mode 100644 index 0fd6006f..00000000 Binary files a/static/assets/img/guides/Responding_to_Change.png and /dev/null differ diff --git a/static/assets/img/guides/Sample Agile Product Roadmap.png b/static/assets/img/guides/Sample Agile Product Roadmap.png deleted file mode 100644 index 55e95730..00000000 Binary files a/static/assets/img/guides/Sample Agile Product Roadmap.png and /dev/null differ diff --git a/static/assets/img/guides/Sample Traditional Product Roadmap.png b/static/assets/img/guides/Sample Traditional Product Roadmap.png deleted file mode 100644 index e0461a6f..00000000 Binary files a/static/assets/img/guides/Sample Traditional Product Roadmap.png and /dev/null differ diff --git a/static/assets/img/guides/SysDesignMgt.png b/static/assets/img/guides/SysDesignMgt.png deleted file mode 100644 index d9d147d4..00000000 Binary files a/static/assets/img/guides/SysDesignMgt.png and /dev/null differ diff --git a/static/assets/img/guides/TraditionalRolesProgMgt.jpg b/static/assets/img/guides/TraditionalRolesProgMgt.jpg deleted file mode 100644 index 83f991ad..00000000 Binary files a/static/assets/img/guides/TraditionalRolesProgMgt.jpg and /dev/null differ diff --git a/static/assets/img/guides/Working_Software.png b/static/assets/img/guides/Working_Software.png deleted file mode 100644 index f7fda0bb..00000000 Binary files a/static/assets/img/guides/Working_Software.png and /dev/null differ diff --git a/static/assets/img/guides/agile_investment_process.png b/static/assets/img/guides/agile_investment_process.png deleted file mode 100644 index 0b3b44b0..00000000 Binary files a/static/assets/img/guides/agile_investment_process.png and /dev/null differ diff --git a/static/assets/img/guides/agile_investment_process_detail.png b/static/assets/img/guides/agile_investment_process_detail.png deleted file mode 100644 index 2200c2f9..00000000 Binary files a/static/assets/img/guides/agile_investment_process_detail.png and /dev/null differ diff --git a/static/assets/img/guides/agile_investment_roles.png b/static/assets/img/guides/agile_investment_roles.png deleted file mode 100644 index 951e3c57..00000000 Binary files a/static/assets/img/guides/agile_investment_roles.png and /dev/null differ diff --git a/static/assets/img/guides/communities_consensus.png b/static/assets/img/guides/communities_consensus.png deleted file mode 100644 index f3dee94d..00000000 Binary files a/static/assets/img/guides/communities_consensus.png and /dev/null differ diff --git a/static/assets/img/guides/maxresdefault_ed.png b/static/assets/img/guides/maxresdefault_ed.png deleted file mode 100644 index 695921fc..00000000 Binary files a/static/assets/img/guides/maxresdefault_ed.png and /dev/null differ diff --git a/static/assets/img/guides/scrum-team.jpg b/static/assets/img/guides/scrum-team.jpg deleted file mode 100644 index 2c7f4350..00000000 Binary files a/static/assets/img/guides/scrum-team.jpg and /dev/null differ diff --git a/static/assets/img/guides/working_agreement.png b/static/assets/img/guides/working_agreement.png deleted file mode 100644 index 604688d4..00000000 Binary files a/static/assets/img/guides/working_agreement.png and /dev/null differ