Avoiding Common Pitfalls During Vendor Selection

Posted by Kimi Mahajan on Oct 25, 2019 3:22:44 PM

Choosing a service provider to get your job done is something which many of us do on a regular basis - at home or at the workplace. Whether it is choosing the right broadband provider, the vehicle insurance company as homeowners or choosing the right coffee vending machine. 

Selecting a vendor that can offer a solution to meet your software or service-related needs is as crucial as choosing a partner for your business. It is a critical decision for an organization as the right vendor will have a considerable impact on the success of your business, and a wrong one will be nothing more than a hindrance.

When Selecting Your Vendor

When choosing a vendor, it is necessary to ensure that both the vendor and you understand the business, outcomes, and expectations to avoid wastage of resources. 

The vendor selection criteria may vary depending upon the organization but it is a must to include them in the inventory management plan. 

1. Assess Your Requirement

Before choosing any vendor, first, analyse what your project or organization want from the vendor. Hiring a vendor can greatly reduce your operational cost and effort in creating the product by yourself. You should document what your expectations and needs are from your vendor. This will greatly benefit you to outline the benefits of hiring a vendor. Later on, when deciding on between vendors you can compare these expectations with their offerings so that you’re able to match what you need from them and what they can offer.

2. Check The Offered Product

Next, you will have to do your own research and identify which vendors can provide you with the right solution as per your requirement. Provide an introduction of your business, a summary of your requirement for a one-on-one discussion. Demo the products to gain insights by porting a sample of your company's data into the available products to test out the entire workflow and know whether it will work for your organization or not. This will give you a fair idea of what will the product offer and how the system would be integrated into your company's existing business processes. By this stage, after you test the product, you will be able to weed out vendors to understand their profitability for your business.

3. Ensure Product Complies With Security Standards

It is important to check whether the offered product complies with your organizations’ regulatory standards, in terms of how data is kept and stored. Ensure that the vendor takes up the onus of helping you with the security and regulatory compliance of the product.

4. Review Past Performance

When you’re done evaluating the right solution for your project that falls within your organization’s budget, you should consider investigating the past performance of your chosen vendor and take the final decision. Consult the online business references to see their past reviews. However, it’s possible the vendor you're looking is new and untested and may not have online reviews. In that case, you can ask for third-party referrals. And in cases where vendors do get negative reviews, it is important to see how professionally they deal with them. 

5. Total Cost Of Ownership

By now, you will be left with 3-4 vendors and you will be deciding to go with one of them post this crucial stage of judging the total cost of ownership involved. You will have final discussions with your shortlisted choices on the upfront costs involved and the long-term cost of maintenance. The costs should be compared with all competitive choices to evaluate they fall within the organization’s budget. Also, this is the right time to mention whether you’ve any special requirements and needs from the vendor. Provide as much information as possible so as to select the best vendor in terms of price and service.

It is a time-consuming process for the project manager to know which vendor will deliver the well-maintained, scalable product as promised and at an affordable cost. And no matter how much you strategize, you won’t know whether you found a reliable vendor, until you give them a chance to prove. And when you feel the decision makes good business sense as vendor delivers exactly what you’re looking for, you need to nurture the relationship with them as you do with your employees.

Topics: Project Management, Enterprises

Delivering software that evolves business outcomes

Posted by Rahul Dewan on Aug 30, 2019 3:15:00 PM

When great people and processes come together, business outcomes get delivered. Learn how Srijan’s Agile maturity model delivers results for our customers.

Defining the right roles, staffing the right T-shaped people for these roles, putting together well-trained engineers, and product conscious quality analysts are ingredients that go into delivering predictability in software quality and budgets — into delivering software that delivers business outcomes.

“Doing it Right Team”

Srijan’s “Doing it Right” team model has delivered results for a large media publishing house in the US, for a global beauty brand and for a large global consulting company.

srijan-onsite-offshhore-delivery-model

The Srijan Onsite-Offshore Delivery Model

Same processes, every time

Srijans Project Delivery Processes w- Arunima Shekhar Ep 1 - Development, Testing & Deployment

Whether it is how JIRA boards are setup (swim lanes, owners of these swim lanes, permissions to go along), unambiguous documentation of ‘definition of done’, the tool-stack to integrate as part of our DevOps and the security processes we shall follow — we have the same setup each time before we begin development.  

 

 

no-non-sense-deployment-process

No non-sense deployment process

 

a-sample-kanban-board-in-jira

A sample Kanban board in JIRA

 

Talk to us to see how we can bring predictability to your product engineering.

Topics: Project Management

Data Lake Strategy:  6 Common Mistakes to Avoid During Implementation

Posted by Nilanjana on Aug 29, 2019 5:42:00 PM

While we have talked a lot about the rising need for data lakes, it’s probably as important to talk about how easily they can go wrong in the absence of a good data lake strategy. While most businesses expect phenomenal insights, not enough attention is paid to actually setting it up in the right manner. And that is where it can all start to unravel. 

It's not uncommon to see scenarios where businesses have invested a lot of time, money and resources into building a data lake but it’s actually not being used. It can be that people are slow to adopt it or it could be that faulty implementation actually made the data lake useless. 

So here, we take a brief look at six common data lake strategy pitfalls, and how to avoid them. 

Challenges involved in Loading Data 

There are two challenges involved when loading data into a data lake:

Managing big data file systems requires loading an entire file at a time. While this is no big deal for small file types, doing the same for large tables and files becomes cumbersome. Hence to minimize the time for large data sets, you can try loading the entire data set once, followed by loading only the incremental changes. So you can simply identify the source data rows that have changed, and then merge those changes with the existing tables in the data lake.

Data lake consumes too much capacity to load data from the same data source into different parts of the data lake. As a result, the data lake gets a bad reputation for interrupting operational databases that are used to run the business. To ensure this doesn’t happen, strong governance processes are required.

Lack of Pre-planning

Data lakes can store an unfathomable amount of data, but not planning the value of data before dumping it is one major reason for their failure. While the point of a data lake is to have all of your company’s data in it, it is still important that you build data lakes in accordance with your specific needs. Balancing the kind of data you need with the amount of data you dump into the data lake ensures the challenges of the data lake implementation is minimized.

Uncatalogued Data

When you store data into a data lake, you also need to make sure it is easy for analysts to find it. Merely storing all the data at once, without cataloguing is a big mistake for a few key reasons

  • Can lead to accidental loading of the same data source more than once, eating into storage
  • Ensuring metadata storage is key to a data lake that’s actually useful. There are several technologies available to set up your data cataloging process. You can also automate it within your data lake architecture with solutions like AWS Glue. 

