Planning & grooming process for distributed (not co-located) agile teams
 

Most agile frameworks encourage team co-location to have

  • Better communication, mutual trust & respect
  • Better alignment and support
  • Lesser operational costs and smooth management resulting in a better outcome.

All of these are designed for achieving better results as a team. Unfortunately with globalization (offshore/onshore model), there are very few teams that are fully co-located.

In such a scenario, sprint ceremonies are often challenging when you are following Scrum or XP model. In this article, I am going to focus only on planning and grooming ceremonies. I have tried this approach in many teams in the past with significant success.

Planning and Grooming
Agilechamps – Planning and grooming

Assumption

In order to better understand the model, let’s assume that you have one sprint team with 12 members split equally into two teams and separated by multiple time zones. The product owner and Scrum master are co-located and duration of each sprint is 2 weeks long, starting on Tuesday. Assume the team velocity is 40 story points, completing approximately 10 features and 10 bugs in a given sprint on an average.  For this example, let us assume the teams to be located in India and the USA J

Approach

The product owner tries to ensure that at least 2 sprints worth of work is well prioritized at any given time. The team focuses on getting sprint work done during the first week of sprint. The team assumes 10 hours’ time for each USA and India team in each sprint to pre-groom stories. The teams spend some time each day pre-grooming stories and creating tasks during the second week of the sprint along with the continued effort towards their existing sprint goals. The goal of this exercise is to ensure that both teams have enough clarity on stories to be able to start working on them from day one of the upcoming sprint.

During this period (the second week), individual teams should communicate with the product owner or other members of the team to retrieve as much information as possible to flesh out requirements and discover potential blockers.

While this may appear a little tough in the beginning, it gets better over time as team members gradually become accustomed to the code base and business functionality, and are able to make better-educated guesses and assumptions about the stories. Initially, teams might even find themselves spending close to 10 hours a week in these activities, but the time needed drops off significantly in due course. This is especially true for teams that are less exposed to business or may be newly formed.

At this point, both teams have a better understanding of stories what they have groomed. During the planning meeting, both teams talk about each story they have groomed. I would personally suggest teams conduct sprint planning meetings on the last day of the sprint. This ensures that the first day of the next sprint is not wasted deciding what to work on.

Pointing stories is a group activity where inputs from all stakeholders can be considered while assigning points to stories.

Both the team collectively go with sprint commitments after the planning meeting.

Benefits

  • Combined planning meetings are short as at least one of the team has clarity over requirements for each story. I have often seen individuals get on to planning meeting with little or no knowledge about stories resulting in long meetings. This also results in only one team being engaged in the meeting while the others become impatient and disengaged.
  • Product owners are human. It is normal for them to not have all the answers up front. This approach gives them sufficient time to gather missing details; details that they might not even have considered necessary unless brought up by developers
  • The team gets enough time to groom stories since they often have questions for the business owners or for other teams that are easy to answer, but a response needs a turnaround time of a day or two because of time zone differences.
  • The team who has less context on business come up to speed with business, processes, and resolving dependencies wherever applicable.
  • A geographically split team doesn’t mean individuals have to work in isolation.

This model helps teams realize a number of benefits which include (but are not limited to):

  • Improved quality
  • Better commitment
  • High productivity
  • High morale
  • Better team bonding
5 actionable you can take today to be more agile
 

Be More Agile

Most of the teams in the software world follow Agile process and practices. Following Agile is fundamentally different from being Agile and in this article, we will talk about some of the actions you can take today to be more agile.

do you follow?

  1. Shed Ego:  Ego is a big blocker for our progress irrespective of being in the Agile world or not. But this becomes even more evident and blocks our every step in an Agile environment. There are lots of articles about egoless development.
  2. Be open to collaborate : When we are open and talk our mind, we automatically become more agile. The restrictions and mental blocks to speak our mind openly to the team are the biggest bottlenecks to free flow of information and ideas. Psychologists call it emotional security to speak our mind.
  3. Don’t Use communication tools: In this age of technology, the tools are plenty for communication,  but none of them provide the connect of the face to face communication. (Agile principle)
  4. Focus on the outcome: Lot many times, the agile manifesto is being misinterpreted (“working code is a measure of progress”).  Unfortunately, it does not talk about production. Some teams get very complacent when they get their working code in “QA” or “Stage” environments for example. There is no result when the working code is not in production. At the end of the day outcome matters.
  5. Get things done: Just like any other methodologies, the trap always exists when teams get lost in the process and meetings. The important part of the business and the product is to deliver things. So never move eyes away from the delivery.

These are the few actionable you can take today to be more agile and be awesome developers and technologists. So take action now!

How can an Agile Leader be successful?
 

I am listing most important factors which an agile leader must focus on, in order to be successful in his/her role

  • People, people and people

  • Building Relationships with all the stakeholders

  • Business Alignment (Clarity of vision and mission)

  • Self-Organizing Teams

  • Sprint Success and Continuous Improvements

  • Everyone contributes 

  • Relationship within team

  • Collaboration

  • Promote “Fail Faster, succeed sooner”

  • Frequent releases

  • Remove impediments

  • Frequent feedback loops

  • Lots of fun

  • Process alignment

  • Visibility on current status

