Author: Snehamayee Kulkarni

Basic Building Blocks – Incremental and Iterative

Meaning of the words Incremental and Iterative are

  • Incremental – Breaking into smaller units and building in pieces
  • Iterative – Repetitive so that feedback can be received

Scrum-incremental-iterative

Scrum is an Incremental and Iterative framework. What this means is that we break the work into smaller units and at the same time we aim to get feedback as quickly as possible from the customer.

The traditional vs Incremental-Iterative work can be described with following diagrams

Traditional Work

Iterative-Incremental Work

Handling Distributed Retrospectives

Following are some of my learning from handling retrospectives with Distributed Teams.

  • Build trust: The Scrum Master needs to develop a sense of trust and honesty within the team, which in turn will lead to a wider degree of openness.
  • Reduce effects of distance: The facilitator of a distributed retrospective needs to understand the cultural differences in the team. The Scrum Master needs to understand how different cultures interact when they want to change something or have issues they want to talk about that can help the facilitator encourage participation from all team members.
  • Set expectations: The facilitator, for distributed teams, should talk to the team ahead of the first retrospective and explain the expectations for the retrospective.
  • Understand the team members’ personalities: Teams have a different combination of personalities, and the facilitator of the retrospective needs to understand the personalities of team members to lead the meeting effectively.
  • Respect cultural differences: The Scrum Master needs to make sure cultural difference should not be taken lightly during the retrospective meeting in distributed teams.
  • Ask for comments before the retrospective meeting — what went well and what can we improve? Ask the team for comments about issues or problems they noticed since the previous Sprint retrospective and summarize them for team discussion. The result is still an action plan the team needs to change or continue in the period until the next retrospective.
  • Provide questions to focus the discussion: In a distributed setup, team members respond to a set of questions developed or selected by the team. The purpose is to focus on a few issues and address them effectively instead of trying to address a lot of issues and address them poorly.
  • Discuss reported issues: During the retrospective, the team reviews the reported issues and, if others feel strongly enough, the team addresses them, creates action plans, and logs them as actions they will revisit in later sprint retrospectives to evaluate their success.
  • Effective and overlapping retrospective meeting timings: To be effective and timely, distributed teams should call joint retrospectives as soon as possible after having their own team meeting. Depending on the number of teams involved in a joint retrospective, teams may want to limit the number of participants from each Scrum team to keep the meeting productive.
  • Hold joint retrospectives: The distributed teams working together will conduct their individual sprint retrospectives at the end of each sprint and then will conduct a joint retrospective. The benefit of this approach is that it promotes communication between the various teams involved in a project.
  • Conduct milestone-based larger retrospectives: Distributed team members should reflect and comment on release quality and capability. The team defines and records the various milestones within the project to improve on or continue in future releases.
  • Release retrospectives: The team talks about the project, then defines and records the milestones in the project, like initial training, team formation, stand-up meetings, start of development, middle of release, deployment, etc.

Cross-functional Team

Perhaps the most prevalent and persistent myth in agile is that a cross-functional team is one on which each person possesses every skill necessary to complete the work. This is simply not true.

  • A cross-functional team has members with a variety of skills, but that does not mean each member has all of the skills. A cross-functional team has access to all the skills necessary to effectively deliver value to customers. A cross-functional team does not have to consist of all generalists. A cross-functional team also does not have to consist of all specialists.
  • You will generally find that a cross-functional team consists of a mix of people who have some knowledge about a lot of different areas, and others who are stronger in one area but are willing to help out in other areas where needed and when they can.
  • You generally want a stable, focused team such that they are working solely on the work of that team, which may cut down on the number of specialists on the team on an ongoing basis. You may instead opt for people that know enough about a certain topic and bring in specialist knowledge only for very specific occasions.
  • A cross-functional team does not require specific roles. You don’t have to have a designer on the team as long as there are people who are proficient at design. You don’t have to have a tester on the team as long as there are people who proficient at testing. You don’t have to have a development on the team as long as there are people who are proficient at development.

Context Of Scrum

