Understand 'Insecurities' to make your team "Psychological Safe"!

Once my team decided to adopt pair-programming. Team was very good but one guy, ‘V’, was a brilliant coder. However, V never agreed for pairing. Other members proclaimed that V never wants to share skills with others & so he is not agreed for it. I started believing others, but I could never convince myself that ‘this’ is the reason why ‘V’ is not supporting pairing and it motivated me to find the actual reason behind it.

We have been given one beautiful thing called brain to preform so many activities. The outcome & experience of these activities is stored as intelligence, called Mind. This mind makes human a complex entity because we human are controlled by certain psychologies developed in this mind.
Psychology means different human factors like hesitation, fear, happiness, emotions, feelings, complexes, excitements etc. which are growing in our mind and psychological safety is how these are taken care of on personal & professional front.

Before psychological safety, we need to understand Psychological Insecurity. I have seen 3 categories of psychological insecurity: -

1. Job Role
2. Gender   
3. Social Inferiority

1. Insecurity related to Job Role:

We are in highly competitive world. Truly, most of the teams are now started talking coordination, collaboration & team-spirit, still there is a feeling of competition & sometimes it takes negative shape. Being an Agile Enabler, I’ve seen below areas where people are hesitant & feel insecure: -

1. Agile Team means we are building cross-functional team. This idea instils the fear in members that their role/skills might become decentralize. When we talk about cross-functional team, without understanding the core of it, member fills with spirit of competition & insecurity.
2. Scrum Team means there is a scrum master. Because of SM role, the traditional management team (team leaders, managers etc) feel insecurity.
3. Same case is with the idea of self-organized team. Traditional management team feel insecurity here.

Protect & Maintain the Psychological Safety based on Job Role - 

As per my analysis as an Agile Enabler, the main reason of this (job role) insecurity is half-knowledge of the concepts (like cross-functionality, scrum master responsibility etc.) & our own assumptions.
Here, my efforts are to:

• Make all the concepts (Theories, Practices, Roles & Responsibilities) clear to every team members & make them understand the core behind these.
• Encourage them to have communication & talks. Discourage any possibility of assumption building.
• Never leave anyone unnoticed. I try to engage each member wherever possible. E.g. – Earlier, in one of my team, there was practice that in sprint review, QA members will showcase the developed features to stakeholders. I presented an idea that each developer showcases her/his developed feature to stakeholder. This idea was practiced & they feel engaged and have better frequency with stakeholders now.
• Motivating them to learn continuously. We do not have SAFe as such but the idea of hackathon & innovation (IP iterations), we have adopted and almost all member participates into it. This helps us in improving technical skills & better coordination among the members which are the core ingredients of safety.

These steps helped, but it still needs more efforts to make people secure on this front because this is directly associated with the feeling of earning bread & butter.

2. Insecurity related to Gender:

Psychologies become more complex when gender comes into the picture. Studies say that Male & Female psychologies are different & most of the time both see the same picture from different lenses, & it is natural. I have experienced some instances:

1. Our organization had a training on “Sexual Harassment". Surprisingly, after that I sensed a behavioral disconnect between 2 gender groups in my team. I talked with each group to find the core and finding was "male group” developed an understanding that Female can use this as weapon in future so better to get disconnected earlier. I was shocked.
2. I witnessed the conflict between 2 male groups: one says - “Females are being treated differently & it is not good”. Other says – “We can’t use the same expression & language with female as we use with males, so we need to treat them differently”.
3. Once, In our cubical sitting arrangement, 1 male & female personnel were allocated seats facing diagonally to each other. One day she informed me – “That member who is sitting & facing diagonally to me, stares at me continuously. I feel awkward & unable to execute my responsibility....”.       

Protect & Maintain the Psychological Safety based on Gender Complexities:

These above incidents motivated me to talk to different people & groups to find the core. What I found was misunderstanding, overthinking & assumptions.

The concept of Sexual Harassment training was misunderstood. To convince the Male group, we had one more session solely on “what males should do to save themselves from false charge”. It took time, but we were able to re-establish the broken disconnect.

Again, that diagonal sitting guy had a habit of being lost in thoughts while thinking. He even did not know that he used to see that girl, while thinking. I facilitated talks between them. Today they are good co-workers & friends.

