Our Agile Project Process — hmm? yet another & my problem
If you think it is so confusing and what is right and wrong process/tools to use, then this read is for you.
Before I start on adding my 2 cents, would like to thank anyone who spends time on reading this and hope it would help in some way.
My problem — It is confusing & complex when you want to balance processes, ceremonies, documentation, and production(sprint) work.
Rule of thumb — All these processes and tools are there to empower you (as a company/a person) to produce what the customer needs on time.
Think of a farmer, you would have to plan and prep, follow a process, have right tools, sow on time, look after the crops & harvest. Probably some might think, oh! that is easy — then go watch ‘Clarkson’s Farm on Amazon Prime’.
A farmer’s production process analogy is very similar to a software production process. Where an iterative process with review and refinement would help to improve the harvest/production, taking acts of nature or things out of your control out of the equation.
Following is a full end-to-end Agile project process in very brief. So, please bear with me if I have missed any finer details or have totally overlooked certain areas.
If you are still interested, please read on; next bit is boring.
End-to-End Agile Project Process Overview
- Pick a Product Owner and/or a Project Manager and/or a Business Analyst
a. Project inception/discovery discussion(s) with the client
b. Documentation & Diagrams (use only what is required & relevant) — time & effort is key, so do not overdo it.
- Project initiation document
- Process diagrams, Use cases, Activity & Flow diagrams
c. Epics, Features & User Stories creation;
- An Epic example — Account management via my account section on website.
- A Feature example — Address details can be edited via address book section in my account.
- A user story example — For B2B users, only admin can edit billing addresses.
2. Pick a Team
a. Should be between 3–9 members.
b. Composition — an architect, a tech lead, senior engineer(s), developer(s), QA(s) and DevOps engineer(s).
c. A scrum master — elected from the above team if there are no dedicated personnel.
3. Create and Prioritise a Product Backlog
a. Like a road map, Product Owner is responsible for managing the Backlog.
b. Product owner, architect, lead & DevOps create architectural, infrastructure & delivery plans.
c. Refine project documents, epics, features & stories.
d. Documentation
- ER & Dataflow diagrams
- Architecture & Networking diagrams
- UML Modelling and Use cases
e. Define test strategy.
- Create a test plan, that includes scope, types of testing, infrastructure, risks/mitigation plan, resources, milestones & deliverables.
4. Refine and Estimate the Product Backlog
a. The production team/elected members from the team need to look at each backlog item and see if it is doable. Is there enough information to get it done?
b. Break stories into tasks/cards/work units.
c. Estimation process;
- Techniques — planning poker (Fibonacci numbers based; 1, 2, 3, 5, 8, 13, 20, 40, 100), Affinity grouping (t-shirt sizes — xs, s, m, l xl …etc.), Dot voting — when undecided and stakeholders are unhappy with the voting, use prioritisation (high, medium & low), ordering protocol …etc.
- Agile estimation techniques are collaborative. All team members are included in the process.
- Problem with time-based units in estimation — Time estimates are often turned into commitments by management and business, team members feel more pressure to be as accurate as possible. As a result, they request more and more detail about the item being estimated. This turns gross-level estimation into the more time-consuming detail-level estimation and defeats the original intent and purpose.
d. Forecasting schedule and budget;
- Find team velocity — this is the total number of points completed on average in an iteration/sprint.
- Use the gross-level points estimate and team’s velocity to determine sprint capacity.
- Once sprint capacity is determined, you can use it in forecasting a long-term schedule.
5. Sprint Planning
a. Once the Product Backlog is complete and refined, work is broken down into Sprints. Breaking down the project into sprints (2/4 weeks), makes the project manageable.
b. Either the entire team or 3 key members (three amigos), i.e., Tech lead, QA lead and the Product Owner sit down to plan the Sprint.
c. Each Sprint needs to have a Definition of Done by starting with the End in Mind. Definition of Done: Clear standards that any piece of work must meet. Defining conditions that need to be met and tests that need to be passed to call complete.
d. For each story/task/work unit, relevant documentation to be added.
6. During Sprint (Do’s and Don’ts)
a. No team member should be distracted, disturbed, re-assigned nor given added responsibility hindering their focus & velocity of production. Probably in an ideal world, this requires a fine balance.
b. All team members are equal regardless of the number of items they clear from backlog.
c. All team members should involve in task/card/work unit review process when they are assigned to.
d. Planned Sprint items should be picked prior to picking items from Backlog.
e. Items from the Backlog should only be picked in the following circumstances;
- All planned Sprint items are completed or been taken by other members.
- Sprint work completed early.
- Dependencies identified during Sprint work and added to the Sprint with agreement from all responsible parties. In this scenario, the Sprint planned items must be balanced out to keep the schedule.
f. Agile testing quadrants
- Q1 — DEVs & QAs write & run unit/component tests.
- Q2 — QAs write & run manual/automated functional, story & simulation tests.
- Q3 — QAs write and run manual/automated exploratory, behavioural/scenarios, usability & acceptance tests.
- Q4 — QAs & External sources to perform performance, load & security testing.
7. Daily Stand-up or Daily Scrum
a. Identify and invite relevant attendees.
b. Request all attendees to come prepared for; The status of the tasks, Tasks working on next and any obstacles.
c. Stick to a strict timeline, maximum of 15 minutes.
d. Create a comfortable, non-judgemental atmosphere that encourages all attendees to share their thoughts and experiences.
e. Listen carefully to others when they speak instead of focusing only on what you came prepared to discuss. Sometimes what others are saying might help you understand your next steps better or resolve your concerns.
f. Strive to be concise to allow everyone who needs to speak adequate time to do so. Scrum meetings should be short and highly productive. Allocate time for each person to talk and adjust, as necessary.
8. Sprint Review/Demo
a. This is an informal meeting with all team members.
b. During the review period, team members show what they have accomplished during the Sprint.
c. Main purpose of it is to only demo what meets the Definition of Done, with the goal of creating transparency, fostering collaboration, and generating feedback.
d. Then need to focus on;
- Requesting feedback on completed work from stakeholders.
- Discuss work not completed and plan.
- Identify any risks and impediments.
- Review project increment objectives and give a thought to next sprint focusing on items on the top of the backlog.
9. Sprint Retrospective
a. Once the Sprint Demo is completed and the team has shown what they have accomplished, they sit down for a retrospective. The goal is to determine how the process can be improved upon.
b. It is a time for discussion, not finger pointing. It should encourage a continuous improvement mindset (a growth mindset) and everyone’s voice is heard.
c. One of the main objectives should be to set the team in a positive path for the next sprint.
d. Questions that you should discuss;
- What could have gone better?
- What can be made better in the next Sprint?
- What is the improvement in the process that they, as a team, can implement right away?
- What could make us faster?
The farmers plan for the next crop cycle and the agile teams plan for the next sprint — And the process goes on.
Next one will be on farmers tools, not really! It will be on project management and development tools for Agile Teams.
