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.

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):

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?

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.

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.

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)

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.

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!

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.

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 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.

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?

In a typical agile environment, as there is no specific design phase, and there are often questions about when the design and architecture happens. There is continuous evolution of architecture and design that happens during the sprint and iterations. Also the conventional roles like Managers and Architects have no room in an agile environment. In this article we will discuss who do we call an Architect in an agile environment and what are their characteristics.

Agile Architect

An agile architect is a developer working and taking the most important technical decisions on the product. This is generally a person who has deep knowledge of the product and the technologies used and have great ownership in taking it to the next level. This definition beats the conventional definitions of a software architect who generally creates artifacts (like class diagram, sequence diagram etc) to be consumed by developers. An agile architect also do these conventional things in order to empower other developers, but also leads & helps the team to solve daily problems faced to implement the technical direction.

Characteristics

Be Agile: Agile architects are highly flexible and adaptable to changing requirements and environments and always open to changes.

Right tool for the problem : Agile architects often have good knowledge on more than one development language and are always open to newer technologies and solutions. When they are solving an intense problem, they use the right tool to solve that.

Emergent Design: Agile architects know that we can not fix the architecture at one go while the requirements keeps changing. So they are always ready to change the architecture and design based on the current business requirements.

Always Learning: They know there is always a better way to do thing and are open to do changes to their current tools, techniques and processes.

Refactor it in free time: When code does not reach perfection, they are open to achieve the business results and then do code refactoring to fix the flaws.

TDD/BDD: Agile architects always follow best practices like TDD/BDD so that the code is always nimble to new architectural changes.

Team along: As architecture and design is in the hands of every developer, agile architects always bring the team along and continuously get their inputs and provide technical directions.

Respect: There is no ivory tower for an agile architect, they are always part of the team and delivering results. So they respect other team members opinions and ideas and focus on delivering the best results for the product.

In this ever changing business environment, developers are often asked to deliver more and more in less time. Agile architects are a big asset to a team in providing technical, architectural and design guidance to the team.

One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges or too busy to do other things that they don’t have time to focus on employee morale. There are obviously pros and cons but making it work truly helps you to achieve more. In my personal opinion, the number of positives what you have with this retrospective is far higher than challenges hence it’s worth doing it.

Prerequisites :-

Your team and your presence

Sticky notes (Three colors)

Enough Pens

Open minded motivated teams

In this retrospective, you ask your team to get into a room. Every colored sticky note represents Sad/Mad or Glad respectively. You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!

You can take the printout of below and paste that in the room where you are going to conduct this meeting. This would provide clarity on the go!

You can start your meeting with a positive note. Ask individuals to participate freely and openly. Once the stage is all set, you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad) on different color sticky notes. I always recommend individual team members to write their names on each sticky note else there are good chances that it would become a political battle.

I have seen instances where team members just write some crap either because they did not have good appraisal last time or not in line with others due to personal issues. If you find an item which has something written in sad or mad while an individual who wrote it is not willing to even talk about it then you can very much assume either that’s fake or written with the wrong intention. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern. Just to avoid the frustration as manager, anything written as an area of concern and individual is not willing to open up personally or with the team, you can safely scrap it.

Once everyone is done with writing, spend an hour or so reading every item and discuss that with the team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.

Things to remember while doing Sad/Mad & Glad:-

You should be reading every item loud or make it visible to every individual unless there is a derogatory remark which is not acceptable.

Team to think of the success of team and project rather considering this as revenge material.

Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.

Refrain from making comments about an individual if you don’t have supporting material. The world is not perfect. The goal is to identify the improve system over making it worse

BE MATURE

Should not be anonymous.

Don’t abuse it. It is conducted to the best interest of an individual and improves as a team. It should never be used as a tool to fulfill your political battle.

Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.

Don’t try to fix the problems during this retrospective.

Constantly read the issues/concerns raised and strive to fix as much as you can. Provide updates to the team around the issues you committed you would work on.

The benefits I see with this retrospective are:-

Gives lots of motivation to the team when going over “Glad” items.

Give an opportunity to an employee to express their challenges.

Bring in open culture

Reduce attrition as you really know challenges and definitely a lot of which you can work on.

It gives 360 views in terms of how the teams are progressing.

One of the biggest “Glad” item I would say is that your organization is conducting it.

The challenges I see are:-

It may become a political battle if your team is not mature and willing to go for an anonymous survey.

Excessive sad mad and glad would unearth issues which are not really problems while making other team members think it’s a major problem.

Sometimes very happy team morale goes down as well as when you have an opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.

What I was written must be addressed and fixed “Myth”. You may not like the tile color in the washroom but that cannot be really changed.