Duplication of Data

When Hadoop distributions or clusters pop up all over the enterprise, there is a good chance you’re storing loads of duplicated data. As a result, data silos are created which inhibits big data analytics because employees can’t perform comprehensive analyses using all of the data.

All of this essentially re-creates the data proliferation problem data lakes were created to solve in the first place.

Inelastic Architecture

On of the most common mistakes organizations make is building their data lakes with inelastic architecture. Several of them start out with one server at a time, slowly and organically growing their big data environment, and adding high performance servers to keep up with the business demands. While this decision is taken because data storage can be costly, it eventually proves to be a mistake in the long run when the growth of data storage outpaces the growth of computing needs and maintaining such a large, physical environment becomes cumbersome and problematic.

Not the Right Governance Process

Not using the right governance process can be another obstacle to your data lake implementation. 

  • Too much governance imposes so many restrictions on who can view, access, and work on the data that no one ends up being able to access the lake, rendering the data useless
  • Not enough governance means that organizations lack proper data stewards, tools, and policies to manage access to the data. Unorganized and mismanaged data lakes can lead to an accumulation of low quality data, which is polluted or tampered with. Eventually the business stops trusting this data, rendering the entire data lake useless

Implementing good governance process and documenting your data lineage thoroughly can help illuminate the actions people took to ingest and transform data as it enters and moves through your data lake.

While this is by no means an exhaustive list, these are some of the most seen mistakes that businesses make. Plugging these holes in your data lake strategy sets you up for better returns from your initiative right out the gate. It also ensures that your data lake does not become a data swamp where information and insights disappear without a trace.

Working on a data lake strategy for your enterprise? Or building the right data lake architecture to leverage and monetize your data?

Tell us a bit about your project and our experts will be in touch to explore how Srijan can help.

Topics: Project Management, Agile, Data Engineering & Analytics

Preparing For A Data Lake Implementation

Posted by Kimi Mahajan on Aug 29, 2019 5:39:00 PM

Data remains a giant value generator and reinforces your enterprise’s ability to stay ahead of the competition.

However, managing, securing and storing data for its continued relevance and using that voluminous information to your advantage is difficult at times, and requires a streamlined process flowchart.

So, how do you make data more useful to you and benefit from its infinite possibilities? What are the cutting-edge tools you need to keep your enterprise future-ready?

We have already discussed the basics of Data Lake and  the expected stages of data lake implementation. Let’s dig deeper as to when and why to implement data lakes and how to strategize the implementation process.

When Should You Opt for a Data Lake

Here are a few scenarios you could be looking at, when it comes to enterprise data:

  • You’re working with a growing amount of unstructured data
  • You want to leverage big data across your offerings
  • Your organization needs a unified view of information
  • You need to be able to perform real-time analysis on data
  • Your organization is moving towards a culture of democratized data access
  • You need access to data, analytics and applications
  • Your organization can benefit from elasticity of scale

If one or more of these look familiar, then it’s time to formulate a phased transformational process.

Traditionally, an Enterprise Data Warehouse (EDW) has served as the foundation for data discovery and functioned well in defining the data according to its quality. However, EDWs are restricted in scope and ability, and are unable to handle data complexities.

So a data lake is required, to expand the possibilities of what you can do with your data. You can take a look at the whole data lake vs. data warehouse discussion, and see how they are actually complimentary.

That said, you can take a call whether now is the right time to start with a data lake or can you invest in that a few months/years down the line. And that depends mostly on your current business goals and challenges, and the kind of data that’s currently most valuable to you.

Here’s a list of pointers to consider before preparing to implement data lake architecture:

Type of Data

Data lakes are best used to store constantly generated data, which often accumulates quickly.

Usually streaming data has a common workload of tens of billions of records totalling to hundreds of terabytes. If you’re handling such huge amount of data, then you should definitely consider a data lake since the costs of structuring and storing it in a relational database will be too high.

Choosing to stay with data warehouse could be a better choice if you’re mostly working with traditional, tabular information, e.g., data generated by financial, CRM or HR systems.

Understanding the Intent

One of the great things about data lakes is the flexibility with which data is ingested and eventually be used, with a sole principle to ‘store now, analyze later’.

A data lake could be a good fit for a project where higher level of flexibility is required.

Complexity of Data Acquisition Process

The process of adding newly acquired data to your warehouse can often be a resource-intensive process. And the process can even get more complex when it comes to unstructured or semi-structured sources, with a serious ETL overhead in order to ingest the data into a format that your data warehouse can work with.

If this complex process is making you consider giving up on some sources altogether, it’s time to consider a data lake – which will allow you to store all the data with minimal overhead, and then extract and transform the data when you want to actually do something with it.

Existing Tools and Skills

A data lake would typically require big data engineers, which are difficult to find. In case of lack of such skills, consider sticking to your data warehouse until the prerequisite engineering talent is hired to manage your data lake.

Data Management and Governance

Both data lakes and data warehouses pose challenges when it comes to governance. Data warehouses pose the challenge of constantly maintaining and managing all the data, whereas data lakes are often quite difficult to effectively govern. Whichever approach you choose, make sure you have a good way to address these challenges as per your project.

The above points will help you decide to opt for data lake or not.

Once you decide to stay with data lake, blindly plunging into its implementation won't necessarily benefit your organization. The big picture of what you want to achieve with your data, and a strategy for a cohesive data infrastructure is crucial.

Strategy for Implementing Data Lake

A haphazard approach may lead to several challenges hampering the use of a data lake to support big data analytics applications.

In the absence of an overarching strategy, a lot of data handling best practices can get overlooked, causing challenges and bottlenecks further down the line. For example, not documenting the relevance of data objects stored in a data lake might make it difficult for data scientists to find relevant data and track who accesses what data sets and determine what level of access privileges are needed on them.