Finally, we need to understand “No girl wants to be treated differently because it gives the sense of discrimination. She wants “to be heard & responded” so that she might feel engaged. At the same time, boys also need the same & don't want to be the victim of feminism.

3. Psychological Safety related to Social Inferiority:

We all are different from each other, from different background, culture, language & traditions. Day-to-day comparison with each other, on these grounds, create rift & people tend to become insecure. Some instances: -

1. Language – If you don’t speak good English, you are alien to society, forgetting the fact that in many geographies it is not the native language.
2. Skills – Sometime people think themselves under-performer & feel insecure.  
3. Religion – Sometimes we see religion-specific incidents in our society. The people of that religion feel the pressure of society even when they are not involved in incidents.
4. Other difference like Politico-economic opinion, Sports opinion, Financial standard of self & family and Any Different Ability highly impact the psychology of individual. And therefore, psychological insecurities take place.    

Approach to create Psychological Safety:

Psychological safety is a trust that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.
It is the environment where team members are not hesitant to share their opinion, to ask question, to reveal their mistakes, to receive & give feedback.
All above instances, I handled through communication & certain initiative. I also took below initiatives: -

1. Highlight my own errors – On certain occasions I shared my mistakes with my team so that they feel making mistake is not a crime.
2. 360-Degree Feedback – I started this practice so that each & everyone can listen & understand others view.
3. Listening Habit – When someone speaks, other interrupt. To install the listening habit, we started high-penalty mechanism. If anyone interrupt someone, s/he will be penalized. We had good funds for weekend parties, but the revenue is reducing now.
4. KYT (Know Your Team) – I started this campaign. We play with story cubes. We select 1 cube & members have to interpret this. This shows how different we are from each other and it is OK to have difference. But the best part is when they appreciate each other’s point of view. This helps in bonding among them. 
   
5. Start Informal – I have habit of starting communication informally most of the time. It goes like knowing about her/his well-being, family-well-being, anything crucial at her/his end. And, then we go to actual issue. It helped to get my team closer to me.  
6. Last but not the least, Cultivation of Scrum Values (Courage, Commitment, Respect, Focus, Openness) among the members will be very useful. 

Psychological Safety is complex aspect which can’t be seen by 1 lens. Unique psychologies need to be magnified through different lenses.

Do you still remember ‘V’ who was against pair-programming? I involved with ‘V’, had informal communications and one day ‘V’ told me:

"You know, I am news-freak guy. I have a habit of checking breaking news very frequently. It never impacts my work, but if I am involved in pair-programming, I’ll be judged on the ground that I spent more time on news sites than work.”

Covid-19 Distances brought us Closer - A Case Study

Covid-19 is an unforgettable situation in our lifetime on each front personal or professional. It brought disaster to the world (in Socio-politico-economic conditions as well as to the life of individual). Most of the unexpected things are happening around the world.

At our team level also, when distributed work culture adopted due to Covid-19, number of problems were encountered. On one single day, distribution adopted and without analyzing future challenges we followed the government guidelines. But it was not easy as many problems, in our workflow, were about to visible due to this. Although, few of these problems were existing in the teams already but distribution brought these up on the surface bluntly.

But, is this not that one situation which Agile is trying to focus from the beginning, that is: -

• Uncertainty
• Unplanned
• Exponential challenges
• No defined solution to the problem

Let me share what happened with my teams & how we, my team and I (as their Agile Enabler), came out of it.

The first week of distributed workforce was like sailing boat in hurricane and the onus was on myself to help my team to sail this boat through hurricane and reach on the shore. And the journey began as follows:

First Step: Early Retrospective

I (as an Scrum Master of the Team) facilitated a very early Retrospective (after 4 days of distribution starts) with very specific & only one agenda i.e. “Challenges due to distribution and how to address these challenges”

              This Retrospective proved to be boon for us. What we found, were the core challenges of working separately. To be more specific, our main problems were related to: -   