The Matrix above shows the context of Product vs Teams.

  • When we define a Product – here we define a Independent Value Stream which makes sense from a market perspective.
  • When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
  • Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts.
  • Scaling means there are multiple teams working on a Product (Value Stream). Scaling is out of scope of Scrum.
  • “Many Products – Many Team” context is defined by portfolio management, which is out of scope of Scrum.
  • “One Team – Many Product” quadrant is for Staff Pools who do heterogenous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

SCRUM ONLY DEFINES ONE TEAM, ONE PRODUCT CONTEXT. SCRUM LEAVES IT TO SCALING FRAMEWORKS TO DEFINE SCALING AND PORTFOLIO MANAGEMENT FRAMEWORKS TO DEFINE PORTFOLIOS.

Handling Distributed Daily Scrum

Conducting the daily Scrums when team members are in the same time zone and speak the same language is much simpler than for a team with members spread in multiple countries and time zones, having many different languages and cultures.

Following are some my recommendations for handling Distributed Daily Scrums.

  • Ways of communicating during the daily Scrum: Having face-to-face daily Scrum meetings gives the team the highest level of collaboration possible.
  • Teleconference meeting: Distributed teams with overlapping work hours should use a teleconference call to the same phone number every day to hold their daily Scrum meetings.
  • Videoconference meeting: The main advantage of this approach is that team members get to see one another, so there is less nonverbal communication loss.
  • Approach to handling time zone issues: Distributed teams can use methods such as Daily Scrums through documentation, liaison approach, alternating meeting times, and share the pain to deal with distributed daily Scrums where the team has members with no overlap in their work hours.
  • Background noise can be distracting on a teleconference, so teams should chose a quiet room to conduct the meeting.
  • Keeping the team engaged: Possibly the best way to stay engaged and to make sure that others on the team stay engaged is awareness i.e. build awareness of what the team is working on.
  • Facilitating the meeting: In a distributed environment, as individuals come into the call, they will identify who they are. The Scrum Master calls each person and asks for their response. They may respond in the order they arrived at the teleconference or the Scrum Master may choose to call on each person.
  • Taking daily Scrum notes: This helps the distributed team members overcome language problems, plan and learn. Chat Tools help distributed teams do daily Scrums.

My Experience of handling distributed Agile teams

I have been working in Distributed Environment most part of my professional life. I have worked with US-India, India-Malaysia, India-Malaysia-Thailand, India-China and various other challenges. The geographical distances, cultures, language barriers, work-styles post challenges for most teams.

Following is a consolidation of various learning I had while working with Distributed teams. I believe, most of the challenges would be similar and therefore most of the learning that I had would be applicable to you too.

  • Scrum Teams should follow continuous integration, test automation, and test-driven development practice to foster distributed collaboration during the sprint and help teams complete user stories within a sprint.
  • Documentation helps to overcome distance: Because of language barriers, distributed teams often need more written documentation than co-located teams.
  • Using the right tools: In a distributed environment, right tools and effective practices can help team members communicate more effectively.
  • Valuing the whole team: The Scrum Master should focus on an “us” versus a “them” attitude in the distributed team, due to more delays in communications and fewer opportunities to work together.
  • Transparency: Distributed Agile teams should use project management tools to identify tasks that are open, in progress, and completed so everyone is aware of the current status.
  • Dealing with defects: Distributed teams may want to consider creating a user story with a certain number of story points in the sprint to deal with the problems, or they can set a priority for the maintenance tasks as per the customer log, or create a sub-team to focus only on handling these issues during the Sprint, or — depending on the skill set of the technical support team — make the necessary code changes.
  • Handling blockers during the sprint: In the large-scale enterprise transitioning to agile, the Scrum Master needs to hear from distributed Scrum team members who are facing blockers and dealing directly with inhibitors will help increase the velocity of the team over time, as well as the velocity of other teams as they transition to Scrum.
  • Responding to questions during the sprint: For enterprise product development, the Product Owner should look for ways to match representative stakeholders with the teams’ working hours and to be available during that time as well.
  • Sharing time zone challenges: One approach to help manage such cases is to make sure that distributed teams in different time zones are fully self-sufficient and the team spreads the work to minimize dependencies.
  • Automation and Continuous Integration
    • Continuous integration: This is the key to delivering stable, high-quality code consistently and quickly, which results in reducing time to market for any distributed Agile team.
    • Report any build failures to the team: Allows the distributed team to know the current state of the code in the integration branch of the source control system, generating a notification for build success or failure.
    • Reduce the risk of integrating code: Continuous integration ensures that a build runs regularly and allows the distributed team to identify integration issues earlier when they are less costly to fix.
    • Automated Test Cases: When developers are doing the unit testing of their code, they should also create automated unit tests as continuous integration certifies every build, developers can make changes with more confidence, and the entire team can remain in sync with the latest build.
    • Improve the efficiency of the team: Distributed teams’ efficiency can be improved by automating once and then reusing as much as possible. This removes human error, provides consistency, and frees up people to do higher-value work.
    • Builds can run at different frequencies: Setting up the hourly build helps the distributed team know about a failure closer to the time of the code integration, and team members can take action on it earlier.
    • Test automation: To streamline the testing and help the distributed team get as much done as possible within a two-week sprint, teams should automate time-consuming manual processes where possible.
    • Dedicated automation teams: The developers in distributed teams should tell what is ready to be automated to allow testers to closely couple with the product.