So, here are seven steps to avoid such concerns for implementing data lakes.

  1. Create a taxonomy of data classifications
    Classification of data objects plays an important role in how they’re organized. Identify the key dimensions of the data such as data type, content, usage scenarios, groups of possible users and data sensitivity as part of your classifications.
  2. Design a proper data architecture
    Apply the defined classification taxonomy to direct how the data is organized. Include file hierarchy structures for data storage, file and folder naming conventions, access methods and controls for different data sets. 
  3. Employ data profiling tools
    The segregation of data going into a data lake can be easily done by analyzing its content. Data profiling tools can help by gathering information about what's in data objects, thereby providing insight for classifying them. They can also help in identifying data quality issues to ensure analysts are working with accurate information.
  4. Standardize the data access process
    Use of diverse data access methods to obtain different data sets often pose difficulties. Standardizing the procedure with the help of a common and straightforward API can simplify data access and ultimately allow more users to take advantage of the data.
  5. Develop a searchable data catalog
    Prospective users might not be aware of what's in a data lake and where different data sets are located. A collaborative data catalog allows the users to know the details about each data asset and provides a forum for groups of users to share experiences, issues and advice on working with the data.
  6. Implement sufficient data protections
    Aside from the conventional aspects of IT security, utilize other methods to prevent the exposure of sensitive information contained in a data lake. This includes mechanisms like data encryption and data masking, along with automated monitoring to generate alerts about unauthorized data access or transfers.
  7. Raise data awareness internally
    Ensure the users of your data lake are aware of the need to actively manage and govern the data assets it contains with appropriate training. Knowledge of using the data catalog to find available data sets, and configuring analytics to access the data they need will help press upon them the importance of proper data usage.

Organizations are increasingly attempting to innovate processes, driving heightened service excellence and delivery quality. Interested in knowing how data lakes represent a smarter opportunity for effective data management and usage for your organization?

Contact us and let our experts do the talking.

 

 

Topics: Project Management, Agile, Data Engineering & Analytics

Your Step-by-Step Drupal Migration Guide

Posted by Kimi Mahajan on Aug 8, 2019 2:27:00 PM

With Dries’ latest announcement on the launch of Drupal 9 in 2020, enterprises are in an urgent need to upgrade from Drupal 7 and 8 to version 9.

Drupal 7 and 8 will reach their end of life in November 2021, and those who wish to stick to previous versions might possibly face security challenges.

Eager but unsure what the process would be like? This comprehensive guide aims to simplify the entire Drupal migration process for easy implementation.

Getting Started with the Migration Process

When site is upgraded to Drupal 7, the old database is upgraded to Drupal 7 structure. However, a different approach is followed when the site is upgraded from Drupal 7 to Drupal 8.

Upgrading D7 to D8

Step 1: Take back-up of your website

Start the migration process by making a local copy of your website. As making changes to live site is not recommended, it is a best practice to keep all data safe by taking a backup locally on your machine.

Step 2: Install fresh new site

Install a new Drupal 8 site by downloading the latest version of Drupal 8 from drupal.org.

Drupal 8.7 is the latest release.

Install the latest release of Drupal 8 along with installing dependencies with Composer.

Step 3: Prepare your Drupal 8 website for the migration

Setup a local Drupal 8 website on your machine as a destination website for the migration process.

Step 4: Verifying the modules are in core and enabled

Ensure Migrate, Migrate Drupal and Migrate Drupal UI modules are enabled on your Drupal 8 site. This can be done by navigating to the ‘Extend’ tab of your website and ensuring all the above modules are present in the core.

Now, check the three modules and click ‘Install’ button at the bottom of the page.

Verifying the modules are in core and enabled

Step 5: Upgrade your website

Go to your website and append the website address with /upgrade (www.<yourwebsitename>.com/upgrade) and follow the instructions. Now click ‘Continue’ button.

Upgrade your website

Step 6: Enter website details

On clicking ‘Continue’ the below screen comes up which asks you for the website credentials, database location and other details.

Enter website details

Step 7: Start the migration

If the database credentials to your source database are correct, the upgrade review page will appear on the Migrate UI. It will show the summary of the upgrade status for all installed modules on the old site.

As a site builder you should carefully review the modules that will not be upgraded and evaluate if your Drupal 8 site will work without the module.

click on ‘Perform Upgrade’ button.

Tip: Don’t proceed and perform the actual upgrade without first installing the missing Drupal 8 module.

Tip: If you get ID conflict warnings

If you manually create a node to the Drupal 8 site before upgrading and the source Drupal 6/7 site has a node with the same ID, the migration system will overwrite the node that was manually created in Drupal 8.

If conflicting IDs are detected, a warning about conflicting IDs will be shown which can be ignored to risk losing data or abort and take an alternative approach.

Depending on the size and types of content/configuration on the source site, the upgrade may take a very long time. Once the process is finished, you are directed to the site's frontpage with messages summarizing the results:

Upgrading D8 to D9

When it comes to migrating to Drupal 9 from Drupal 8, process is quite simpler. As D9 is an extended version of D8, it is much easier to upgrade. Read the complete guide of Drupal 8 to Drupal 9 upgrade to understand the complete process.

Alternate Method: Migration using Drush Command

Upgrading to Drupal 8 using Drush is useful when migrating complex sites as it allows you to run migrations one by one and it allows rollbacks.

If you are using Composer to build your Drupal 8 site, then you may already have Drush installed. However, if not, then you can install Drush from command line as follows:

composer require drush/drush

To migrate using Drush you need to download and enable the contributed modules: Migrate Upgrade, Migrate Plus and Migrate Tools.

Ensure the Drush is up to date (with the command: “drush –version”)

Now it’s time to start the migration through Drush with following drush command

“drush ://user:password@server/db — ://example.com –configure-only”

Where the below mentioned values can be with your values in the above command

  • ‘user’ is the username of the source database
  • ‘password’ is the source database user’s password
  • ‘server’ is the source database server
  • ‘db’ is the source database

Now check your migration status (with the command “drush migrate-status”)

Import the data with the command (“drush migrate-import –all”).

After successful migration, go to the structure->migrations to check the status of migration.

After successful migration, go to the structure->migrations to check the status of migration.

Check the list migration button next to the migration group ‘import from drupal 7’ to view the entire migrated data.

Check the list migration button next to the migration group ‘import from drupal 7’ to view the entire migrated data.

After clicking on all upgraded data will be visible. Click to the execute button and data will be imported.

After clicking on all upgraded data will be visible. Click to the execute button and data will be imported.

Once you click on the execute button, you will be redirected to the page with below mentioned options.

Once you click on the execute button, you will be redirected to the page with below mentioned options.

Import button imports all previously unprocessed records from the source into destination Drupal objects.

With this we come to an end of our Drupal migration process. If the above steps are followed carefully, a website can be easily migrated to the latest version.

Srijan has more than 35 Acquia certified Drupal experts with expertise in migrating projects to newer versions of Drupal. Contact us to seamlessly get started with the latest Drupal version.

Topics: Project Management, Drupal

Ensuring Vendor Diversity - Why Enterprises should work with small IT vendors