People

Let me tell you honestly, there is nothing more important than people.  As a leader, you should focus on people, their careers, growth, motivation and anything what you can support them to add value to their personal lives. Don’t forget to appreciate good work and at the same time it is important to provide feedback around areas of improvement.  When you think of growth, think about your team’s growth. When they grow, you grow.

Provide them opportunity to become better individuals. Inspire them to learn and get better. Feel pride in their success.

Building Relationships

Strong relationship with team and stakeholders make life easy. It’s not just about bringing in empowerment while at the same time it is important to understanding everyone’s need and expectations.  The great relationship with business, management and team helps you to have

  • Better insight
  • Access to more information
  • Align people
  • Open culture

Business Alignment and Vision

If you don’t know where you want to go, you will reach nowhere. As an agile leader, you must ensure that there is a clarity of vision and mission for you and your team. Moreover everyone is aligned to business needs and expectations. You should often ask yourself and your team about USP (unique selling proposition) of what you are building.

Self-Organizing Teams and autonomy

Don’t hold your team too tight that they can’t breathe at the same time don’t leave them to do everything by their own assuming they would become so called “self-organizing teams”  by themselves. The ultimate goal should be to build self-organizing team and if you are successful in doing so, the chances of you being successful is very high along with your team.

Sprint Success

Always focus on sprint success. When you start, do it less and then improve. Never get into discussion with business or management that we are delivering enough for our need hence meeting commitment is not important.  Do whatever it takes to make sure your sprint is successful.

Everyone contributes and Continuous Improvements

If this doesn’t happen then slowly you would see your self-organizing team start deteriorating.  Everyone has different skill and competence hence you can have different expectations while everyone has to contribute. One rotten apple spoils entire basket and this no different here.

Relationship within team

If you have happy team that gel well with each other, you are likely to do much more. If you’ve highly competent individuals in team but team members don’t go well with each other over a team which has lessor experience and competence with strong bonding then your chances of getting better output in team with good bonding. Do whatever it takes to make your team align and build a bonding among them. By doing so, you are significantly improving the chances of your success.

Collaboration and Communication

Agile team cannot run in Silo. The collaboration nothing but working with cross functional teams to accomplish a task. This encourages communication among business owners.  The communication within team is also very important. The output will be produced by team and not individuals.  It helps in removing impediments faster as well.

Promote “Fail Faster, succeed sooner”

It’s not a perfect world. In order to be successful with Agile there should be an environment where everyone encourages individuals to experiment. It’s OK to fail and that’s what lead us to be successful.  Fail faster, succeed sooner is something you should not just feel while you are expected to enforce that in your team.

Frequent releases

Release as much as you can. I have seen teams releasing every day or even post every feature completion. This is a challenge at a times or product which are quite big and needs significant testing. More you do, simple it becomes.  The moment you start thinking about releasing frequently, you would focus on automation tests.  That something most times become last priority which is not at all good.

Constant feedback

Don’t wait for showcase to provide feedback. The code review phase is not important to provide the challenges or best practice. Talk more. Provide feedback then and there. Look for ways to get the feedback from customer, PO or other stakeholders as soon as possible.

Lots of fun

Start with fun and then get on to work. Don’t wait for you to be successful to have reward. There is going to be celebration for that as well while create an environment where everyone feels comfortable and enjoy working.

Process alignment

Arrange a training. Talk about process. Doing agile is probably easiest thing while doing it RIGHT is what really needed right mindset. There are many teams I have seen they do “waterfall agile”. They are basically trying to do waterfall within each sprint.  Not good!

Visibility on current status

Create various matrix to ensure things are on track. Utilize standard artifacts like burndown charts, velocity report etc to see where you stand. You can fix the issue and come up with finding a right solution only when you know how are you doing.

Abusing Agile – Part 1
 

Disclaimer – There is no intention to hurt anybody. The idea is to pass the learning and a MESSAGE. I have seen Agile getting abused and many a times it is visible to rest of the world except the one who is responsible for it. Click on each scenario to get more details.

Scenario 1 – I leave very early because I finish my work and I pick very less because this is all I can do.

Scenario 2  – I didn’t do anything hence pairing was a saver although it was knowledge transition.

Scenario 3 – A standup cannot be a meeting.

Scenario 4 – ‘Sprinting’ means running super-fast.

Scenario 5 – It is perfectly alright to play with estimation at any point in time.  

Scenario 6 – Story point is not about time, not even a range.

Scenario 7 – We will unearth acceptance criteria and requirements for a given story as we continue with development. Writing one liner description for a story should be fine and we will keep looking at it while work in progress during the sprint.  

 

Why do we need tasks? What is the need of Planned, Actual and Remaining hours?
 

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. )
  • Dependency
  • Constraints
  • 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.
Does size matter?
 

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?