1. Problems of lacking self-organization in the teams (few members faced enormous challenge in organizing themselves)
2. The communication became lesser user-friendly as it was not face-to-face (or co-located) by any means
3. Digital intervention & particular time-box required to begin any communication
4. Home environment is not supporting (disturbance, no dedicated space) to deliver what is expected
5. Technical challenges, VPN issues, Device availability etc.
6. Few members (correctly) pointed that we are working from home does not mean we cannot have personal time. It is expected that we should start early and end late in night because we are at home.

In the same Retrospective, we started discussion to find solution of these challenges. (It was well understood that before leaving the table on that day, all of us should reach to some(expected) solutions of these problems because we can’t go anywhere until we resolve these). After some brainstorming, discussions, arguments, we decided to adopt certain practices.

Second Step: Possible Solutions/Changes introduced by Team

1. Increased frequency of daily scrum to Twice/day – Team decided to have 2 times daily scrum during the day, one when starting first half and second when starting second half (i.e. like 10 – 10:15 AM and 2:30 – 2:45 PM). The whole idea was improved coordination among the distributed members and highlight the blockers ASAP. Now, members were to share the plan only for 4 hours in each daily-scrum session. It helped the complete team in increasing coordination, but it drastically helped them who were facing problem in self organization. They were feeling comfortable as it was easier to plan for lesser time-box now. It really worked for us. I am still following the same with 3 out of 4 teams in my organization.  
2. Common chat group to facilitate discussions – We created a common chat group and all of us were committed to have any work-related discussion on that group only. Until & unless it is very-very specific between 2 people, the communication shall be done on common chat group. It will maintain the sync and information leakage can be cured.
3. If possible, priority will be for video calls – We made an agreement, irrespective of magnitude of discussion, if possible, we shall have video calls. Undoubtedly, on video calls, the engagement was less interrupted
4. Weekly Retrospective – Another important decision taken to have weekly Retrospective with very specific agenda “Challenges in working distributed & solutions”. It is quite different from Sprint Retrospective which focuses on Sprint-happenings. It actually made us better.

Finally: When we got distributed, my whole idea was to strong the scrum values among the team. These values (Commitment, Courage, Focus, Respect & Openness) gave us confidence & courage to be more aligned & have better coordination. And, it happened because we understood the value of communication & alignment. What can be better example than: “One member actually managed to get pass from govt. administration, to visit the remote locality, just to get one device & make it available to another team member so that we can deliver the feature timely”.

Approach for Future:  Now we are prone to have such pandemics in future also and we should be prepared further. In my opinion, the very first step is to understand what the problem is at core & so we need to talk. The approach will be the same, find out core problems & let’s brainstorm to solve these, like we did this time (Retrospective & more coordination). 

I understand that this Covid-19 is unforeseen challenge & might be, we’ll never be out of it. But I cannot deny, it gave, everyone in general, and I & my team specifically, a new way of thinking, new kind of team-spirit, next level of maturity and great confidence to handle such challenges.

One thing still needs improvement that is related to our geographic culture. In our geography, most of us are not supporter of working remotely ( like Work-from-home) and that is why most of us don’t have certain arrangements like dedicated space, working hour ethics at their end (home or anywhere else) which sometime create unnecessary delays & disturbance. I believe, everyone at her/his level making effort to improve such scenarios and is this not the essence of Agile - “To Inspect the current scenario, Adapt the better way and Learn from it for future”?

Krishna: The Ultimate ScrumMaster chosen by Pandavas (The Team)

Krishna: The Ultimate ScrumMaster chosen by Pandavas (The Team)

As per Vedas, somewhere around 5000 years back, Mahabharat (Kurukshetra war) battle had been fought. There were so many sequential events which led to the circumstances where battle became inevitable. There were 2 sides Kauravas & Pandavas. Both the armies (teams) participated in the event. We all know this.

Have you ever analysed the role of “Krishna” in that battle (event)? What he did? What he thought and to what was he accountable? Let’s see!

1-      Krishna did not fight the battle himself.

2-      He aligned Pandavas to the goal (which is actually not winning the battle rather re-installing the ‘Dharma’ on the Earth).

3-      He facilitated all the discussion among Pandavas to find the solution of problem. He took Pandavas on the same page and let them take the collective decision what to do next.

4-      Only when Pandavas were not able to take any decision, he ‘suggested’ the action-items.