Posted by Gaurav Mishra on Sep 19, 2018 11:22:00 AM

Large IT vendors are great. They have huge teams they’re able to put at your disposal, they’ve been around and will be around for a long time, and more often than not they have the experience of working on a project like yours. In short, they are safe, reliable, and they will get the work done. 

Smaller technology companies, on the other hand, are never the first choice for enterprises because of several concerns:

  • Do they have a team big enough to serve my project?
  • Haven’t really heard about them. Are they any good?
  • They make a good point but what if they can’t deliver? Is that a risk worth taking?

 

These are all valid questions that an enterprise procurement team has to consider. But amidst these doubts, there might be a few key advantages that you might be missing out on.

Here are four unique benefits that smaller IT firms bring to the table:

Niche Expertise

While large vendors may have teams offering a lot of different technologies, each is a small part of their overall skill set. So you get a team that has a range of skills but often not enough depth of skills. On the other hand, small IT companies typically build deep expertise in niche technologies, which makes them capable of delivering more customized and sophisticated solutions with those technologies. 

For example, we work with a global consulting giant because they wanted a team that has deep expertise and experience of working with Drupal. They were already working with a large IT vendor, but not really convinced of their Drupal skills. We, however, had a team of Drupal developers experienced with deploying large-scale Drupal implementations. And that fit in perfectly with what the client was looking for. We have been working with them for six years now, and till date are the only high-skilled Drupal team they trust.

Interestingly, our engagement with them has also led to them expanding their previously limited Drupal project. Currently, they run a vast array of internal systems on Drupal including internal as well as customer facing websites that leverage Decoupled Drupal.

De-Risk Project Delivery

Not putting all your eggs in the same basket are widely accepted words of wisdom that should apply to hiring an IT vendor as well. And then why you need vendor diversity - a mix of different vendors working on your project Entrusting the entire project, or all simultaneous independent or interdependent projects to a single vendor is taking a huge risk on the delivery. In a scenario where the initial engagement is plagued by project management or delivery challenges, that impacts other downstream projects as well, severely delaying project timelines. The high initial investment and time spent in on-boarding a large vendor also makes it difficult to quickly change vendors mid-project.

Introducing small IT vendors into the project, especially for parts of it that demand niche technology expertise, is a good way to de-risk delivery. This could have two key advantages:

  • Segments of the project get delivered even if there are challenges with the large vendor. So you are just left with a huge bill with nothing to show for it.
  • Since you already have a different vendor in the mix, with understanding of the project (even if just a part of it), they can be easily brought in to either assist or replace the teams from the large vendor, if necessary. You save on critical expenditures in the middle of the project, while being able to bring it back on track.

Agile and Transparent Project Management

Small companies have tighter teams, shorter hierarchies, and less red tape which allows them to move faster on projects.

While Agile is an accepted projected delivery method across most IT teams, it is easier to follow rigorously with smaller, tightly integrated teams. And that ensures a more streamlined, flexible, and faster product development and delivery process.

For example, one of our clients, a global financial services firm, had stalled their product development owing to the US$ 1 million budget, and six month delivery timeline quoted by a large IT firm.

We came on board and offered to do a PoC delivering the most complex piece of their product. We did it at an investment of US$ 50,000 and in just four weeks. The lower investment and shorter delivery time gave the client confidence to move ahead with the project. We successfully delivered the complete product and have been maintaining it for a few years now.

In addition to the speed, teams brought in by smaller vendors are more amenable to working in close collaboration with your internal teams, and aligning to your delivery processes. This gives your stakeholders better visibility into the project, and hence greater control. Given the shorter hierarchies, you also have easier access to vendor-side decision makers in case you need to escalate certain challenges and concerns.

Superior Service and Delivery

Smaller IT vendors specializing in a specific set of technologies are small by design. They choose to work on a limited number of projects at a time, and that creates a huge advantage for their clients.

Teams from smaller vendor firms are highly focussed on their respective projects, and not spread out too thin across different projects. This means greater attention to your particular project, with teams making the effort to identify and develop the right technology solutions, and taking the time to truly innovate to meet your requirements. With a fully dedicated team, you can also be assured of timely delivery and a more transparent project management process.

Yes, a small IT vendor may not be an immediately logical choice for enterprise procurement teams. But these advantages definitely make them a viable contender, especially when it comes to developing highly customized solutions leveraging specific technologies. What they might lack in numbers, they more that make up for in skill levels, flexibility, and accessibility.

Srijan’s 250+ strong technology team is currently working with global enterprises across seven countries. Our extensive expertise with Drupal, as well as skilled teams for complementary technologies, enable us to successfully deliver a range of transformative digital solutions to our enterprise clients.

Working across media, travel, retail, telecom, and pharmaceutical industries, we typically kickstart our engagements with small PoCs. That helps our clients assess if our technology expertise fits their requirements, and how our teams work and deliver.

Got a digital transformation project in the works? How about we do a quick PoC to demonstrate the benefits of working a smaller vendor?

Tell us a bit about your project, and our solution experts will be in touch.

Topics: Project Management, Enterprises

How to measure the progress of a Kanban project

Posted by Siddharth Goswami on Jan 4, 2018 12:12:00 PM

Before we jump to the core Kanban metrics, I would like to touch upon the core principles of Kanban development. They are: 

  • Visualize the workflow

  • Limit WIP

  • Continuous measurement and improvement of the life cycle

 

We have covered the first two principles in a previous blog post, Getting Started with a Kanban Project on JIRA. We will cover the third principle in this post: how to measure the performance of a Kanban project and how to improve upon it. 

Kanban Metrics to Track

Let’s look at the Kanban flow-chart from the perspective of a treasure hunt.

The game has which several teams that are competing to find the treasure by solving five puzzles at various stages, and procuring the treasure at the end of the last stage. All the teams will begin at the same time and will be given the same puzzle to solve. The team that reaches the treasure in the shortest time will be declared the winner. The shortest possible time can only be achieved when a team completes each of the five puzzles faster than the other teams. In order to gain lead time over the other teams, each team has to solve each puzzle faster than the others. 

Therefore,

Best Lead Time = Min(Cycle Time at Stage 1) + Min(Cycle Time at Stage 2) + Min(Cycle Time at Stage 3) + Min(Cycle Time at Stage 4) + Min(Cycle Time at Stage 5)

The below-mentioned definition will explain the Lead Time and Cycle Time in a better way for a Kanban project:

  • Lead time: This tells you how much time it will take to finish the task after it is received from the customer.

  • Cycle time: This is the time required to complete a certain task after the developer starts work on it. 

 