DevOps Tools

Tools are inherent to our jobs, inherent to how we solve the problems we face each day. Our comfort level with the set of tools that are available to us, and our ability to adapt to new tools as they evolve and shape our thoughts and ideas. The availability of collective knowledge within the palm of your hand combined with the collaboration across organization and company boundaries through open source software is dramatically disrupting the status quo of work. Companies mired in managing infrastructure configuration management by hand with unknown numbers of divergent systems, unable to quickly change and respond to market demands will struggle against their counterparts who have managed to contain their complexity on one axis through infrastructure automation. While it is possible to manage servers by hand, or even artisinally crafted shell scripts, a proper configuration management tool is

invaluable especially as your environment and team changes.

Even the best software developers will struggle if they are working in an environment without a version control system in place. Tools matter in that not having them, or using them incorrectly, can destroy the effectiveness of even the most intelligent and empathetic of engineers. The consideration you give to the tools you use in your organization will reflect in the overall organization’s success. You’ll find that what is a good tool for some teams might not be a good one for others. The strength of tools comes from how well they fit the needs of the the people or groups using them. If you don’t need feature X, its presence won’t be a selling point when considering which tool your organization should use. Especially in larger organizations with teams numbering in the dozens, finding one tool that meets the needs of every team will be increasingly difficult. You will have to strike a balance between deciding on one tool that will be used across the entire company consistently and allowing more freedom of choice among individual teams. There are benefits to both the consistency and manageability that comes from having only one tool in use in an organization, and also from allowing teams to pick specific tools that work best for then.

Because DevOps is a cultural shift and collaboration (between development, operations and testing), there is no single “DevOps tool”: it is rather a set (or “DevOps toolchain”), consisting of multiple tools in the Delivery and Deployment pipelines. Generally, DevOps tools fit into one or more of these categories, which is reflective of the software development and delivery process:

  • Plan – Planning Tools
  • Code — Code development and review, version control tools, code merging;
  • Build — Continuous integration tools, build status;
  • Test — Test and results determine performance;
  • Release — Change management, release approvals, release automation;
  • Deploy — Infrastructure configuration and management, Infrastructure–as–Code tools;
  • Operate and Monitor — Applications performance monitoring, end–user experience.

Though there are many tools available, certain categories of them are essential in the DevOps toolchain setup for use in an organization.

Tools such as Docker (containerization), Jenkins (continuous integration), Puppet (Infrastructure-as-Code) and Vagrant (virtualization platform)—among many others—are often used and frequently referenced in DevOps tooling discussions. Typical stages in a DevOps toolchain looks like this

DevOps Toolchain

A Framework

Scrum is a Process Framework. The word Framework means “MINIMUM SUPPORTING STRUCTURE”. Scrum does not define any details related to tools, techniques, implementation details or does not give specific recommendations on how to deliver complex work. Scrum defines the following

  • 3 Roles – Scrum Master, Product Owner and Development Team
  • 3 Artifacts – Product Backlog, Sprint Backlog and Increment
  • 5 Events – Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective and the Sprint

Beyond the minimum, Scrum gives flexibility to add things to the framework as the Scrum Team desires to. For example, there could be a mid-Sprint Review, there could be an additional Demo meeting to the PO, User Story could be used as a technique to represent scope, Automation tool such as Selenium could be used to implement regression test automation etc.

