Tag: scrum

Conducting an Agile Workshop Series at work

Nishi Grover GargLeave a comment

Over the last three weeks, I had the opportunity to run a series of Agile workshops for my team — an experience filled with learning, collaboration, reflection, and plenty of fun moments.

I spent my first few weeks exploring how we work today, what’s possible tomorrow, and how we can evolve our ways of working using agile thinking. And when it was time to get ideas to practice, we needed more hands on deck! That is when we created our ‘Agile Guild’ – a core team who would not only help plan and conduct the workshops but also help align all team members to the core principles as and when needed.

🐝 Together with our newly formed Agile Guild, we explored where we are today and where we want to go as an agile organization.

🦄 We brought in new concepts tailored to our context, introduced working in Agile Pods and even reimagined how we use JIRA — moving beyond traditional sprint management — to a setup that truly fits the way our teams operate!

💡 Workshop 1: Deep-dive into our existing processes, pain points, and failures — followed by Agile fundamentals to build a strong base.
🚀 Workshop 2: Our recommended implementation plan using Agile Pods, and strategic discussions on how we can transform the way we deliver.
📊 Workshop 3: Hands-on introduction to JIRA Plans, and how we’ll use it to create clarity, alignment, and predictability across our pods.

🐬 From insightful discussions to hands-on team activities, the sessions sparked great energy and alignment.

🦋 What I loved most was the energy — team activities, honest conversations, shared learning moments, and a clear roadmap for what comes next.

🪴 Feeling grateful for the engagement, the curiosity, and the collective commitment to continuous improvement. Excited for what’s next! ✨

P.S. – The iconic view in this room was the icing on the cake! 🙂

(What you see – The landmark Erasmus Bridge of Rotterdam over the serene waters)

#Agile #AgileTransformation #AgileLeadership #ScrumMaster #TeamLearning #ContinuousImprovement #WaysOfWorking #JIRA #WorkshopFacilitation #LeadershipInTech #AgileCoaching

From Team to True Squad: Building Synergy in Scrum

Nishi Grover GargLeave a comment

I’m excited to share my latest article, “From Team to True Squad: Building Synergy in Scrum,” recently published on Devm.io!

We often hear about the importance of teamwork when we talk about agile and Scrum in particular. But there’s a massive difference between a group of individuals that work together and a squad that truly clicks. Building a high-performing Scrum team is less about following rigid frameworks and more about nurturing relationships, creating trust and creating a shared vision & sense of purpose. What truly elevates a group of individuals into a high-performing squad is synergy—that magical cohesion where the whole is greater than the sum of its parts.

Key Insights from the Article

🔹 Continuous Improvement: Agile squads thrive when retrospectives are used not just as a ritual but as a powerful tool for learning and growth. The key is to focus on actionable feedback, addressing both the wins and the pain points. Improvement isn’t a one-time event; it’s a mindset that fosters resilience and adaptability.

🔹 Alignment with Autonomy: Balancing squad goals with overarching organizational objectives can be tricky, but it’s essential. Alignment ensures that the team delivers value, while autonomy empowers them to decide how to deliver it, fueling innovation and ownership.

🔹 The Role of Trust: A true squad is built on a foundation of trust. When team members trust each other, they feel safe to share ideas, challenge norms, and admit mistakes—without fear of blame or judgment. This psychological safety is the bedrock of creativity, collaboration, and continuous improvement. Leaders must actively foster trust by encouraging open dialogue, leading by example, and celebrating team wins.

🔹 Fostering Synergy: Building synergy means creating an environment where collaboration isn’t just encouraged—it’s ingrained in the squad’s DNA. This involves clear communication, shared accountability, and a shared vision of success.

Why It Matters

Agile is more than a process; it’s a way of thinking. When squads embody these principles, they don’t just deliver—they innovate, inspire, and transform.

📖 Read the full article here: From Team to True Squad: Building Synergy in Scrum

I’d love to hear your thoughts:

  • How do you foster trust within your teams?
  • What strategies have helped your squads achieve true synergy?

Let’s discuss and share ideas!

#AgileLeadership #TeamSynergy #ScrumMastery #TrustInTeams #ContinuousImprovement #AgileSquads #LeadershipMatters #DevOps

Agile Metrics that Matter: Measuring Success in Software Delivery

Nishi Grover GargLeave a comment