If we relate the above example to any Kanban project, the development team will have to focus on achieving a minimum lead time by continuously focusing on reducing the cycle time for each of the work in progress processes (Development, Theming, Testing, UAT). 

The Scrum Master of the project will then have to keep a regular check on these two primary metrics and share it with the development team so as to analyze the ongoing performance of the team. It is always advisable for the team to log performance on these Kanban metrics over a period of time for comparative analysis. The team will then be able to identify bottlenecks/obstacles easily and suggest performance improvement areas.

Reporting for Kanban teams

There are two common reports that Kanban teams should use: 

  • Control charts
  • Cumulative flow diagrams

Control Charts

A control chart report helps the team to keep track of the cycle time for each of the issues plus the rolling average (lead time) for the set of issues in the development process. Here’s a control chart for one of our projects:

image3_3       
 Figure 1: A control chart report helps a team keep track of the cycle time for
        each of the issues plus the rolling average (lead time) for the set of issues in
the development process 

The red line in the chart indicates the Average Cycle Time for a given set of issues in the development process over a specific period of time. The blue line shows the rolling average cycle time. The rolling average is issue-based, not time-based. For every issue shown on the chart, the rolling average (at that point in time) is calculated by taking the issue itself, X issues before the issue and X issues after the issue, and then averaging their cycle times. Twenty percent of the total issues displayed (always an odd number and a minimum of 5 issues) is used in the calculation.

For example, in the screenshot above, at the point of time where an issue (green dot) is shown, the rolling average is calculated as follows:

  • Take the issue plus 6 issues before and 6 issues after (6 issues total).

  • Average the cycle times for the 13 issues.

  • Map the blue line to the calculated average.

  • If the Timeframe is reduced to 'Past two weeks', the number of issues used would reduce, as there are fewer total issues available to use for the calculations.

Tips for the Scrum Master

  • The team's goal is to focus on reducing the time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success.
  • The closer the rolling average line is to the average line, the greater the control the team has over the process. And greater the precision in releasing tasks over a defined period of time.
  • Spot the Outliers: As the name suggests, outliers are issues that lie outside the standard range of resolution time. These are also the issues that can be easily spotted on the control chart as they are the ones that lie in the white area. The Scrum Master should notify the team of these outliers and find a way to resolve these issues as these impact the Average Rolling Time in the control chart.

Cumulative Flow Diagram

The second type of report that a team can use is the cumulative flow diagram, which shows the number of issues in each state. A team can easily spot blockages by seeing the number of issues increasing in any given state. Issues in intermediate states such as "In Progress" are not yet shipped to customers, and a blockage in these states can increase the likelihood of conflicts while delivering tasks to production. 

Here’s a sample cumulative flow diagram:

image1_4
 Figure 2: Using the Cumulative Flow Diagram, a team can easily spot
    blockages by seeing the number of issues increasing in any given state

SMs must keep a track of this flow diagram to understand the Kanban progress. This diagram can give various insights into the current state of the project. Let’s try to understand this with the help of another cumulative diagram shown below:

Cumulative flow diagram: Kanban metrics and reporting

There are five stages in the above cumulative flow diagram: In Dev, In theming, For Code Review, In QA and UAT. By looking at the graph, an SM can see that the number of issues in the UAT stage are on the rise, and sufficient UAT isn’t happening in the development process. Thus, it requires for an action item to nudge the UAT contact person to speed up the UAT process. The primary objective in a Kanban project is to keep the flow ticking by spotting and removing such blockages.

The Kanban Board has only two reports - control charts and cumulative flow diagram - as compared to the Scrum Board, but these reports give sufficient insights for an SM to keep a project on track by monitoring performance indices like Cycle Time, Lead Time and Average Cycle Time.

So there you have it, two well-defined ways to monitor and report the progress of a Kanban project. Of course, based on your particular project requirements, and the level of visibility you want, you might wish to customize these reporting formats. 

Are there any other Kanban metrics that you monitor, or methods that your team uses to measure project progress? Let me know in the comments below.

Topics: Project Management

How to follow the Kanban process for software development using JIRA

Posted by Siddharth Goswami on Dec 18, 2017 1:44:00 PM

The word 'Kanban' stands for 'signboard' or 'billboard' in Japan, which signifies some information. It was introduced by Taiichi Ohno (Industry Engineer, Toyota) to achieve “just-in-time” (JIT) manufacturing.

In the 1940s, Toyota started studying the supermarkets' self-stocking technique which they thought could be applied to their factory floor to improve manufacturing efficiency.

Pull-technique

                 Fig.1: Self-Stocking Technique of Supermarket Supply Chain


One of the essentials of any supermarket stores is to keep a track of the stocks maintained on the shelf. Ideally, the stocks on the floor should never exhaust and the product must be available for the customers to buy. 

Here’s how it was done:

  • Whenever stock on a supermarket shelf fell below a certain number, a red Kanban card was placed on the shelf.

  • This card signaled the need for new stock to be brought it from the store inventory

  • This, in turn, signaled the inventory-in-charge to get the same number of stocks from the factory

  • A Red Kanban card is added for each unit fall below the defined minimum stocks. An upper limit of cards is defined for each product type. Once there are that many cards on a shelf, it’s a signal for immediate restocking, without any delay.

 

This was the Pull Technique of stock replenishment, driven by customer demand.

The system is considered efficient if more and more shelves are well-stocked, and able to meet customer demand. This means, the goal of the Kanban process is to decrease the number of Red Kanban cards in circulation.

How to Set Up a Kanban Board in JIRA

Agile software development teams started leveraging the same JIT principles by matching the amount of "Work in progress" (WIP) work items to the team's capacity. 

Let’s understand Kanban Process in a software development project through an illustration. Let’s assume that there is a team, with two developers and one QA, who must complete 200 tasks to meet the project goals. 

To complete a task, it must traverse through the following statuses: 

  1. To-Do

  2. In Development

  3. Code Review

  4. Testing 

  5. UAT

  6. Done

The software team needs to define the ideal number of work items that they need to pick, in accordance with the team’s capacity. They need to have some kind of a signaling mechanism like a Red Kanban Card. In order to achieve that, the software development team started using Kanban Boards with WIP limits (max and min) for each of the above mentioned statuses. 

image1_1

To-Do: With the current understanding of the project and the given maturity of the team members, it is discovered that a developer will only be able to focus on 7 tasks in each release cycle. Hence, the WIP limit (Max) for the To-Do column becomes 14. 

