No matter how great your team is, there is always scope to improve and get better. The retrospective is a 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 a 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 to a meeting (Scrum Master, Product Owner, Team and Customer if possible)

Give 10 minutes for 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 the whole team in advance to enter their points. This would save time for a 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 the team to continue utilizing the best practices.

Discuss what did not work well and come with action items

Assign owners to every action item.

Close the retrospective while action items to go to action item register.

Best Practices

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 organizational 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 a retrospective of retrospectives to make it better.

The standup is nothing but a daily meeting among all scrum 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)

BEST Practices

This is not a status for a management instead it is to make sure the whole team is on the same page. Stand up is not a meeting. It should clearly intend to be a 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 the same agenda. The evening standups 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 every day. Meeting morning is very important as it helps set the context for upcoming work.

The quick questions and clarifications can be covered at a time while do remember that the meeting must have to 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 canceled 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.

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.

Fig: Success

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

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.

Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”

Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”. Also as the number of unknowns in a story is high, team provide higher story points for the story.

However the size of the story points is not important because

Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.

When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.

Story points are a relative sizing of the stories and not a exact reflection of complexity/effort

Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.

Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.

Please let us know your thoughts, using story points? does size matter?

Product Owner (PO) – PO is a key stakeholder in an Agile project. He/She is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it.

Defines the features and stories of the product. Responsible for elaborating requirements, clarify doubts and clearly stating acceptance criteria.

Agile software development or methodology or framework refers to time boxed, continuous iteration of development and testing to build software where the solutions evolve throughout with incremental development via collaboration among self-organizing teams. Agile helps organizations to expertise and respond to continuous change and make them able to do more.

As shown in above diagram, the vision and feasibility are most important factors to be considered before starting a project. In this phase, we identify whether we should consider doing a project or not. Some of the questions need to be answered in this phase like what is going to be ROI (Return of investments) for a project? How do we get funding? Is it worth taking risks? Staffing? what is the value the project bring in? etc. You use this phase to break the idea into individual functionality items called features or user stories. If this looks positive, the next step is to create a product roadmap document.

The product backlog is created leveraging the product roadmap document. The release planning results in release backlog. The individual sprints are defined to accomplish upcoming release goals. The Agile Roadmap blog defines the entire project in more details.

A switch from waterfall to agile project and suddenly you would start seeing whole new world. Is this shift complicated? How can I be successful as manager in agile project? How does it defer from traditional methodology? And there are many more questions which every manager who starts with agile project or managers already part of agile project come up with. Most importantly what is my ROLE? Lets explore

As a manager, when you get into a project you want to manage the day to day deliverables and processes but wait that’s a job of a scrum master, you move on to prioritize the work but that’s again product owner owns. Wow, then you jump on to assign work and get involved in day to day activities but wait again, isn’t your teams are self-organizing?

By heart, I am a software engineer. Can I code? Off course you can if you don’t have any other work and moreover you are expected to become a team member. Frustrating, well yes and no. If you are quite adamant and not ready to unlearn some of the traditional practices as manager, you would be biggest bottleneck in getting your project successful. You can’t do many things in agile while you can control everything by keeping some distance while taking complete ownership.

As a manager, I would suggest you to do the following

Motivate team – Constantly encourage your team members. Agile focus on every individual and a motivated team member can do wonders. If you are thinking of spoon feeding agile member then either the member has too many challenges or you are not a right manager.

Celebrate victories – Find an opportunity to celebrate your victories. Even if that are small as every celebration would enhance your team motivation and bring in lots of energy to system.

Focus on business priorities – Constantly focus on your business priorities, contribute in vision, drive vision by ensuring work gets done, keep abreast with business demand. Learn domain and make your team gain expertise over that. Build a model to train new joiners quickly. Encourage collaboration and encourage teams to discuss the business.

Be open – This is one of the biggest challenge I see in this industry. You don’t want to hurt anybody and with that you always go with giving positive feedback. Remember the areas of improvement and constructive feedback helps an individual to grow. You are supporting short term growth by killing his/her long term growth as well as organization priorities. You need to constantly strive to build your team and focus on every individual to be successful. More you focus on people, better off your results are. Rate your people as they are. You need to motivate your high performers and bring you low performers to get better. Always remember that you need to get better constantly.

Generate Metrics and constantly monitor them – The world is not perfect place. Teams which are doing amazing, may go down. Constantly monitor productivity, prod issues, defect rate and whatever is important in your organization.

Trust team and encourage the culture of trusting people – In my experience, if you have an average team, and that team trust each other and ready to support each other, they would end up doing much more and better compare to your star team where you see conflicts. I have seen multiple examples in past where the whole team gel extremely well and the result you see are outstanding. Not just project did the best in those scenarios while the whole team has gotten bigger rewards and great careers. The dedication to team result in delivering values. This holds true all the times.

Invest in resources – Hire best talent. Further send them for trainings, Encourage cross KT culture, plan their travel if their teams are in different country city, constantly keep in touch with them and make them feel that the org does care for them. Many a times in bigger organization individuals are lost while it is primary responsibility of a project manager to ensure they are being taken care of. One of the tool I used heavily is to ask individuals their aspirations and constantly seek opportunities to fulfill them. You may not be able to do it all but creating a path is kind of easy. In fact, many a times I see individual aspirations are so easy that it can be fulfilled in no time and little effort.

Process improvements – Let scrum master handles processes while constantly review to see what improvements can be made further. Improving on test coverage, adhering to standard practices, encouraging people to take risks etc. For instance you see all retrospective items are great while after a meeting we don’t do anything about it (Unfortunately most agile team has this challenge). Well, here you can have action items and ask team to assign that. The next retrospective should start with older action items. You can always work with scrum master to get processes better.

1×1 Meetings – This is very powerful tool. As a manager, I would strongly recommend you to keep talking to team members. Appreciate them for their great work. Constantly provide feedback on areas they should get better. Understand their perspective and identify action items for you. Make yourself available for team all the times. I am being often told by managers coming from traditional model that don’t be easily available for your team as you may end up doing more and people won’t value you. I am completely against of that idea. I think you should meet up your team as much as you can.

Empowerment – Find right people and empower them to do certain things. Build your next set of leaders. Trust people. If you manage multiple agile teams then build leader within each team and empower them. Practically you shouldn’t be very busy all the times. You should be available for your team as soon as possible when they need you.

Improve system – You should be constantly looking at everything in the system and find opportunities to improve them. Improving productivity, quality, trust, competence, delivery, processes and many more.

Seek challenges – The seeking challenges is always better option over embracing challenges. You should be constantly seeking challenges and building the same culture around that.

Fun place to work– Create an environment where everyone feels like coming to office. There should be lots of fun. Believe in starting your day with fun and it should be throughout. Don’t have a constraint that I would allow you to have fun when we achieve something. Although you do celebrate every victory but fun is something should be there all the times.

Always remember that things which you can do directly, that’s great while things or tasks which agile doesn’t allow you to do it, get yourself involved indirectly and get them accomplished. At the end of day, your biggest priority is make your team successful. If you can achieve that, rest all fall in place.