In the world of software delivery, the agile approach has transformed the way teams work, adapt and succeed. Agile is all about delivering value quickly and iteratively, but how do we know our team is succeeding at that? The answer will lie in the metrics we track.

I tried to answer this in my article that was published on devm.io platform recently.

Why Metrics Matter in Agile

Agile metrics provide valuable insights into:

  • the health of our processes,
  • helping us make informed decisions,
  • identifying areas of improvement and, eventually,
  • delivering better software.

Before we get into specific metrics, it is important to understand why tracking metrics is crucial in agile development.

Agile thrives on feedback – whether it is from users, stakeholder, or the development process itself. Metrics provide that feedback, helping teams understand where they stand and where they need to go.

Metrics help us answer critical questions:

  • Are we delivering value quickly enough?
  • Are we maintaining quality as we move fast?
  • Are our customers satisfied with the product?
  • Where are the bottlenecks in our process?

Without metrics, these questions are left to guesswork.

With metrics, you have data-driven insights that guide decision-making, foster continuous improvement and ensure alignment with business goals.

Let us explore the key metrics that agile teams should track to measure success in software delivery.

1. Lead Time and Cycle Time

Lead time is the time taken for a piece of work from request to delivery. It includes everything from the requirement coming in, to the idea generation, coding, testing & deployment.

Cycle time is the time it takes to complete a specific task or user story from the moment work starts on it to when it is finished. Unlike lead time, cycle time doesn’t include the time spent in backlog or waiting for the work to start.

In agile, the goal is to deliver value quickly & frequently. Lead time tells you how quickly your team can turn ideas into working functionality. Shorter lead time would indicate a more efficient process and better response to market changes.

Cycle time helps you understand the efficiency of your team’s workflow, and how long it takes to deliver a piece of work once it is in progress. Shorter cycle times mean that the team is working efficiently and can handle more tasks within a sprint.

—- Follow the link to read further —–

https://devm.io/agile/agile-metrics-software-delivery-analyze

About devmio

devmio is an IT and Tech conference platform that goes beyond the conference room. Join live events, read magazines and articles from the IT experts you know and love! You can join the live events to chat with experts, read magazines written by experts and attend conferences with exclusive discounts all accessible with their Fullstack Experience membership. Join here -> https://devm.io/

🌟 New Milestone Unlocked: Advanced Certified ScrumMaster (A-CSM) 🌟

Nishi Grover GargLeave a comment

Guess who just levelled up in the agile universe? 🚀 I’m thrilled to share that I’ve officially earned the Advanced Certified ScrumMaster (A-CSM) certification, a prestigious milestone for agile leaders, coaches, and Scrum Masters! 🏅

This journey wasn’t just about the certificate (although it does feel good to have it in my portfolio!) – it was about embracing continuous learning, stepping out of my comfort zone, and investing in my growth as a professional and as a person.

Here’s the thing: Growth doesn’t happen by accident. It happens when you choose to prioritize learning, say yes to challenges, and remind yourself that there’s always more to explore. 🌱

This journey has been an incredible deep dive into advanced Scrum practices, fostering team dynamics, facilitating agile processes, and creating environments where teams thrive and deliver value consistently.

Here are a few key takeaways from this certification:

  • The art of servant leadership: Empowering teams while giving them the space to innovate and grow.
  • Advanced facilitation techniques to navigate challenges and boost collaboration.
  • Building a culture of continuous improvement, focusing on delivering value sprint after sprint.
  • Strategies for addressing team dynamics and unlocking each team member’s potential.

This certification is more than just a badge—it’s a reflection of my commitment to continuous learning and evolving as a Scrum Master, agile leader, and team enabler. 🚀

💡 I’m excited to apply these insights to empower teams, improve agility, and help organizations achieve their goals. If you’re passionate about agile, Scrum, or leadership, let’s connect and exchange ideas!

💡 A little nudge for you:
If you’ve been thinking about that course, new technology or skill you’ve always wanted to pursue—this is your sign to go for it. Future you will thank you. 💪

💬 Let’s keep the conversation going! What’s one learning milestone you’re proud of, or something you’ve been wanting to tackle next? Drop it in the comments—let’s inspire each other! 🚀

My experience speaking at DevOpsCon, Singapore 2024 – Talks, Learning, and Inspiration

Nishi Grover GargLeave a comment