This is added to the Kanban board (see screenshot):

image5_1                                                  Fig 2: WIP Limit(MAX) Added to the 'To-Do' Column

Also, to keep the work ticking, there must at least 3 tasks for each of the developers which bring in the factor of WIP (Min) = 6. 

Whenever the ‘To-Do’ exceeds this max limit of 14 tickets or goes below the min limit of 6, the column will turn red to notify the team to subtract or add a work item from the ‘To-Do’ column. The color ‘Red’ of the column will indicate the bottleneck in the workflow. 

Please see the screenshot below reference:

image2_3                                                     Fig 3: WIP Limit(min) Added to the 'To-Do' Column

In-Dev: Multitasking kills efficiency. When you overload the team members with more work, there are more chances of introducing errors into the system. 

So, if you are using the Kanban Board, you can make a rule that a developer will never work on more than two tasks at a moment. Therefore, the WIP (Max) for ‘In-Dev’ = 2. This will reduce the impact of context switching and will help the team to complete the tasks quicker.

Testing: Similarly, there should not be more than 3 tasks in ‘Testing’ Column for a single QA to work on at a given point in time. If there are more than 3 tasks in the ‘Testing’ column. This implies that there is some bottleneck in the flow which calls for an improvement. 

Therefore, the WIP (Max) and WIP (MIN) for the ‘Testing’ column becomes 3 and 1, respectively. 

In the same manner, the WIP limit can be defined for all the significant column. The Project Owner(PO) and Scrum Master(SM) can together study the capacity of the team and decide the WIP limit they would want to set on the planning board columns. Let’s take a look the execution board after the WIP limits for the all the statuses have been set:

image4_1
Fig 4: The complete view of the Execution Board with WIP Limits for the different columns

At any given point of time in the execution of the project whenever the WIP Limits are exceeded, the corresponding will turn red in order to notify the team of the blockage on the workflow, thus, ensuring the smooth flow of tasks on the execution board.

Please see the below screenshot for reference:

image3_2

The boards need to be monitored on a regular basis to ensure that work flows smoothly. As the project environment keeps changing over the course of time, the workflow and the WIP limit of the board are supposed to change accordingly. 

For example: A senior developer of the team exits the team and a new developer comes in to work on the project. This new team member comes with a different skill set and has limited knowledge of the project, which might lower the WIP Limit. The scrum masters are required to monitor the control chart on regular basis during this duration till a set equilibrium of WIP limit gets established.

Once the workflow (columns of the board) and the WIP limit has been decided, the project is set to roll. With this information in hand, the SMs would be enabled to monitor, control and act upon the blockages identified on the execution board. 

This is a good start for working with a Kanban board. In my next post, I will cover the Kanban metrics to monitor, and how to measure project progress.

Meanwhile, do you have any tips or suggestions on how you use the Kanban board for your team? Or any questions about starting off with Kanban? Please let me know in the comments below.

Topics: Project Management, Agile

How DevOps solves the challenges faced by siloed teams

Posted by Pavan Keshavamurthy on Dec 5, 2017 12:27:00 AM

The most critical factor that determines the quality of your product or service is how your Dev and Ops teams work together. If your Dev team is responsible just for production, and Ops team is concerned only with maintaining availability, the product is in trouble.

DevOps integrates these two teams, making them jointly responsible for delivering a product to your customers’ satisfaction. Adopting the core DevOps principles, you achieve:

  • Robust, quality software, built and maintained using the best practices
  • Faster time to market with smaller but frequent releases
  • Proactive monitoring that identifies bugs and issues before they become too well-baked into the product

 

Besides these key business benefits, DevOps principles also solve certain common challenges that siloed teams face:

Challenge 1: Whose fault is it?

With siloed Dev and Ops teams, every time something breaks, the first question is “Whose fault is it?” With skill-based teams like this, people tend to believe their skills are above reproach, and hence the problem must be with the other team. 

Solution: Culture

With DevOps, teams adopt a culture that’s open, trusting, and collaborative. This is best achieved by switching to project-based teams working towards a single goal.

Project-based teams make sure that the entire team, whether they are developing the product or maintaining it, are communicating with each other. The Ops people know how the Devs are working, their issues, and timelines. The devs understand the kind of challenges that Ops face, making for easier release management. And when something breaks, the team’s first priority is fixing the project, not pointing fingers.


Challenge 2: The Genius Bottleneck

All teams have that one person who takes the initiative to fix a problem whenever they see one. Maybe someone on your dev team is tired of asking the Ops team for new environments. They write scripts to quickly set up the virtual environments that they want. 

It’s an efficient solution but not a scalable one. Because only the one who wrote the scripts can troubleshoot them, and the team is stuck when that person is not around.

Solution: Automation

With DevOps, automation becomes a key characteristic of how a team works. The entire team adopts toolchains that ensure standardized automation for repetitive tasks. And each team member is capable of understanding and troubleshooting these automated processes.

Two of most common automations adopted are:

Continuous Delivery: Every piece of code is run through a series of automated tests, and error-free code is packaged and deployed. That is why teams adopting DevOps have smaller releases, where it’s easier to identify and fix bugs.

Infrastructure as code: Provisioning becomes as simple as a modular code that can be run multiple times to set up identical instances. Any change in configuration, or even reprovisioning an instance becomes a quick and reliable process, making life easier for the Ops team.


Challenge 3: Unplanned Work and Dealing with Failures

For any product or service, your systems are bound to break down at some point. That means a lot of firefighting and unplanned work for both the Dev and Ops teams. And while they are busy dealing with such immediate problems, there’s no time to think about developing strategies and practices that help anticipate and prepare for system failures.

Solution: Lean and Agile

While your development team already follows the agile and lean way of working, DevOps extends those practices to your Ops team as well. 

For the Ops team, being lean would mean learning to accept system failures as inevitable and prepare for it. Every emergency is not just a mad scramble to get things fixed, but also a close a collaboration between the Dev and the Ops team to improve the system to prevent a repeat occurrence.

Additionally, with project-based teams, the Ops team is now also a part of the regular stand-ups and retros by the dev team. So they are always in the loop about the kind of work they can expect and plan accordingly.

If you aim to build great products and services, DevOps is non-negotiable. Srijan's DevOps consulting teams can help your teams assess current practices and identify the correct DevOps adoption roadmap. Let's start the conversation about how we can power your competitive advantage with DevOps.

Topics: Project Management, CI/CD & DevOps

Distributed Agile best practices: An expert round-up