5-      When Arjuna put down his weapons, he asked Arjuna to fight not-to-win but for the goal which “re-installation of Dharma”. He re-installed the Commitment, Courage & Focus among the Pandavas (the team).

Krishna was accountable only for “re-installing the Dharma” and keeping team motivated towards this goal for which he made Pandavas:-

a)       Committed towards the goal

b)      Focused towards the goal

c)       Courageous enough to proceed towards the goal (Here, pandavas were courageous enough to fight but when Arjuna saw relatives other end, Krishna made him & other courageous enough to take step which are required to achieve goal which is re-installing Dharma.)  

d)      Open enough so that they can say/suggest what they think

e)      Respecting each other’s quality among them. (E.g. – Yudhishthir every time spoke truth which created tough situations to handle. But other Pandavas supported their eldest brother.)

This battle had been fought for 18 days and after each day’s fight, Krishna facilitated discussion for Pandavas to inspect the incident and adapt & prepare for next day. He instilled the quality of ‘Empiricism’ (learn from today’s experience and plan for tomorrow accordingly) among the members.

I could see this as the qualities of ScrumMaster. The 2 things:-

1-      Reveal - not resolve, and

2-      Actively doing nothing

are something on which facilitation is based. Krishna was truly a facilitator for Pandavas during the complete event by: -

-          keeping them focused towards the goal (again, not winning but to re-install the Dharma)

-          keeping away from external distraction

-          helping them to identify the blockers (like Bhishma, Karna) towards goal and removing them

Along with this, He made team (Pandavas) able to earn trust on each other. Everyone trusted each other. This was one of the main ingredient of their success.

If not completely, isn’t it mostly in line of ScrumMaster’s responsibility?

Krishna correctly proclaimed:

“It is not my duty to do your work (fighting the battle). I’ll show the correct path to you and set the environment in which you can fulfil your duty.”

Most importantly, he left Hastinapur when the re-installation of Dharma was achieved (the goal).

“And ScrumMaster is succeed only when team is in condition when ScrumMaster is not required.”

Learn From Google Map to Grow as SCRUM Team!

Learn From Google Map to Grow as SCRUM Team

Today, it is very common & easy to use google map navigation when you are going somewhere. Just enter your source & destination and start navigation. Right after this moment, google map will do below activities for you: -

1. Calculate Estimated Time of Arrival as per current traffic scenario;
2. Highlights the best possible path to reach destination;
3. It also mentions the other available paths in grey colour;
4. During the journey, if traffic scenarios changes on the way, google map will highlight the other best alternate route;
5. If you change the destination in middle of journey, it accepts the change and highlights the best possible route to reach changed destination;
6. Once you reach destination, it notifies the same to you;

Along with these standard steps, google-map also does: -

a)       Learn about newly created route on the way. (Eg. – On your way, one new underpass or alternative route was constructed by Govt. When you & other travellers follow that route, google-map learns that there is another route here and after significant learning, it will start suggesting this route in navigation);

b)      It keeps check on time-taken during the journey. If time-taken is more or lesser than the predicted one, it learns whether this route has some issue (like some construction is going on) or the route has been improved. Based on this learning, it adapts the new changes and provide predictions accordingly;

c)       It learns whether a path contains toll booth. Accordingly, it highlights the same thing so that you might know about other extra expenses before journey;

Apart from these, it also does number of things. However, let’s consider only these activities performed by google map.

Let’s give a thought on this, doesn’t it look like standard activities of a project (or journey of a product). During the product development, we do: -

1. Set the product vision (the destination)
2. Create plan as per available resources (people, tools, budget etc)
3. Based on the information in #1 & #2, define the roadmap and estimated time of delivery
4. Since, during the development nothing (vision, people, tools etc) will be fixed or prone to change, the teams need to adapt these changes and come out with the best possible plan in the scenario
5. Once product has significant features, it will be released to customers
6. According to the further requirements, the future development will go on
7. During the development, team learns & enhance skills which results into better & faster product delivery
8. Team can foresee the other challenges, roadblocks, extra-cost during the product development and notifies this to business.

What we have seen, is the quality of Scrum: -

Inspection, Adaption and Transparency!