Last week, I had the wonderful opportunity to attend and speak at DevOpsCon Singapore, an event that brought together some of the brightest minds in the DevOps and agile communities. It was an experience filled with learning, sharing, and connection, all while revisiting the vibrant city of Singapore.

My Talks at DevOpsCon

I had the privilege of delivering two talks, each centered on topics I am deeply passionate about:

  1. Mastering Test Automation: Strategies for Maximum Efficiency and Impact
    In this session, I explored how teams can elevate their test automation game to ensure faster feedback, better quality, and smarter integration into CI/CD pipelines. We discussed practical strategies, real-world examples, and tools that can help achieve these outcomes. The engagement and thoughtful questions from the audience truly made this session a delight.
  2. Navigating the Agile Seas: Program Management in Startup Waters
    This talk was all about managing the unique challenges faced by agile teams in fast-paced startup environments. I shared insights and anecdotes from my own experiences, focusing on strategies for balancing speed with quality, fostering collaboration, and keeping teams aligned with business goals amidst chaos.

Both sessions were well-received, and I was deeply encouraged by the feedback and conversations they sparked. Knowing that my insights resonated with the attendees is always a humbling experience.

The Power of Learning and Collaboration

One of the highlights of the event was attending Ben Linders‘ workshop on Agile Teams Gamification. The session was not just informative but also incredibly interactive, showcasing how gamification can be a powerful tool to foster team collaboration and innovation. The exercises and insights were eye-opening, and I’m already thinking of ways to incorporate some of these ideas into my own work.

Workshops like these remind me of the endless possibilities for learning and the value of sharing knowledge within a community. It’s moments like these that inspire us to challenge conventional thinking and embrace fresh perspectives.

Reflections on the Event

Events like DevOpsCon are a testament to the power of tech communities. From engaging discussions with fellow speakers and attendees to exploring ideas that can reshape the way we work, the experience was nothing short of invigorating.

Beyond the technical learnings, it was also about connecting with people—whether it was hearing about their challenges, sharing stories over coffee, or simply realizing how much we all have in common in our pursuit of excellence.

Gratitude and Looking Ahead

I’m immensely grateful for the opportunity to represent my ideas on such a global stage, and for the chance to learn from some of the best minds in the industry. Sharing my knowledge, while also growing from the knowledge of others, is what drives me to keep pushing forward.

Here’s to more opportunities to learn, share, and grow together! If you attended the event or my talks, I’d love to hear your thoughts and continue the conversation.

#DevOpsCon #AgileLeadership #ContinuousLearning #Grateful #TechCommunities

3 Ways Technical Debt Can Actually Help Improve your Sprints

Nishi Grover GargLeave a comment

“Debt” is not a pleasant term. It brings to mind a burden and generates a feeling of anxiety. The same may also be true for technical debt, or the extra work that we incur while developing our software in the form of missed quality targets, pending tasks, or skipped points from our exit criteria checklists. Like monetary debt, technical debt happens when we make a decision that is quicker in the short term but will hurt us in the long term.

Though we may try our best to limit this debt, it will still happen. And while we will need to pay back the debt one day, we can also use it as a lesson to help improve ourselves and our processes. If it ultimately helps our development, it doesn’t even always have to be a bad thing.

In my article published on the Ranorex blog site, I examine three ways technical debt can actually help us improve our sprints.

Better Estimation

Though the first time incurring technical debt due to an inability to complete an activity as planned may not be pleasant, it should consequently improve the team’s estimation and planning.

Let’s say we had defined developers’ tasks for all user stories with estimated hours, along with a mandate of peer reviews being performed for all code being written. But the end of the sprint saw that though the developers marked their development tasks as done, none of the code had been peer reviewed before check-in. It could have happened due to lack of time or ownership.

The next sprint, the team then decides to have a separate sub-task for peer reviews under the development tasks, each of which is assigned to a peer with an allotted time of 30 minutes. This helps the team plan, have clarity around what tasks are pending, and see how much effort is being spent on the tasks.

So, even though you may begin to accumulate technical debt early on in your sprints, understanding the cause and having a plan of action may improve the team’s overall performance.

Sequencing and Prioritizing

If you find yourself at a point where release is a couple of sprints away and you have a number of unresolved defects, even though they are lower severity, the team may decide to reduce open defect counts for a sprint rather than adding new features. The technical debt incurred in the form of defects can urge the team to refocus and shift priorities.