Posted by Nilanjana on Oct 19, 2016 12:57:00 PM

Distributed Agile teams are the future of high performing global enterprises. They are lean, efficient, and get you the best people on the job, And all this while being extremely cost-effective. So that answers the question why enterprises need distributed scrum teams

But it's not an easy thing to get started with. The challenges range from timezone differences to collaboration issues. And so we decided to ask the experts, "What would you do?" And that led to this great round up post on distributed agile best practices. Here we have seven agile coaches, including Jeff Sutherland, the co-creator of Scrum, sharing their expertise on resolving the key challenges faced by distributed scrum teams: communication and team building.  

If your enterprise is contemplating working with offshore delivery teams, or if you already work with such a team; here are the distributed agile best practices that will make it a pleasant and productive experience for everyone involved.

Ready? Let's go!

Jeff Sutherland

CEO, ScrumInc.

Jeff is the inventor and co-creator of Scrum. He launched the first Scrum team in 1993 and has shepherded its growth into almost every industry: finance, healthcare, higher education and telecom.

"For over 20 years we have scaled Scrum using a Scrum of Scrums as the release team. So any delivery problems in any team are resolved at the Scrum of Scrums level. Scrum is fractal in nature so if there are many Scrum of Scrums they role up into a Scrum of Scrum of Scrums. Saab Defense has four levels to run the Saab Grippen fighter aircraft factory with the top Scrum of Scrums being the senior management team that meets every day an 8:30. We also developed other proven methods 20 years ago for virtual teams which are implement at Spotify and ING Bank as chapters. I regularly coach both of these companies. For really high performing teams we allow backlog to move across teams during a sprint to automatically level loading but that is beyond the scope of this short comment. In Scrum@Scale we also reduce dependencies and carefully manage any that remain across teams. We eliminate all bottlenecks (there are no release teams, test teams, hardening sprints, operations teams, or other waste that cripples the system) and go to a pure Scrum release every sprint or better yet, every day. For teams that can't do this, their top priority process improvement is to implement it."

Bryan Jacobson

Bryan Jacobson

Scrum Master, Dealertrack Technologies

Accomplished leader with a track record delivering outstanding products. Strong communicator who connects stakeholders to developers and collaborates across all parts of the organization.

 

"First of all, we should be honest with ourselves and admit that a “distributed” agile team will never be as effective as a co-located team.

In fact, people see improvement seating team members within view and within a few steps of each other, versus in different rooms or on different floors of the same building. When you’re in the same place questions get answered within seconds, instead of minutes or hours. You overhear conversations you need to hear. Multiple team member can consult with each other quickly. You can tell if it is a good or bad time to interrupt another team member.

However, for many reasons, sometimes you have a distributed team or remote team members. What to do?

1. Travel

It makes a vast improvement to spend at least a day or two face to face, at least once, and ideally two or more times a year.  Communication improves. Team work improves. “Us vs them” is reduced.
If you can’t do regular travel, doing it at least once also makes a significant improvement.
I realize that some teams, due to budget constraints, cannot get travel approved. As Agile experts we should advocate that we don’t make a one sided analysis that assumes “travel costs money” and “not traveling is fine”. We should find ways to quantify the impact of missed communication, teamwork difficulties, misunderstanding, rework to correct problems, missed customer deliveries due to time spend correcting problems, etc.

(Obvious, and everyone does this): If time zones differ, make good use of the times when both teams are in the office. In extreme cases some team member may need to come in early or late.

Top recommendation: If you have a team that is largely co-located, but has one or a few remote team members, the remote team members will be at a disadvantage.

2. Remind everyone to over-communicate

  • Make it the responsibility of the remote team members to make sure the communication happens. They should:

  • Call on the phone (over email) as much as possible. Video call is even better.

  • It is the remote person’s responsibility to ask for information.

  • It is the remote person’s responsibility to ask to be included.

  • It is the remote person’s responsibility to pick up the phone when they are not sure.

  • Categorize email as “non-communication”. A growing percentage of people are simply not reading their email.

 

Top recommendation: Video calls are very beneficial. Seeing the other person makes the other person seem more human. You engage better. They engage better. It forces the remote person to be engaged and participate (not sit there partly listening, but partly reading their email or whatever).

3. Use a Chat based team collaborations systems like HipChat or Slack

  • Require everyone to monitor it.

  • Require everyone to use it for questions.

  • Use team rooms for most conversations.  That way everyone sees the conversation, knows what the problem is, what the solution is, etc.

  • Have special channels for critical communication if the main team room gets “too chatty” and people miss important notices.

 

Benefits: Everyone sees critical conversations. Less interruptive than the phone. If someone is out on the break or in a meeting, they see messages when they get back. Faster than email, harder to ignore than email.  There is a record of conversations that can be checked later.

Top recommendation: Have an online system of information record, such as a wiki or issue tracking system. That way everyone has the same view of information. 
Use the rule: If it’s not in the wiki, it didn’t get decided. A conversation that some people heard, and others didn’t, doesn’t qualify as a team decision"

Daniel Mezick

Agile Coach & Author

Coaching executives and teams since 2006, Daniel Mezick is an expert on extending adaptive Agile culture beyond software. A published author, his books The Culture Game (2012) and Open Space Agility Handbook (2014) talk about his Agile philosophies and help teams and enterprises work better.


"In general, distributed-Agile teams that want to be successful are subject to the very same Agile principles as co-located teams. This means (for example) that "working software is the primary measure of progress," and that "business people and developers must work together daily throughout the project," and that "the most efficient and effective method of conveying information...is face to face conversation."

Distributed-Agile teams that keep Agile Manifesto principles in mind are the teams that will win big with Agile. The actual methods or practices are far less important than the principles that power them. So for example, a team may use one of several methods to practice the following principle: "business people and developers must work together daily throughout the project." As long as the practice aligns with (and does not directly violate) Agile Manifesto principles, the team- distributed or otherwise- is going to be OK. And do great work. And deliver working software-- ourprimary measure of progress."

Suzanne Prince

Director, Product Management, ThoughtWorks

Suzie Prince works with ThoughtWorks Studios as Director of Product Management. She has ten years experience designing, building, and delivering software for large and small organisations in a variety of domains.

 

"Distributed teams require specific and purposeful management that is different than co-located teams. Clear, articulate and specific communication is deeply important. I highly recommend peer-to-peer collaboration between teams or individuals who are not located in the same place. Removing silos and exchanging information frequently is paramount to success. At the same time I recommend having full stack teams and minimizing dependencies between teams. When dependencies do occur creating clear contracts and hand offs is important. Tools that support visual representations of work in and between teams as well as tools that support synchronous and asynchronous communication are essential.

