Our Process
How We Work
What Is Agile?
An iterative approach to delivering projects. We define units of related work e.g., modules and prioritize them. Then agree on a repetitive delivery schedule e.g., two weeks or a month. Within which we design, develop, test, and deploy the unit of work. Each two week or monthly iteration forms a sprint. Project signoffs and billing are tied to sprints.
Agile Pictogram
Traditional vs Agile Project Management
Image courtesy of association of project management
Why Agile?
- Simplified, human and natural approach to software projects. No need to know every single requirement in detail beforehand, nor a cast-in-stone approach to scope, budget or timelines.
- We deliver value early on, and continue delivering working output every two weeks or monthly.
- No need for hard to achieve, big bang Go-Lives. Go-live every two weeks or every month reduce project risks and pressure.
- Incremental Go-Lives allow for focused prioritization of organizational value drivers, and early ROI.
- Frequent, constant interactions allow for more collaboration and shared vision, purpose.
- Integrating planning with execution creates a working mindset allowing teams to respond and execute effectively.
What are the benefits of agile working?
- Agile approaches empower those involved; build accountability; encourage diversity of ideas; allowing the early release of benefits; and promotion of continuous improvement.
- Agile helps build client and user engagement because changes are incremental and evolutionary rather than revolutionary: it can therefore be effective in supporting cultural change that is critical to the success of most transformation projects.
- Agile allows decision ‘gremlins’ to be tested and rejected early: the tight feedback loops provide benefits in agile that are not as evident in waterfall.
What are the differences between an agile and the typical waterfall approach?
- Customer collaboration (progress, value) over contract (scope, timelines) negotiation.
- Working solutions (software product) over comprehensive documentation.
- Individuals/Teams (people, mindset) and interaction over process and tools.
- Responding to change (Adapt) over following a structured plan (Rigid).
Key Agile Components
1. Product Backlog: Product requirements derived at the start of the project. Based on new functionality or from a gap-fit analysis of existing product. Aid to provide an understanding of the scope & breadth of the project. High level system designs, and process flows are done together with the product backlog.
2. Sprint Backlog: Requirements specific to a single unit of work (product) to be done in a 14–30 day window. They are described on cards, with estimated completion times, assignees.
3. Iterations: Iterations that deliver measurable, definite, and valuable software product. Usually based on the priority of project objectives. Sprints start and end with ceremonies to build consensus and ensure continued objectivity and value delivery.
4. Kanban: Physical or digital board illustrating and tracking sprint progress. Each card/requirement moves from one lane to another (Pending-In-Progress-Review-Done-Rework-Parked). The scrum master is charged with curating this board daily, together with the project teams.
5. Standups: Daily 15-30 minutes sessions to review progress and move the card to the next lanes, meant to ensure project cadence and accountability. They are quick, status-based discussions that avoid tackling design or project concerns.
6. Release Management: Process of packaging and deploying a working software product and involves testing, documenting, versioning and deploying. The same unit of work can be reworked/improved in future sprints based on client feedback.
7. Retrospectives / Reviews: Sessions at the end of each sprint held by the project team to review team/sprint performance. Identify lessons learnt, best practices, improvements, and related concerns of the just finalized sprint. These foster improved cadence, management, and quality in the next sprint.
8. Definition of “Done”: Criteria for passing a sprint card/requirement as done. Agile advocates for good-enough as opposed to perfect/ideal, therefore teams agree on the thresh-holds required to close a card. High demands may lead to too many reworks or scope creep, while a low threshold may lead to poor product quality. An ideal balance is key.
9. Project Meetings: Project meetings (usually bi-monthly) held to updates executive project stakeholders. Help to handle concerns such as change management, policy/process changes, resourcing concerns among other concerns.
Key Agile Stakeholders
1. Sprint Managers: Vendor side resource that co-ordinates the sprint process, including daily standups, release management and general stakeholder updates.
2. Product Owners: A team of both vendor and client authorities, who determine and are accountable for various software products within the scope of the project e.g., departmental/process heads
3. Project Sponsors: Executive persons from the Client side with ownership of the vision, purpose and resourcing of the projects e.g., CEOs, Division Heads, Executive Committees, Boards
4. Project Teams: Composition of both vendor and client working teams charged with the day-to-day delivery of the project. Involves vendor leads, client champions, users, software developers, business consultants, quality controllers, among others.
5. Project Managers: Both vendor and client-side authorities tasked with managing overall project scope, budget, quality and timelines. They navigate the project from start to end, eliminating obstacles, assigning resources, ensuring accountability and communication among other key responsibilities.
