Loading

CoP

In the A2F Framework, the Communities of Practice aligns with the Agile Center of Excellence. The Agile CoE provides the guidance and governance to ensure all the Communities of Practices across the different Programs are consistent and facilitates the sharing of good practices across them.

Why Communities of Practice

  1. Communities of practice help connect people in organizations that are scaling their agile delivery.
  2. Communities of practice can support people, build capability, reduce the duplication of work and build better practices.
  3. A mature community will benefit members and the organization.
  4. Communities of practice take time and effort to create.
  5. A community goes through a number of stages as it develops and a self-sustaining community has the best chance of survival.

Communities of practice regularly bring together people who share areas of interest or concerns. They are loose structures that support their members and the organization’s development of those areas. They often form around a specific job role but can also center on a specific area of interest.

Agile Test Automation

Test Automation Strategy

  1. Automation Pyramid.
  2. Planning for Automation.
  3. Automation Frameworks.
  4. Selecting Tests for Automation.
  5. Supporting Process.

Testing & Continuous Integration

  1. Automated Test Cycles (Continuous Testing).
  2. Code Analysis/Metrics.

Automating Story and Feature Testing

  1. Mapping Tests to Automation.
  2. ATDD and BDD Testing Frameworks.
  3. UI Testing Frameworks.

Automation Support for Integration and System Testing

  1. Data Setup and Tear Down.
  2. Data within Automation.
  3. Tools to Support Exploratory Testing.
  4. Tools for Performing Non-Functional Testing.
  5. Virtualization.

Committee: Size should be 6 to 8 people. The group should be composed of QA Leads, automation testers, and DevOp Leads.

CI/CD (Continuous Integration/Continuous Deployment)

Version Control

  1. Developers working in branches.
  2. Trigger CI when merging into main master branch/ trunk.

Continuous Integration

  1. Build
    1. Pull and organize application artifacts and dependencies.
  2. Code Quality
    1. Run unit tests and static code analysis tools to ensure code quality.
  3. Packaging
    1. Assemble application artifacts including dependencies & configuration into deployable validated package.

Infrastructure Automation

  1. Automated provisioning of infrastructure resources & platforms.

Release Automation

  1. Automated application deployment across all runtime environments.

Quality Control & Approvals

  1. Project specific functional testing & production sign-off.

Application Management

  1. Provide instant feedback and diagnostics on deployed application to development and operations teams.

Committee: Size should be 6 to 8 people. The group should be composed of QA Leads, automation testers, and other Development & Content Delivery team members.

Agile Methodology

Agile Playbook

  1. Review feedback and update playbook.
  2. Discuss what Agile development and team processes/practices are not working well and how to improve.

Agile Rollout

  1. Review feedback and update Big Picture.
  2. Discuss what processes/practices for the rollout are not working well and how to improve.

Agile Training

  1. Discuss and implement strategy to train more CU employees on Agile.
  2. Maintain ppt decks and online training videos.

Agile Tooling

  1. APM Tool.
  2. Wikis.
  3. Metrics.
  4. Reporting.
  5. Other Tools.

Committee: Size should be 6 to 8 people. The group should be composed of Product Managers/Owners, Agile Program Manager, Scrum Master/Facilitators, Leads, Architects.

Agile Release Management

  • Release Policy:
    Organizations need to align their strategic goals with the enterprise release. This is the phase in which organizations define the end goals, scope, and principles with regards to adopting the release management processes across the enterprise. The ideal time for charting out a release policy is either before any development activity or during development.
  • Release Planning:
    Based on the release policy guidelines, enterprise release plans are designed and formally approved by senior management. This is not only contains the governance aspects, but also the detailed process designs for implementing releases across the organizations. These plans are generic frameworks that can be tailored by individual Business Units or teams as per their specific requirements.
  • Hardware/Software Design:
    This is the phase where the actual assets required for a release are designed and configured. This may include the application servers, hardware servers, source control tools, build tools etc., that would be required for the build, test and delivery of code. This needs to be done during the development stage and before the testing stages of SDLC.
  • Build & Configure Release:
    This is the phase where the code from development is built using build tools, tested internally to ensure build integrity and finally delivered in target environments.
  • Quality Review:
    During this phase, the quality of the release is assessed by the QA Team. This includes checking that the release meets minimum acceptable standards and business requirements.
  • Release Accepted:
    Once a release has been successfully tested by the QA team, the functional team will validate the results and if everything is good, the release will be approved for deployment in production. Any bugs identified during the QA Review stage will be rejected and sent back to the development team for review and bug fix.
  • Rollout Plan:
    Once a release has been accepted by the QA team, it is ready for deployment in the Production environment where end-users or customers will be able to access the new capabilities released.
  • Communicate and Train:
    Communication and training are critical elements of a service delivery or transition. It is a process by which the clients or end-users are communicated about product feature or service releases and train them to use the new releases.
  • Implement Release:
    In this phase, the release units that were tested in the testing stage of SDLC are deployed in Production environments for live or real-time usage.
  • Verify Implementation:
    It is a good practice to verify a release, each time it is deployed in Production. This is to ensure that the release behaves as expected in the live environment.

Committee: Size should be 6 to 8 people. The group should be composed of senior leadership, QA Leads, Product Managers/Owners, DevOp Leads, Content Delivery & Product team members.

References

Ardichvilli, Alexander; Page, Vaughn; Wentling, Tim (2003). "Motivation and barriers to participation in virtual knowledge sharing in communities of practice".
Journal of knowledge management.

Kimble, Chris; Hildreth, Paul; Bourdon, Isabelle (2008). Communities of Practice: Creating Learning Environments for Educators. Information Age Publishing.

About Me

Sed pellentesque nibh enim, quis euismod enim lacinia nec. Phasellus quam diam, semper in erat eu. Consectetur adipiscing elit. Sed pellentesque nibh enim, quis euismod enim lacinia nec.