Avienaash Shiralige

Agile Coach, Srijan Technologies

Avienaash Shiralige is an agile coach and trainer, and has been working in close conjunction with Srijan. For him, agile is a way of life, and he helps business and teams understand and implement agile methodologies into the way they function. He also shares his expertise and experiences on his blog titled “Agile Buddha

"Information sharing and communication are well known challenges when you offshore. A great aspect of Agile is the open synchronization of the team on a daily basis. But, how is the remote development team synchronized with the local team or with customer?

Here are a few distributed agile best practices that you can incorporate into your work culture:


1. Streamline offshore team communication and development infrastructure

The off shore team must be able to seamlessly communicate with the onshore team. You could use emails to video conferencing and anything in between. Go for a trial before you start on a project. If you experience any technical issues during trial, demand an upgrade and/or additional systems. Fix them before you dive into project

2. Meet face-to-face to build trust
If the offshore team is small, bring the entire team onshore for some up-front project activities such as establishing the shared project vision, requirements elicitation, initial planning and execution of initial 2-3 sprints. If the team is big and budget is limited, then have key members of the team onsite. Additionally, plan travel of onsite teams to offshore location and spending few sprints together.
Travelling onsite is a big investment, so make sure it brings tangible returns.Define collocation goals and closely track it. Teams should spend outside office time together to build informal relations.

3. Reduce work disruptions due to each other
Establishing continuous integration approach with good test coverage is a must. Good CI will ensure teams getting successful green build when they start their day. This will reduce work loss or productivity loss due to one team committing bad code and next team unable to use that code base. You could also have a common email list between teams, where you post your issues.This will get you support from other team members not just in common office hours, but also during outside of office hours too.

4. Shared project Vision
When you are starting a project and all along the project keep offshore team completely involved in all the activities. Share customer feedback, involve them in release planning, doing all scrum ceremonies together. The Product Owner (PO) has to make an extra effort in communicating product vision, road-map, his conversations with product users etc to offshore team. Product Owner spending a sprint or two together with offshore team, makes the team feel important and in the process lot of domain knowledge gets transferred.

5. Synchronize your working hours to get at least 1-2 hour overlap
Plan at least an hour of overlap between local and remote teams. Use this one hour for synchronization and information flow between teams. Plan your joint team activities like pair programming, reviews, joint meetings, distributed stand-up etc during this overlap. Even in extreme situations like 12 hour delta between teams, local and remote team can alternatively extend their day to get sufficient overlap.

Some Agile purists say that Agile is contradictory to multi-shore development because of its inherent reliance on face-to-face communication. I consider agile thinking(short sprints, working software, focus on people and collaboration and more) is a natural solution for above offshore challenges. Yes it requires new way of thinking and doing.

You can also watch our webinar by Avienaash and discover why distributed agile teams are necessary for global enterprises.

Ken Collier

Director of Data Science & Engineering, ThoughtWorks

Dr. Collier leads a team of brilliant data scientists, data engineers, and data analysts. The focus of this practice is on advanced “big data” analytics solutions that combine adaptive data pipelines, modern data engineering, rigorous data science, and data savvy business analysis to create maximum value from data.

"Cross-team communications in distributed/remote agile teams is a function of three key factors - distance (timezone difference), language difference, and cultural gaps. Each of these decreases the effectiveness of cross-team communication/coordination, but distance is perhaps the most significant.

  • Timezone: When a team is separated by 6 timezone hours or more, asynchronous communication becomes the norm. At ThoughtWorks we seek to shrink this separation by using near-shore distribution whenever possible (e.g., US/Brazil, India/Australia, etc.)

  • Language: Language barriers are the next most significant factor. The distributed team as well as the customers must have at least one shared language in which everyone is fluent.

  • Agile Terminology: The "agile language" must be common for everyone. Does everyone have a shared understanding of what "pairing" means, the rigors of test-driven development, and the definition of "done"?

  • Culture: Cultural differences, both regional and corporate, are impactful. The team should establish a shared set of cultural norms and expectations. For example, is there a cultural of hierarchical subordination (i.e., "pecking order") held by the remote team that differs from that of the host team? At ThoughtWorks we routinely rotate distributed team members from the remote location (where the delivery team is) to the host location (where the customers and stakeholders are) for a few iterations at a time. In this way everyone on the distributed team gets some face-to-face collaboration with customers, stakeholders, and other team members thereby building a shared culture of trust, familiarity, and clarity about the project."

Ben Linders

Agile Consultant & Author

Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of "Getting Value out of Agile Retrospectives", "Waardevolle Agile Retrospectives", and "What Drives Quality and Continuous Improvement".

"If you are a new distributed Scrum team getting ready to become productive, a sail boat futurespective helps you to get to know each other and agree upon the way of working for your team. You start by stating your goal and imagine how your team should look to reach it, next you'll explore what you can do to get there. Alternatively you can play a core qualities game to learn about each team member's strengths and find ways to collaborate effectively. You can build a new team using these retrospective exercises.They can easily be done with distributed teams, all you need is an audio/video connection between the team members and an online drawing tool in the retrospective."

Jeff Sutherland

CEO, ScrumInc.

Jeff is the inventor and co-creator of Scrum. He launched the first Scrum team in 1993 and has shepherded its growth into almost every industry: finance, healthcare, higher education and telecom.

 

"Scrum Inc is totally run by Scrum - marketing, sales, finance, consulting, training, software development, everything we do. Everyone is on a single Scrum team. I am on a distributed team and it is essential for us to fly everyone into to a two day quarterly meeting face to face where we do quarterly planning, retrospectives, and build team agreements. We do one week sprints and meet on Google hangout for all other Scrum meetings. We are heavily into Legos these days and my Scrum Master ran the quarterly retrospective this week by having team members build lego structures representing the best and worst experiences they had. It was deeply insightful."

So that was seven Agile experts sharing their take on distributed agile best practices. You could also take a closer look at all the different challenges that can arise in a distributed scrum model, and how to resolve them. We hope you found this post useful, and will now be able to take an informed decision on starting to work with distributed agile teams. 

If you are looking to plug a distributed team into your enterprise, Srijan scrum teams could be just the thing you need. And in case your enterprise is just transitioning to agile, we have curated 6 of the best blog posts by agile coaches, to guide you through a smooth transition.

Topics: Project Management, Agile

Discussion

Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us