Tag: scrum

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 »
Advertisement

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!

A Day in the Life of an Agile Tester

Nishi Grover Garg1 Comment

An agile tester’s work life is intriguing, busy and challenging. A typical day is filled with varied activities like design discussions, test planning, strategizing for upcoming sprints, collaborating with developers on current user stories, peer reviews for teammates, test execution, working with business analysts for requirement analysis and planning automation strategies.

In my article for Gurock TestRail blog, I have explored a typical day in the life of an agile tester and how varied activities and tasks keep her engaged, busy and on her toes all the time!

agile tester.png

Let’s sneak a peek into a day in the life of an agile tester — > You will go through the daily routine of an agile tester and will experience their complicated schedule in real time.

Read full article

https://blog.gurock.com/agile-tester-work-life/

 

Getting Better at Agile — Using Agile Pods

Nishi Grover Garg2 Comments

Pod

Agile is an ever-evolving field, and its rate of change has exploded exponentially in the last decade. Businesses are constantly trying to catch up with the market pace—and evolving their processes accordingly. Scrum has seen huge success and led to easier adoption of agile in a lot of organizations, but there is a demand to further speed things up while allowing for flexibility in resource and time management. This pursuit led my team to what we call agile pods.

Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of our agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output.

My company, Winshuttle, started the transition toward agile pods by dividing our one large product team of about twenty people into smaller teams of four to five members and calling them pods. The requirements got divided as independent deliverables for each pod based on the expertise of its team members. Because the team members were responsible for the design, plan, delivery, and quality of the output, the ownership level increased dramatically. Also, because complete communication happened directly, the results were faster and more precise.

Pod Organization

An agile pod is designed as per the requirement of the deliverable, involving varying levels of management, development expertise, QA, and creative talent. These teams are customizable and may change depending on the current requirements, creating a relevant ecosystem leading to maximum innovation and faster delivery times.

Pod Features

Agile pod teams are designed to be self-sufficient. The team is self-organizing and works with minimum supervision, creating a higher sense of ownership and maturity. Also, because most required expertise is available at hand within the team, there is a minimum level of dependency on people outside the pod. The pods stay together until the requirements keep coming for their team—say, for one release cycle.

A pod consists of the following team members:

1. Core team: These team members are dedicated full-time to working for their pod. They are part of all discussions, decisions, and standup meetings. The competencies of the core team members add up to the competency of that pod. The core team members may be shuffled between pods during or after the release cycle according to the expertise required.

2. Part-time specialists: These team members are available as part-time resources to support specialized project needs of different pods. They may be working for multiple pods at the same time. Examples would be a UI designer, a white box tester, or an automation engineer.

3. Pod leader: The pod is led by a pod leader, who is responsible for prioritizing the work with the business management team, clarifying requirements, and replenishing the queue for upcoming projects periodically.

The project management team does not interfere with the working of the pod apart from supplying the requirements and clarifying doubts about functionality or priority of tasks to be picked. The pod leader is an interface between the pod and the project management.

Like in Scrum, the daily standup meeting is scheduled so everybody can meet and discuss their updates, tasks, doubts, and risks. The part-time specialists may be included in the stand-ups whenever they are working with that pod.

Leveraging and Working in an Agile Pod

In order to leverage an agile pod, it is important to define clear requirements and then have an onboarding time for the agile team members. The skills and specialization of the team members must be kept in mind when putting them together in a pod, and the onboarding time must be dedicated toward getting them to understand the process and develop a level of understanding among themselves. Working in such a self-organizing and disciplined structure requires guidelines, team spirit, and acceptance among the team members.

In my experience as a pod leader, the first few weeks can be empowering and taxing at the same time. When our team got the responsibility to plan out the complete release cycle, requirements, design, and delivery schedule, participating in all those discussions brought exposure and a broader perspective to all the team members. Though the planning, triages, and prioritizing were new to most team members, once we got the hang of it, it actually felt energizing.

Further on, the communication became direct from the pod to all nodes outside the team, such as the project management group, the outsourced UI design team, and the other pods working in parallel. This reduced the communication time, filled the information gaps, and gave a voice to all opinions alike, and many brilliant ideas came our way.

Also, a major difference came in the dynamics between the development members and testers. We shifted our seating arrangements together, putting the entire pod, including developers and testers, together in a cluster. There were no secrets to be kept! Because the quality was an inherent part of the deliverable expectations from the pod, developers volunteered to help review the test scenarios prepared before testing happened on their components. Testers volunteered to buddy-test each component before it was finalized and released for the iteration level testing. This led to lesser issues in our production level builds, and demos to the project management mainly went bug-free. This also meant no altercations within the team on issues because everything was discussed, reviewed, and tested at buddy level.

All in all, at the end of a release cycle of about five weeks, we released a major chunk of functionalities that would have been difficult to get delivered in the normal scrum manner by any manager in the same amount of time.

So, give agile pods a shot and see how much good may come out of it!

Do share your experience..

Also read my write up about Agile Pods – published at –

http://www.agileconnection.com/article/using-agile-pods-realize-potential-your-team?page=0%2C2