No matter how great your team is, there is always scope to improve and get better. The retrospective is way to accomplish this periodically. The main focus is to look at what is working and what is not? Further what are the action items we have based on our learning. The core focus of retrospective is continuous improvement which is one of the core philosophy of agile.
The primary agenda of this meeting where every team member is expected to bring their points are
- What worked well?
- What did not work well?
- Action items to improve the process (Mainly action items are result of what did not work well)
How to do it
- Set the stage. Invite entire team for a meeting (Scrum Master, Product Owner, Team and Customer if possible)
- Give 10 minutes to everyone to enter their points towards 3 agenda items stated above. The recommendation is to use a tool (For instance noteapp) and send this to whole team in advance to enter their points. This would save time for team in meeting and moreover give enough time to team members to think and state their points.
- Start with talking about previous retrospectives action items. Close the items which are accomplished.
- Talk about what worked well, appreciate people and motivate team to continue utilizing the best practices.
- Further Discuss what did not work well and come with action items
- Assign owners for every action item.
- Close the retrospective while action items to go to action item register.
- Typically it should happen after every sprint and should last between 30 to 60 minutes.
- The whole team should participate.
- This can be considered as “lesson learned” meeting. The notes can go to organization process assets (Remember “PAL” or “Process Asset Library”).
- The owners must be assigned to action items. The next retrospective should start with open items of previous retrospective meetings. I have seen, individual teams have excellent ideas while post retrospective nobody really thinks about it.
- One of the recommendation is to have retrospective of retrospectives to make it better.
- Don’t point fingers instead work as team and support each other.
- Do not forget to appreciate your team members.
The agenda of this meeting should be:
1. What did you accomplish since the last meeting
2. What are you planning to work on until next meeting
3. What issues are blocking your progress (Impediments)
- This is not a status to management instead making sure the whole team is on same page. Stand up is not a meeting. It should clearly intended to be standup.
- The stand ups should be strictly time-boxed to 10 minutes. The standard scrum practice says 15 minutes while with my last many years of experience, I see better results with 10 minutes.
- Hold the meeting “Without chairs”. Everyone must stand and speak up.
- Plan to do this in morning. If you have sprint team outside of your country and common meeting held only in the evening then plan to meet whoever is available in morning for 5 minutes for quick sync up with same agenda. The evening stand ups are just status or post mortem which doesn’t serve the purpose of stand ups.
- Everybody in team reports to three agenda items listed above to rest of the team.
- Prefer to have this meeting at the same place and time everyday. Meeting morning is very important as it helps set the context for upcoming work.
- The quick questions and clarifications can be covered at a times while do remember that the meeting must have to be end within 10 minutes. Please understand when I say quick, I am referring closed ended quick questions. The rest everything should go offline or should be addressed with other meetings.
- The meeting should not be cancelled even some of the members are not present. As a team member it is extremely important for you to attend the meeting if you are not on leave that day.
Following are the TOP 10 agile interview questions. There is another list of critical questions while these are expected in most interviews. Moreover these are very basic, and every interviewee is expected to excel in his/her responses for these questions.
- What is agile roadmap looks like? Explain agile process start to end? How do you start agile project? What is the difference between product roadmap and Release planning?
Refer Agile Roadmap
- What is Test Driven Development? How does it differs from traditional method where tests were written before the actual code?
- What is continuous integration? How do you achieve that?
- What is scope creep and how do you manage that within sprint?
- What are the core artifacts of sprint? Elaborate them?
- What is the role of Scrum Master, Product Owner and Team Member? Or what are the typical roles in Scrum?
Refer Scrum Roles and Responsibilities
- What is Velocity and Story Points? How do you relate story points to hours? Is it right?
Refer Story Points Vs Time
- What type of metrics or reports you have in agile? Explain?
- Explain Sprint Ceremonies? Planning & Grooming, Stand-up, Demo or Showcase and Retrospective.
Scrum Ceremonies – Daily Stand Ups
Scrum Ceremonies – Planning and Grooming
Scrum Ceremonies – Retrospectives
Scrum Ceremonies – Demo/Review or Showcase
- Explain Agile in 2 minutes? When should you use Agile? Explain the instances when you prefer to go with Waterfall over Agile
Refer Agile in 2 minutes
I would be writing other important questions in addition to questions focused for Managers, Directors, Agile Coaches, Scrum Masters, Team Members and Product Owners in my upcoming blogs.
If you are a manager and above in agile work environment and you need to go with appraisal, you might have encountered situations where what to expect from your team members compare to traditional model. The focus is on collaboration, pairing, individual ownership for self and team. The “Working for team” culture over work for “self” make it more difficult. One of the recommendation I have for all the managers or individuals responsible for doing appraisals for agile team is to have a certain percentage allocated to team success in everyone’s goal, and further how the team collaborates and how well they work together. The percentage can differ with experience of an agile team member and expectations what you have from your team.
When it comes to individual performance (obviously there is a percentage attached to this as well which is typically little above than team success), I prefer to look at three factors which covers it all.
1. Competence – Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.). Consistently works to leverage skills for team and larger organization success.
- Breadth and depth of knowledge and skills
- Problem solving ability
- Technical, communication, interpersonal, business skills
- Leadership and innovation, applied to people, processes, and projects
2. Contribution – Someone who has a lot of initiative, is a leader across the organization, and has outstanding productivity.
- Ability to meet commitments
- Overall productivity and volume of output
- Early communication of problems and contribution to workarounds that meets business goals
- Versatility – willingness and ability to adapt to new tasks
- Teamwork – willingness and ability to help others
- Leadership skills such as architecture, project management, change management, communication, and mentoring
- Ability to motivate others, manage self, and demonstrate initiative.
3. Value to business – This is very critical. What kind of value you are adding to business. There could be high competence and contribution to build a product while ROI (Return on investment) should never be ignored.
- Knowledge and skills as mapped to needs of the business
- Extra points here for unique skills we need
Every agile member should ask three questions to himself/herself frequently
- Am I learning?
- Am I contributing?
- Am I making a difference?
The manager should ask the same questions to himself/herself and same for his team. If the answer is no then appropriate development goals must be planned and discussed.
The biggest goals for a manager should be in while managing agile project should be
- Sprint success
- Continuous Improvement
- Constant Learning
- Building Self Organizing Teams
In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.
Following are the some of the reasons why sprint success is important.
- Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.
- Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.
Fig: Habit Loop
- Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.
- High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.
- Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes bigger than individuals and deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.
These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.
I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks? Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.
The recommendation is to have tasks created for each story. Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria. Once tasks are created, each task should be tagged to approx. hours needed for the same.
While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to
- Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
- Acceptance criteria
The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming. It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.
I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining
- The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
- It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
- Having tasks for individual story make it very easy to share your story work with other team members.
- The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
- The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
- Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
- Small victories (after completing each tasks) gives motivation to individuals.
- You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
- The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
- In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
- The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
- These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
- The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
- The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
- Better bonding within team as things are BETTER organized.
- You can better calculate matrices like productivity, cycle time, utilization etc.