In the first part of the article, we covered the basics of Agile. In this part we will cover my way of Agile practices which is combined and modified version of Scrum & Kanban.
Let’s dive in.
Consider that you have to develop a software for a customer.
- Product Owner & Requirements & Backlog:
- One person can be assigned a role to be a product owner and he would be responsible for customer communication throughout the product life.
- Similar to traditional software development cycle, the very first thing would be to gather the requirements. But the difference is gather overall requirements for the product.
- Overall requirements will give fairly good idea about what the end product would be. Based on the requirements, discuss them with team and create list of Backlog items.
- One good practice would be to put detailed information of the requirements along with Acceptance Criteria.
- Collaborate with customers and continuously keep refining the list and details of backlog and done items.
- Development team:
- In Agile every team member is developer. The programmers, testers, designers all.
- Sprints & Sprint planning:
- Once initial backlog is created, collaborate with all team members.
- Priorities the features (backlog items)
- Timebox the sprint. i.e. depending on product size and backlog items, decide how much can be developed, tested and delivered within one single sprint.
- Divide each requirement into goals and team works to achieve that goal in one or two sprints.
- Create Epics and stories from Backlog and goals.
- Start assigning stories to developers based on developer and sprint’s capacity. Start with small and keep on increasing or decreasing the number of story assignments based on past sprints result.
- For preparing backlogs, creating Epics and Stories, Sprint planning and execution we need some tools. Most widely Agile feature used would be Agile Board.
- Agile board is simple visual representation of items (Stories) in different workflow states presented in swim lane fashion.
- Simplest Agile board would be like TODO | In Progress | Testing | DONE.
- You can use a digital tool for this or just draw a board on whiteboard and use Sticky notes to represent your individual items (stories/bugs)
- So, when sprint is started all assigned items are put in TODO lane, each item is put in In progress when it’s being worked on, once done item is put into Testing, once Tested and delivered, item is moved to DONE.
- The similar board can be configured if you wish to follow Kanban, and same board can be shared with customers to view. Once additional configuration that you can do is set to WIP (work in Progress) limit for each lane. WIP can be number of items, or Estimates or any other condition of your choice.
- For eg, we can keep number of items as WIP limit.
- WIP for TODO (10), WIP for In Progress (2), for testing (10), Done (10)
- As you can see that In-progress has WIP for 2, which would ensure that no developer can work on more than two items simultaneously.
- This would also give a clean picture of team’s capacity and availability.
- Daily Updates (Stand-ups):
- Everyday entire team should gather for 10 mins and share their updates with entire team. This is very important so do not skip on stand-ups.
- Updates can be what the person worked yesterday? What he’s planning to work today? What are the impediments if any?
- This gives entire team a daily progress; kind of a report and quick actions can be taken to resolve impediments immediately rather than at end of the sprint.
- Demo at sprint End:
- On the last day of sprint there should be a demo run with entire team (and customer if needed)
- Demonstrating implemented feature helps validating the implementation also it may uncover hidden things which are not planned or discussed yet.
- It gives opportunity to other team members to review and provide their inputs. Also product owner can get clear picture of the progress.
- Review, Improvise and Repeat (Iterate):
- At the end of each sprint collaborate with all team members and do a retrospective(review) of the sprint.
- First thing to check is Current work in progress and Done items. Based on the plan, ideally all items should be in Done. But if that is not the case, pending items goes to next sprint.
- TODO vs DONE items will give you better idea to plan next sprints.
- Another important thing to discuss and note: (First point of the Manifesto)
- What did we do well?
- What did not go well?
- What can be done better?
- Or simply put GOOD, SAD, MAD points.
- This considering above points continue doing good points, create action items for impediments and things that didn’t go well, and improvise the suggested things.
- Do a Sprint planning for new sprint based on above and start new sprint.
- It is not necessary that you have to deliver after every sprint ends.
- There are many services that depend on other services which prevents the developed feature to be delivered.
- This is quite usual scenario and hence when we put the requirements in Backlog (Epics), we should divide the epics in stories such that working sub feature can be delivered after end of one or more sprints.
- After each delivery demonstrate the results to customer and get their feedback. This would help identifying and eliminating issues and changes requests. Also, customers would get a chance to decide whether any changes are required in final feature or product.
Once you start working in Agile fashion and keep improvising the execution, you’ll get great benefits.
Try to stick to the plan, keep happy and comfortable working environment which would ensure high throughput of team and happy customers.
Q: What are different roles we should have in a team?
A: There is no ideal list of roles for any team. As Agile suggest, team should be flexible and so should the Roles.
This flexibility also gives chance to each team member to take up different roles and responsibilities so as to increase their knowledge.
Some of the roles that I think should exist in role are:
- Product Owner: responsible for entire product and product level decisions
- Business Analyst (BA):
- Responsible for maintaining requirements and assisting in business decisions.
- Ensure everything is documented: Requirement along with Acceptance Criteria, Site Maps,
- Ensuring that Acceptance criteria is satisfied after every sprint end demo.
- Designer / UX Designer:
- Designer and UX designer are different roles which can be assigned to one or more persons.
- Designer is responsible for visual of the product and UX designer is responsible for User Experience (Flows, Navigations, Clicks etc).
- Programmer, Tester:
- In Agile all are developers, and in general scenario, developers are responsible for sanity and Unit testing as well.
- For regression and end to end testing it can be advantageous to have different person to test entire application.
- Agile Lead/ Scrum Master:
- To help manage the project with Agile methodologies it’s good to have individual person to handle this role.
- Agile Lead or Scrum Master can be of different team or projects and they may server to multiple projects.
- Having different person from other team helps getting unbiased opinion and executions.
- Also, Sprint planning, Stand-ups, Retrospectives, Synchronising with other teams (Backend, Front end teams), Identifying impediments, creating Action items for them and follow-up to get them resolved etc. All these are challenging tasks. So better done by individual person.
To sum up, I would say, this is what my understanding and learning is. I use both scrum for execution and Kanban board for current progress tracking with WIP limits. I often serve as Product owner along with Business analyst or Programmer, Tester as well and for some projects I serve as Agile lead.
The tools available for Agile management also provides various other features like Sprint Reports, Burn-down Charts, issue tracking etc. which are great additional features proven to be useful for software development.
For detailed information, you can always refer to Wikipedia and other books.