Google map is the prefect example which Inspect or Retrospect the surroundings and improve its knowledge and learns from the experience (Empiricism). It Adapt the changes coming in the surroundings whether new construction, any roadblock or extra-cost requirement or the destination itself has been changed from the original destination. Having the quality of Inspection & Adaption, it truly satisfies the need of being Transparent. It is transparent to user and providing the most correct information. These are the exact virtues of Scrum Teams who learns from experience, retrospect themselves & adapt the changes, embraces the change requests coming during the product development and ensure transparency among themselves & to organization.  

Scrum Teams, if you want to learn, grow & develop as an Agile/Scrum team, analyse the activities of google map doing for you & learn from it

  

Direction is more important than speed, Really?

We have heard many times like “Direction is more important than speed. Many are going nowhere fast”.

What does this mean? Why is Direction necessary? For software products also, do we need to focus on the direction?

Let’s think about it:

1. when you are going to the office, do you take the correct turn and take the shortest path to reach the office?
2. When you are investing your money to get better ROI, do you consider the multiple investment options and pick which is the most suitable in your scenario?
3.  You get married and as a life-partners to each other, do you consider few parameters (like financials, working-life balance etc.) before starting a family?

If the answers of all these questions are “YES”, it reflects that “you are not only executing your action-items, you are also planning and setting the directions up for the future.”

Then, why should not planning & direction should be set up for the software products?

Let’s consider another point of view:

Once Charles Darwin said – “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.”

We always heard that “Change is the only constant”. Consider below image which showcasing the expectation-zone and product journey: -

As we see in the above image, the expectation zones are moving with time. It is true for products also. There is one set of expectation from the customer when product manufacturing starts. However, as product development goes further, the customer's expectations & requirement also change. Therefore, it is necessary to accommodate these changes in the product development phase. It is necessary to follow the right “direction” while developing the product so that maximum business value might be achieved.