Or, let’s say your team agreed to 70% automation of regression testing in the beginning of the release cycle, but after four sprints, the scripts they created are showing signs of being unmaintainable or not scalable enough. This may affect delivery in the end, so some testers may take the call of focusing full time on reworking the scripts and adding new automated tests to them, while the other testers take up functional and regression tasks.

My team once found out at the end of our fifth sprint that our developers had not been performing static analysis of their code or creating the reports that were mandated for every sprint. Whatever may have been the reason, this meant that running those reports now was leading to hundreds of errors or warnings all pertaining to code formatting, naming conventions and comments. Even though these were minor issues, it required time to get them all corrected with thousands of lines of code.

Read More »

Defining Your Definition of Done

Nishi Grover Garg1 Comment

The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?

It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Check out my article published at https://blog.gurock.com/definition-of-done/ – Here I talk about some good ways to define your Definition-Of-Done

Brainstorm with your team

The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.

For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.

By doing this exercise you are baselining your expectations from each task, independent of its owners.

Consider quality goals

If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.

For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.

Read More »

The Agile Mindset: Cultural Changes for Successful Transformation

Nishi Grover Garg1 Comment

Agile transformations can be a challenging undertaking, and many organizations struggle with what is probably the hardest part of the transition: adopting an agile mindset. It is imperative that teams embrace the agile culture before they can fully embrace agile.

Let’s discuss the major cultural shifts needed for a successful agile transformation. Full article-> https://blog.gurock.com/agile-mindset/

Collaborating to Make Decisions

As I always like to say, agile is more a mindset than a process. It guides you to a better way of working and collaborating in order to deliver the most value to your users. But how you choose to implement those guidelines is up to you, and most teams coming from a traditional style of software development find this aspect the most challenging.

Teams are left to find ways to work together rather than having a process forcing them to do certain actions, follow certain processes, or organize specific meetings. There are no templates or techniques to adhere to and no rules to follow strictly.

This may come as a surprise and leave teams guessing since they are used to being told what to do and how. Agile drives them to think on their feet as they plan and replan their way through the development process. Read More–>

Being Comfortable with Visibility & Exposure

Agile gives everyone a voice and values every person’s opinion. Many teams have been used to only the manager speaking for them or having one representative in most meetings. As a result, some team members may feel flustered now that they’ll occasionally be in the spotlight. People who are not used to voicing their opinion are expected to speak in all forums. Hiding behind the team is no longer an option in agile.

This also means team members are valued as individuals and everyone’s contribution is recognized. Agile treats all team members as equals, whatever their role or designation. They are expected to estimate their own tasks, pick things to work on, collaborate with other team members, and provide value by the end of each iteration. Continue Reading–>

Read More »

4 ways Task boards can help Agile teams

Nishi Grover Garg1 Comment

A task board is a physical or virtual chart containing all current team tasks at hand and their progress over time. For an agile team, all sprint tasks can be represented on the task board, and their flow over various stages can be tracked in the daily standup meeting. Task boards are a great way to visually representing pieces of work and their status.

Besides helping to organize and track work and being the focal point of the iteration and relevant meetings, task boards can have numerous more benefits for an agile team. In my article published @Gurock, I have discussed four additional ways in which Task boards can help an agile team-> https://blog.gurock.com/agile-task-boards/

Different styles of Task boards

Main points discussed–>

  • Customize the process
  • Visualize their Scrum
  • Improve Commitment and visibility
  • Facilitate Team interactions

Click here to read more ->

‘Co-opetetion’ Among Agile Team Members

Nishi Grover GargLeave a comment

Agile focuses on motivated individuals acting together toward a common goal. Consequently, agile needs people to collaborate and requires complete transparency, communication, and cooperation, within and across teams. But at the same time, individuals instinctively try to outperform others in order to stand out in their teams.

This transition from individual responsibility to collective ownership is often the hardest part of the cultural shift that teams face when adopting agile. I have looked at ways to encourage healthy competition, more cooperation, and a sense of community among agile teammates in my latest article for Gurock – TestRail blog, the main points being-

  • Showing People the part they played
  • Have Co-workers appreciate each other
  • Measuring personal growth
  • Motivating with extra initiatives
  • Encouraging Collaboration and healthy competetion

Check out the complete article at – https://blog.gurock.com/agile-co-opetiton/ to find ways to encourage healthy competition and better team dynamics in your agile teams!