What is a Method?

Method is much more than a framework. Method may contain a framework of its own, but may also includes :

  • Tools and Techniques
  • Detailed Processes
  • Detailed Guidance
  • Templates
  • Document Formats
  • Organizational structures
  • etc

Example of a method is Extreme Programming

process methodology framework

A Metaphor of Framework vs Method

A Framework – Essential supporting structure – a Empty Photo Frame with a Glass

aFramework

A Method – Details, Tools Techniques – An Photoframe along with the Photo which gives all details

a

DevOps, Lean, Scrum, Agile

DevOps shares many characteristics with the Agile/Lean movement, especially with the focus on individuals, interactions and collaboration. You might wonder if DevOps us just “rebranded” Agile/Lean. While Devlops has certainly grown out around agile/Lean methodology, it is a separate cultural movement steeped in the history of the computing industry with a broad reach that includes more than just developers. DevOps adopts and extends Agile principles and applies them to the entire organization, not only the development process. Some of the important practices which support DevOps are

Agile

  • Agile Manifesto defines the 4 Values and 12 principles around which the whole Agile movement revolves. Especially the 4 values are very relevant to DevOps Movement
    • Individuals and Interactions OVER processes and tools
    • Working Software over Comprehensive Documentation
    • Customer Collaboration over Contract Negotiation
    • Responding to Change over Following a Plan

Lean

  • The 5 lean Principles support the DevOps movement
    • Value : Focusing on Value being created for the customer not just on delivering requirements.
    • Value Stream : Focusing on elimination of wastage
    • Flow : Flow helps in focusing on completion and getting tangible delivers out to the customer
    • Pull
    • Continuous Improvement : Continuous improvement mindset results in constant improvements in your product which is one of the core requirement of DevOps mindset.

Scrum

  • Scrum is an Agile Framework which also supports the DevOps in various ways. Some of the examples are
    • Scrum advocates frequent delivery in the form of Sprints. The objective is to produce a potentially shippable increment every iteration.
    • Product Backlog help define operational elements, testing elements and end to end elements commonly called the Product Backlog Items
    • The Daily Scrum meeting is a useful meeting for inspecting and adapting daily. This helps in collaboration between the various teams to produce potentially releaseable increment.
    • The Review meeting every sprint is a good way to get feedback from the customer every iteration and thus inspect and adapt.

Distributed Scrum Teams

Today businesses are shifting to emerging economies (such as India) due to reduced business operations cost and an easily available workforce. The businesses certainly are more virtual and distributed, with “distributed” as its key element. Thus the need for better managing such teams, using the right tools and processes, is becoming increasingly critical for any enterprise company.

   Here are some reasons for the shift and need for having distributed Agile teams:

  • Globally distributed teams reduce costs.
  • They can reach the market more quickly with a “follow the sun” model.
  • Distributed teams expand access to new markets.
  • Acquisitions as a result of consolidation results in companies working together to integrate their businesses.
  • Expansion can aid innovation and thought leadership.
  • Telecommuting gives options for communicating with teams effectively.
  • Collaboration tools — improved tools for distributed communications and server-based, multiuser tools for product development — are removing barriers, and more teams view distributed collaboration as an alternative.

Handling Distributed Scrum Teams

  • Distributed teams increase the need for clear, timely communication between sites. You might be thinking of increases in complexity due to more time zones, language barriers, and cultural differences getting in the way.
  • Communication is the core issue among the distributed teams. Different time zones, conflicting working hours, cultural and language barriers impact communication and collaboration.
  • Investing in effective enterprise tools for requirements repositories, source Control management, build and deployment setup, defect tracking, and project management tools is essential.
  • Practicing Test Driven Development (TDD), Continuous Integration and Automation of Testing are recommended
  • Proper communication setup such as telephones and videoconference are essential in a distributed setup.
  • Telecommunication etiquettes such as conversation using round-robin technique, importance of mute etc are essential hence a upfront training or setting ground rules for telephone etiquette is essential.
  • Coordinating Agile and non-Agile teams: Making sure the non-Agile team is aware of the priorities of the Agile teams and keeping dependencies visible can help to prevent blockers between the teams.