Agile is a culture that facilitates the environment which embraces the changes and motivates the team to work on the most important requirement. It provides “Direction” along with speed to develop the product. (You can read more about agile at the below location: - https://agile-is-culture.blogspot.com/2018/06/agile-inculcating-culture-of-ci-cd.html )

Now, the question is how Agile facilitate such an environment which is responsible to provide the correct direction to team & product? As we already know there are 4-pillars of Agile Team:-

1- Scrum Team
2- Product Owner
3- Scrum Master
4- Stakeholders

Let's see the point-of-view of each entity: -

Scrum Team Member – “I do my work and I do it well, but my race isn’t won until all my fellow team-members cross the finish line with me. We win as a Team. I check my title (as well as ego) at the door; I am willing to do whatever it takes to help the team succeed, even if that means working outside my area of expertise or comfort zone.”

Product Owner – “I own this product and I want to see it succeed. I will only ask the team to build what has Business Value and ROI for my organization. I am a consensus builder and I love marketing and selling the value of what the Team has accomplished.”

Scrum Master – “I don’t succeed unless the Team Succeeds. My mission in life is to grease the wheels and ensure that everyone is playing nice and that the process is running smoothly.”

Stakeholder – “The Product that the Scrum Team produces for me has value, I need to be involved in providing ideas and seeing the results. Please don’t keep in dark and feed me the misinformation. I would rather be a part of development process and informed of how things are actually going, the good, the bad and the ugly.”   

As we saw, each component of Agile-Team is committed to deliver the value. They put their efforts in One-Direction which ensures that highest-possible value is produced for the business.

Agile is culture which sets the sync between the direction of product development & team's effort.

Always remember:

"You cannot change your destination overnight, but you can change your direction overnight."  - Jim Rohn

Discussion on Agile & Technology (Layman friendly)

Go to the below link and this discussion may be helpful for you!
https://www.youtube.com/watch?v=zYmDjoPHZv4

"TUFE" is not TOUGH to understand!

I believe you are thinking "Ok, it's not tough to understand, but what is TUFE by the way?" So, TUFE is something which confused many of us many times and it is:-

T - Tasks
U - User Story
F - Feature
E - Epic

Most of the time, for most of us it is difficult to understand these & differentiate among these. I've tried to explain this here in the simplest way. Let's see!

First, consider the below Release plan & hierarchy from any organization for a particular Calander Year:-

As per this plan:-

1. The organization has 4 Releases in a year.
2. Each Release occurs after 3 Sprints. Therefore, the deliverable of 3 sequential sprints will be the part of MVP in a particular release (R#.#)
3. Each sprint has 30 calendar days.
4. The organization has taken the decision to have 6 hours capacity per person per day. So, there are 6 hours a Day. 

This was the top-to-bottom hierarchy of Releases.

Now, Secondly, consider another hierarchy and see how TUFE is placed:-

As per this hierarchy:-

1. Epic is the highest level requirement. It contains multiple Features.
2. Feature consists of the number of user story.
3. User Story consists of the number of tasks.
4.  Task is the lowest level requirement.

The interesting thing is that Release Hierarchy and TUFE Hierarchy is related to each other and has some relationship. Let's consider the below diagram and then let's try to find out the relationship in these:-

What does this relationship mean? 

It says:-

1. Epic - The high-level requirement which shall be completed in multiple releases and cannot be completed in a single release. E.g.- Create an e-commerce website.   
2. Feature - The high-level requirement which shall be released in a single release but cannot be completed in a single sprint. There will be more than one sprint to implement this requirement. E.g.- Implement Payment Gateway in e-commerce website
3.  User Story - The requirement which shall be completed in a particular sprint but can or cannot be completed in a single day. E.g.- Create Payment Gateway page as part of Payment Gateway implementation in E-Commerce website.
4. Task - The lowest level requirement which is the subset of a user story. It shall be completed in a particular day but can take a number of hours in a single day (say 3 hours out of 6 hours). E.g.- Add Image for Credit/Debit card option at Payment Gateway Page etc.  

Was TUFE tough to understand, really?

AGILE: Inculcating The Culture of CI & CD (Continuous Integration & Continuous Delivery)

Agile, whether considered as Culture or Framework, is attracting many around the world. In the world of complex development & rapidly changing demands, agile is inculcating the culture of responding to the customer’s changing requirement & deliver the concentrated business-value in the form of the product. Agile does this in many ways & CI/CD is one of them. Let’s dive into CI/CD & SCRUM and see how SCRUM can facilitate the CI/CD & ensure that extensive business-value is being delivered to the customers.

What is CI / CD (Continuous Integration / Continuous Delivery)

The development of complex product needs a long timeline & most of the times more than one team works together to deliver the common product. All these teams work in same iteration/sprint. At the end of the sprint, all teams deliver their MVP (as a part of sprint deliverable) & all these MVPs from different teams combinedly becomes the Product Increment (PI).

Lets’ understand CI & CD:

Continuous Integration (CI):

Most of the time, during the development of complex products, the work is done in sprints/iteration & by the different-different members of the team. They share the same code base & continuously enhance/update the code to implement new functionalities/enhancements.

“Continuous integration is the process in which multiple members of multiple teams write the code in the same code-base in such a way that the newly added code is merged into the older code without breaking anything.”

To understand the concept of CI, consider the below diagram:

Dev1, Dev2…& so on are working on the same codebase for their respective implementation (on their respective User Stories). After the completion of implementation, all developers do the unit testing to test the implementation. After that, they transfer the code to ‘Test Branch’ where QAs execute the testing. Once the QA is completed, the code is merged the Source Code Master(SCM) branch. Now, this SCM branch has all the code from multiple developers. Then, this SCM branch code goes for build & the updated functionality is ready for Integration Testing. Now, these integrated functionalities pass through the “Integration Test” which ensures that “all the integrations done into the code are bug-free & not breaking anything.”

In this way, Continuous Integration is implemented.

Continuous Delivery (CD):

Continuous Delivery (CD) is the mechanism which ensures that “product can be released anytime”. As we have seen earlier in Continuous Integration, teams work in multiple iterations & continuously integrate the new code into the Codebase to implement the new/required functionalities.

Continuous Delivery goes one-step ahead to the Continuous Integration. Consider the below diagram: -

As this diagram depicts, after the Continuous Integration, Acceptance Test is performed over the integrated code base to ensure that:

•        The integrated code is In-line with the expectation of the client
•         Integrated code Does not have show-stopper issues
•         Integrated code Pass through the Acceptance Test phase, &
•         It Can be released anytime to the client

After passing the Acceptance Test, the product becomes eligible for release & to be deployed in production.

In this way, this is the concept of CI / CD.

Let’s dive into the SCRUM now.

What is Scrum

Being one of the methodologies under Agile Framework umbrella, Scrum ensures the iterative development. Originally, this term has been taken from RUGBY. Consider the below diagram:

Scrum is an iterative development cycle. These iterations are called sprints. Each sprint has a definitive goal which is based on the customer’s vision & business-value. Before going further, let’s consider the below SCRUM cycle: -

 As shown in diagram, there are below steps involved in the Scrum cycle: -

1-     Stakeholders / Product Owner meet the customer & brainstorm the customer’s requirement. They prioritize or outline the work that needs to be done as a product in general & in upcoming iterations (aka Sprints) as specific. As a result, the Product Backlog is prepared. This backlog shows the roadmap & vision of the product.

2-     There are some refinement sessions organized by Product Owner with Scrum Team (Developer, QAs, Architects) & Scrum Master. The story point estimates, dependency, blockers & other required details come to the surface for the user stories which are present in Product Backlog.

3-     Then, Sprint planning comes into the picture. Scrum Master leads this ceremony with Product Owner & Scrum Team. The refined Product Backlog is taken as input for this sprint planning & on the basis of capacity & required business value, User Stories are shortlisted from the Product Backlog to be taken into the sprint. Now, Sprint Backlog is prepared & sprint is kicked-off.

4-     During the Sprint, team works on the Sprint backlog item (finalized in #3) & perform the daily ceremonies. Scrum Master is the responsible to keep team away from distractions & remove their blockers & dependency.

5-     Finally, the team come up with MVP (Product Increment / Minimum Viable Product) which is called the sprint deliverable.

6-     This MVP is demonstrated to the Product Owner, Stakeholder & business people & collect the feedback, suggestions.

7-     Then, Scrum Team with Scrum Master goes to retrospective meeting. It can be considered as “Lesson Learned” meeting where the team members keep trust & respect to each other & feel free to put their concerns before the team.

8-     Product Owner, stakeholders & client meet to discuss the requirement shift or priority shuffling. Accordingly, the changes need to be adjusted in Product backlog. Again, the cycle from #2 runs on. It goes continuously.

This is the complete Scrum Cycle.

Now, after having the understanding of CI/CD & SCRUM, let’s see how SCRUM facilitate the CI/CD in the projects.

SCRUM and CI / CD

We have seen SCRUM, CI & CD in this article & understood these concepts. Now, the question is How SCRUM is the facilitator of CI & CD? Consider the below facts: -

1-     In SCRUM, there is an iterative (aka Sprint) approach to development. In each Sprint, Scrum Team develops the solution & deliver the MVP

2-     Multiple members of the Scrum team work for the same product & share the same codebase

3-     After the iteration, all these newly implemented solutions merged into the original codebase & product increment take place. This product which is ready after the iteration with newly implemented functionality, is called MVP (Minimum Viable Product)

4-     The solution becomes ready to be released to the client after the iteration. It is done after Integration & Acceptance testing.

Along with these facts, consider the below SCRUM cycle again:

The scrum cycle runs in 1-4 weeks’ time window & this is the duration in which Scrum Team develops the solution for new requirements. These members use their respective development branch & transfer the code to Test branch for QA process. QA team collects the multiple solutions from the multiple members & run the Integration Test. All this work is done in the iteration or Sprint. When the QA is successful for all these multiple implementations, this solution is merged into the Master Code base & Integration testing takes place. After this testing, the product is ready to be deployed.

Therefore, SCRUM facilitates the continuous integration because all the development is done into the iterations & after each iteration, the newly developed code is merged into the original codebase without breaking anything.

When the Sprint ends, Sprint Demo ceremony is organized in which Scrum team runs the Demo of newly developed features. This complete Product (Older product, with newly implemented features aka Increments) is always ready to be released to the client.

Scrum ensures that after each iteration/sprint, the product should be able to be released & it is called the Minimum Viable Product. Because it is ready to be released anytime, it facilitates the Continuous Delivery.

Conclusion

Agile has become the culture which ensures that “the change in requirement from client does not go unheard”. Agile made the process so mature that teams are always ready to embrace the change & deliver the product which truly delivers the business value. Agile made it possible by introducing the culture of “Deliver in Iterations”. And, when it comes to working in iterations, CI & CD automatically comes into the picture because these iterations are continuous & in each iteration, teams are continuously integrating the new features & continuously delivering it to the client so that it can generate continuous business value to them.

Scrum facilitate the Sync between Customer’s Journey & Product Journey. AGILE-Scrum & CI/CD are not only the process to develop the product, rather these are the culture of respecting the ‘Changes’ & deliver something which gives multiplied business value.

Thinking Scrum? Let’s Play RUGBY!

Agile is becoming popular day-by-day. Agile, as a CULTURE, is becoming the lifestyle rapidly. It is exciting to know that agile is being used in all sort of industries like Software, Automobiles & Event management (e.g. - Weddings etc. See my blog - Getting Married? ‘AGILE’ Is Here to Help You!). To achieve Agility, there are number of frameworks available and Scrum is the most famous one. It is more exciting to know & understand Scrum in a RUGBY Way.       

Rugby is a game which follows the same sort of spirit as Scrum does. In Rugby, every member of the team has the responsibility to take the ball & touch the goal post. All the members unite together, play as team & work towards the same goal. Scrum teams, in the same way, unite & work together to deliver the MVP (Minimum Viable Product) after each iteration a.k.a. sprint. MVP can be considered like a Rugby ball.

Both Scrum & Rugby show the same thing:  One Team – One Ball - One Goal!

Except for the subject matter, Agile & Rugby have same characteristics as:

1-    Team Spirit – We, not ME!

Every member of the team shows the extensive amount of team spirit & ultimately these team-spirits & support results in the success. They all are dedicated & accountable to the goal & team. These team-members shows the unconditional support, trust & respect to each other.

2-    Adaptable Team

Both Agile & Rugby teams are highly adaptable. They are not bound to predefined strategies. Whether it is related to change the strategy at the playground or embracing the change as per customer’s requirement, they are accepting these & preparing themselves for these changes rapidly.

3-    T-shaped Skilled Team

These teams are cross-functional. Every member of the team is able to perform any required action & at the same time has expertise in some area.

What AGILE adopted from Rugby?

AGILE is an umbrella under which a number of frameworks fall like Scrum, Kanban, XP & Lean etc. Industries have adopted methodologies out of this list as per their requirements. E.g. – Toyota took Lean & Kanban; ThoughtWorks took XP. As you see in my previous blog, few Wedding planners adopted Scrum. 

Scrum is one of the most famous frameworks. Do you know the roots of SCRUM?

Yes, Rugby has given the concept of SCRUM. Scrum is the style in which players pack closely, play for the same goal & restart (after an interruption/iteration). In the same way, SCRUM is used to achieve goals in iteration by closely packed teams.

AGILE / RUGBY: Roles & Conflict Resolution?

The teams are the group of human & every human is unique. This uniqueness brings the differences among the human and so team-members. So, having conflict is obvious & that is why resolving them becomes undeniable.  

AGILE Teams have 3 roles which have the direct correlation with Rugby teams:

1-    Product Owner: The one who has the vision of product, strategy & what needs to be done on the playground (or workstation)

2-    Scrum Team: Cross-functional team working to achieve the same goal

3-    Scrum Master (or Referee): Performing roles like Facilitator, Information Manager, Conflict Resolver & Distraction Remover that too without having an authority within the team. 

The most important thing in Agile Teams is they are self-organizing teams. No manager kind of role is required because these teams are able to identify their action-items rather than being directed by Manager.

As we have seen the characteristics, roles & the performing techniques both in AGILE & RUGBY teams, it is not wrong to say that both have too much as common & inspired by the same spirit.

Think, Both Agile & Rugby are not like:  One Team – One Ball - One Goal – Similar Role!

But finally, it is not a strategy or planning or management which works alone for AGILE/RUGBY team. What really matters are the Team Spirit, Respect, Dedication, Self-organization, Cross-functionality & Work Towards the Same Goal and are these not creating A CULTURE when combined?