October 26, 2016
Use Agile Correctly (Part 3) - Grooming and Planning
Groom Often (Backlog Grooming)
- Usually Sprint 0 is dedicated for backlog grooming and then team start to deliver in Sprint 1 and onward.
- Considering any Enterprise Line of Business (LOB) application, sprint 0 can’t suffice the entire backlog groomed at once.
- Hence, team must regularly have backlog grooming in small chunks of time instead of lengthy full day meetings.
Ideally, grooming is a lengthy process and hence groom in short chunks and team lead can be present in the regular or small grooming sessions with PO or business and team can continue to focus on their work. However, team must be present at Sprint Planning time.
Brainstorm Together (Sprint Planning)
- Everyone is invited. Many teams ask only Dev’s to attend and excuse the QA team members.
- Understand the problem 1st.
- Ask Questions and clarifications.
- “Well defined” Acceptance criteria is a must.
- Confirm that User Story is ready for development.
- Nothing should fall from the cracks, document all within the User Story.
Daily Status Check
Just three things, no more; no less
- What have you done since yesterday?
- What are you planning to do today?
- Do you have any blockers preventing you from accomplishing your goal?
I recommend, that if you have to discuss something related to a User Story or bug or some reported a status on something etc. then “Post Scrum” that. I.e. discuss that when team has given the status and now you can drill into the detailed discussion.
Many times Dev’s start going into technical details of the issue, design of solution, architecture, code review comment details etc. during their status. This is not right way of doing it. Just Post Scrum all that; if you have to discuss anything other than those three absolute must.
I am Blocked
It’s is obvious that someone at some time is blocked on something. You can help, by asking just:
- On what
- What is the issue
- Who is POC (Point of Contact)
- What is ETA (Estimated Time of Arrival) I.e. delivering solution to you.
I will give you a scenario, let’s say I join a team which works on some third part control library and my license of that product is pending or not yet processed. Am I blocked. Well in a way; yes, but I can use trial version up to 30 days and when my license information come I can punch those.
Also, many times we just tell other team that we are blocked on something and we are expecting the endpoint or JSON format etc. but we don’t always ask what is ETA and convey the timelines we have to adhere. If this has any impact on your team’s deliverable than you need to re-prioritize, escalate etc. so either that work is delivered to you on time or that user story is pushed to next sprint and you pick next item on Stack rank (priority) from the Product backlog.
Scrum Master must help you to get unblocked
Is there time to Think?
Many people and teams think that Agile has no time for following:
- Researching a solution
- Brain storming on the solution architecture.
- Share your thought process, design, approach with the architects, PO etc. to get the insight.
Well, there is and it’s called “Spike”. In agile software development, a “Spike” is a user story that cannot be estimated until a development team runs a time boxed investigation. The output of a spike story is an estimate for the original story.
Some examples of spikes:
- Discussing authentication mechanism and partner team’s flexibility to apply / accept those changes.
- Discovering or researching for an off the shelf solution work flow solution.
Every team has it, generated it, accumulate it; not a problem. Just make sure you pay it off.
Technical debt is a term which is used for the work which team or an individual didn’t prioritize upon while pushing the deliverable, and require improvements.
- First and foremost, poor coding style and standards.
- No unit test cases.
- Not following OO design principles and developing long monolithic classes and code libraries.
- Not envisioning on proper candidate technology, architecture or approach and then hitting a wall. I.e. when application is little bit mature you start to feel the hit on User experience, performance, scalability, code maintenance etc.
- Code files has a lot of comments. I.e. code is completely documented. Many developers write few lines of comment for each line of code.
- Code is not self-documented.
- Magic strings (hard coded path and endpoints etc. in the code)
- Dead code in project. You must have seen or left some commented code in various code files. This is dead code and needs to be cleaned up.
Branching and Merging
Branching enables parallel development and delivery by providing each development activity a self-contained snapshot of needed sources, tools, external dependencies and process automation.
Continuous check-ins pollute the branch. Have a separate Release branch per Release.
Basic Dual Branch is an Ideal branch plan, have a Main, spin a Dev branch for development and have RI (Reverse Integration) and FI (Forward Integration) to merge changes between Child and Parent branch respectively.
When you are ready to deliver the shippable product at sprint completion then spin a Release Branch and deliver the product out of that.
Feature Branch Plan is slightly complex and requires more merge efforts but at the same time it give entire isolation of work being done in a feature branch for entire time; until it’s ready for merge to Dev branch. One major issue with this plan is that your feature branch will have old and stale code and when you will Get Latest / Pull from the changes then you will get some conflicts etc.
“Save your creativity for your product… not the branch plan.”
“Your branch distance from main is equal to your level of insanity”
For a sneak peek at the full series, see Vidya’s blog. Or, Follow Us on LinkedIn to follow along.