Devops – Integrating team cultures

With time there has been a lot of evolution in the practices that are followed by various teams within a software organization that is either developing products or providing services to develop products. In contrast to a clear boundaries that used to keep different teams separated, there has been a section of people that is working on diminishing these boundaries. People often are calling this group with different names like DevTestOps, DevOps, DevTestSecOps etc. and the most popular being DevOps that should integrate all of these together in one way or other.

What is Devops?

DevOps aims to bring together people with different cultures and philosophies, who share their best practices and continuously learn from each other, to improvise on practices and tools that can help an organization to deliver at a high velocity. In the process it enables them to learn and adapt at an unprecedented faster rate as compared to when they used to work in silos.

How it works?

DevOps aims to remove silos between various teams that are responsible to deliver a product to the end user. These may consist of only development and operations team, but in many cases it does involve test and infrastructure security teams as well (that one can also refer as DevTestSecOps model). With players from all teams coming together to form a single team, this model does boast of removing the bottlenecks quickly and everyone working together to make each other successful. One of the primary objective team has is to optimize the way of working by automating the necessary and redundant practices in the product lifecycle.

Benefits of DevOps

  • Improved Collaboration – With teams working together, there are ‘Zero’ Silos between teams that helps in building a efficient and engaged team culture
  • Enhanced Quality & Reliability – Practices like CI/CD enables quick verification and monitoring with each change of the code that results in enhanced confidence.
  • Accomplished Security – With automated security and compliance integrated into the configuration management system enables security control across the lifecycle
  • Higher Velocity – A platform to build, fail/succeed and deliver fast enables to quickly learn and adapt as per the customer needs providing a competitive edge over competitors

Best Practices to achieve DevOps

Though there is no set of defined best practices to implement a successful DevOps, but organizations have consciously started examining the proprietary practices that have engulfed them since long to identify gaps and most importantly think about getting rid of obsolete methods. With time, some of the best practices that have been adopted by various organization to implement a successful DevOps model are

  • Continuous Integration
  • Continuous Delivery
  • Automated and Continuous Testing
  • Live Monitoring
  • Involved collaboration

Though all the above is true, while implementing DevOps culture, the most important philosophy that will make one stand apart is the ability to ‘Be Agile‘.

KISS Agile Standups

Almost all the IT organizations across the world are in some kind of a race to adopt Agile. Post decision and Agile is selected as the process, the first challenge that anyone faces is to broadcast who is doing what in the team. To meet this challenge,  the best defined solution is to have a daily standup scheduled.

These  Daily standups have become a trend in project teams. The team has an awesome feeling when Agile starts as it seems to be connected. Though some projects master how to organize these meetings, but many of such meetings become a status call and slowly as the projects progresses, team starts losing the steam. People start ignoring it as it becomes time eating meeting, as other ones, and people prefer to complete work rather than giving status.

To resolve this challenge, the only way to keep the momentum going on for this meeting is to “Keep It Short Stupid”.


Do not let it become just another status call!

Implementing Agile – Understand your ‘Team’ first!

After so many years working and implementing Agile practices in various organizations, I have found that Agile is still new for many. Everyone wants to adopt it, but still.. is not able to adopt it! There is one major piece that people miss and i.e. “The TEAM”. The team that will be responsible to implement it. The team that will make it either success or failure.

Before we decide on to implement Agile, we need to look at the team that we plan to implement it in. An agile team does not consist of just any random set of people. It is not a group of developers, testers, project manager who meet for 15 mins to perform daily standup rituals. It is not the team that plays poker to do product sizing and then do sprint planning. It is not a team that has individuals supporting multiple agile teams.

Let us understand what makes

The Agile Team

An agile team should consist of members with cross functional skill sets that makes the team independent to deliver without waiting on external teams to certify it’s success or failure. These members are dedicatedly allocated to one team, and as a rule, work together to deliver the common goal without moving in and out of the teams.

The team should also understand the core principles of agile very clearly and it should be ready to go beyond rigid organizational boundaries. It should understand very clearly that the software delivered at the end of the sprint should be a working software, that works not at the unit level, but also at the integration level. Above all, it should feel empowered to be Agile.

Once one understand the team and forms an independent team to deliver, then comes the next steps – Team Activities beyond Agile standards. I will cover this in my next post.

Using automation to overcome Agile testing challenges

Using automation to overcome Agile testing challenges

Organizations globally are adopting the Agile development methodology for enhanced collaboration and faster delivery. Agile is a set of software development principles that lays emphasis on individuals over processes and tools, working software over documentation, collaboration over contracts and responding to change over following the plan. Through Agile, organizations can collaborate with their customers by delivering live and working software to them. Despite its benefits, embracing Agile in the Testing practice is not an easy task and fraught with challenges.

Challenges in adopting Agile in Testing

While selecting appropriate tools that are usable as well as flexible is an issue, encouraging the entire team to contribute towards the tests is another problem. Enabling open-source integration and promoting test-driven development are some of the other concern areas in Agile testing.

Agile also brings with itself a few technical problems like difficulties on account of distributed teams and obstacles faced by individual testers within the Agile team. In the case of Agile development methodology, it often becomes tough to keep track of the number and speed of changes in user stories, requirements or the code.

Another issue with Agile is frequently changing requirements. Due to this, the code is refactored quite often.  Agile testing can be further bogged down by the fact that the testing team has to continuously collaborate with other cross-functional and geographically scattered teams.

How Test Automation can help

Test Automation can help organizations resolve the challenges associated with Agile testing.  Test Automation ensures that the application is and continues to be in a good shape with each new sprint. It encourages the Agile development team to collaborate with the testing team, seeing it as a  partner, rather than as Quality Police. Running the tests over and over again gives the development team an assurance that the new code, which was added to the system, does not break or destabilize anything.  It also certifies that the system is working and the new code is doing what it is supposed to do. As Agile teams need to test continuously, Test Automation provides the required speed, and helps ascertain that the feature implemented during a given iteration or sprint is actually deployed.

Think, before starting

Overall, Test Automation is useful in addressing and fulfilling critical testing demands and essential for Agile projects due to their need for frequent regression testing. At the same time, while Test Automation may be needed, just deploying an automation tool is not the solution for an organization.  What companies also need is a proven automation testing strategy and a skilled test team. This involves designing an effective automation solution that supports quicker maintenance, faster ramp-up time and distributed ownership.

Do look at Jim’s comments to complete reading

Webinar – Using Automation to Address Agile Testing Challenges

Agile is being adopted by most of the organisations to achieve quicker deliveries. But, looking at the usage and implementation, they are still struggling to milk the actual benefits that they can reap while being Agile.

Testing is one such area that is making testing teams lose their sleep.

One of my friend and colleague, Garima Mishra, has prepared a 40 mins webinar that aims to showcase how testing teams can  get benefited by Automation and how it can help address the challenges that are usually encountered while testing time-boxed agile projects.

The webinar is scheduled on Nov 30, 2011 at 10 am PT / 1 pm ET

Register to learn more.

Problem on the table

This idea came to my mind when I, alongwith Ajoy Singha and Vipul Kocher, were discussing on the agenda of first NCR Testers Monthly Meet (NCRTMM) that we started in December 2010.The main motivation behind developing this idea was to provide an informal space during NCRTMM where testers can discuss the problems that they face and get the resolution from other testers present in the room.

We have already implemented this in the two NCRTMM and attendees have found it beneficial. The testers  have utilized this space to resolve the problems that they face in their live projects.

This post of mine will provide the complete details about “Problem on the table”.

What is “Problem on the table”
“Problem on the table” defines a space that allows group of testers to interact in a simple and organized way to enable valuable dialogs that addresses the day to day issues that they get stuck with and want some expert help to get them resolved. This space encourages people to discuss and resolve the issues and be more productive within their organizations.

Fundamental Rules

  • No one will control your discussions
  • Whoever wants to provide help is the right person
  • Allow owner of the problem to steer his or her topic in the right direction
  • Always thank individuals whose suggestions have actually helped you

How “Problem on the table” works?

  • Come up with some interesting problem area that you would like to discuss during any NCR Testers meet to ITB NCR Chapter with as much detail as possible.
  • After receiving an email from your side, there will be a space allocated during the meet to discuss about your “Problem”.
  • Anyone attending the meet is free to walk to the designated area for your listed “problem” and provide their frank suggestions.
  • It is upto the owner how they would like to steer the discussion.
  • At the end of the session, the owner of the “problem” needs to present their “problem area” alongwith the best solution, that fits in their context using a defined template.

Benefits of owning “Problem on the table” session?

  • You manage and define your own agenda
  • As most of the test experts from the industry are joining the NCR Testers Meet, there is a high probability that you will be able to find the answer to trivial issues that remain unanswered elsewhere.

Developer and Tester – Can we make them work together?

In the past we were always taught that developers and testers often are the two opposite poles of a product team; they are two different entities that should only collaborate in the form of bug reports and the tester should verify each functionality based on the requirements that are documented.

Today, when I relook at that separation, it sounds dangerous. But it has been the case in many organizations even lately. As it has been sometime since we started working on a platform that will help bridge this gap between developer and tester, I thought of sharing the idea in a webinar and how developer and tester can work more closely without any communication overhead. The webinar is scheduled on 17th Sep, 2010 at 10:00 AM PST. This webinar should give a fair idea on how you can develop your own solution that can bring both the teams together and make them work to achieve organization goals.

Register for this webinar at

Tweet to report defects!

Twitter and Facebook have changed the way we used to communicate in the past. Instead of email, people are finding them as a better communication medium. These 2 are often the mediums to get the instant first hand information on almost anything.

There have been times and even today we use various tools, OSS or Paid, to report and manage defects so as to keep a record for any product development team. Let us revisit what these systems provide and how are they used by various teams.

Defect Cycle configured in any Defect Management Team (generally followed by most of the teams in various companies)

  1. Open a new defect
  2. Provide Summary
  3. Write complete description on how to reproduce that defect
  4. Assign proper severity/priority and other details like build number, browser etc.
  5. Save the defect
  6. The Test Lead evaluates the defect and, if valid, assigns it to the dev lead
  7. The dev lead assigns it to the dev engineer
  8. The dev engineer fixes the defect and routes it back to the test lead
  9. The test engineer verifies the defect and if found fixed closes the same
  10. If not fixed, the defect is reopened and routed back to the dev engineer

In the whole process there are various checks where automatic emails are sent to the stakeholders (mostly configured for steps 5 to 10 above) to notify about the incoming defects or change of state, if any. There are various processes also defined that make it mandatory for any lead to review all the logged defects at the end of day or participate in defect triaging meetings scheduled regularly. Overall these tools and processes are good to keep focus on defect reporting and fixing, but here are the limitations/disadvantages that they bring in.

Limitations of current Defect Management Systems

  1. Communication lag: There is an overall communication lag between testing and development teams. Both the teams often communicate by putting comments for any particular defect which wastes a lot of time in turn and sometimes they don’t understand each other’s point.
  2. Defect language issues: Many a times it is raised that the testing team is not drafting the defects correctly. Or the summary of the defect does not communicate exactly what is mentioned in the description.
  3. More meetings as project progresses: Frequent defect triage meetings are needed to keep a tap on incoming vs closed defects. Also, in such meetings the lead is mostly explaining the defects and might not be able to do complete justice to the defect.
  4. Time lag: It has also been seen that whenever any tester finds a new defect, the tester first notes that down in his/her local file and at the end of the day logs all of them into the defect management system with all the details. Due to this sometimes critical defects that needs immediate attention by other stakeholders lose time to take action.

If we look at twitter and how it has changed the communication, I feel that if we integrate twitter in our day to day defect reporting mechanism, the whole process can be made better.

How Twitter can help

  1. Whenever a defect is found, the tester tweets about it. The developer and tester can discuss it immediately and both of them can agree/disagree on the same.
  2. Twitters 140 chars limit will force tester/developer to be more crisp in doing the communication about the defect. It will also help them in improving their communication skills.
  3. Unnecessary mail communication can be minimized as everything can be discussed live.
  4. As the defects will be discussed immediately, so it will remove the need of having (sometimes) unnecessary triage meetings.
  5. The whole product team/sub teams will be together on twitter so they will be able to immediately know which area of product is getting more defects.
  6. The management can also have a feeling of how the two teams are performing and can have a complete access to each individual in the team, at the time of need.

As the world is moving towards Agile based development and it is definitely bringing development and testing teams more closer, twitter can play a very important role in building harmony between both the teams. Though it might not be as easy to implement as it is said above due to various issues like

  1. This will require teams to be online everytime, and teams might complain of wasting their times due to this.
  2. Managers who are driven by metrics might feel this a bit unrealistic as they will not be able to measure based on tweets.
  3. To keep track of the defects, the defect needs to be logged into the defect management system that will definitely require some extra time.

Defect reporting is only one form where Twitter can help. It can also be helpful during test case creation, evaluation, testing etc. Let us see how things converge to build a better platform for futuristic teams. Feel free to post your comments/thoughts on the same.

Is Agile making teams ‘Fragile’?

Before you go through this post of mine, let me clear out that I am not against Agile. I am actually not against any methodology used during SDLC unless and until it is being misused. As per my previous post and the comments that I recieved, I will be touch-basing on the fact that the companies are not implementing Agile in the manner it was designed and how it is making teams ‘Fragile’.

We are seeing the following messages appearing in various magazines/posts – “Agile makes teams 50% more productive” or “Agile teams are 37 percent faster to market” etc. Anyone that we talk to or meet in the business boasts of using Agile methodologies and increasing team efficiency. But have we thought on the aspect of how are we measuring this? Even if we are able to measure it somehow then at what cost are we getting this?

Let’s revisit Agile Manisfesto once more. It says

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Now let me raise few questions

  • How many of us believe individuals when the things go wrong without document proofs?
  • How many of us do not want a comprehensive project report document?
  • How many times the individual gave an incorrect estimate and had to work overtime to meet the deadline?
  • How much time are we giving individuals to research and estimate?
  • Can a software survive a long term cycle if there is no comprehensive document created for that?
  • How many times have your clients pressurized you to get make a functionality into a release due to which team needed to work overtime?
  • How many times the testing team did not get a build till last minute as Agile is used?

If we go in detail to each of these questions, I am sure you will start getting insight into why the teams often lose sight when such kind of issues are again and again faced in long term projects said to be using Agile methodology. To safeguard oneself, apart from the pressure of deliveries the individuals need to do more documentation so that they can present that at the time of need. What I have found is that in long term, people are not able to meet such a demanding nature of agile projects and lose faith in Agile methodology and often switch projects/organizations. Which is a serious concern for the organizations and community as a whole who want to use Agile to increase productivity..

Is it time to rethink on Agile implementation strategy?

Use Agile to increase Productivity. Really!

This post of  mine is inspired from sdhanasekar’s blog entry How to measure productivity. He discussed a typical scenario about how a team member did an estimation and failed to meet that.

The scenario that he discussed is really a common thing that is happening in current project teams. As more and more organizations are pretending to be Agile, they are increasing the indirect or direct pressure on the individuals to commit on something that they might not be confident on completing. And once the commitment is made, the whole pressure is to deliver that irrespective of the fact that it can be completed as per estimation or not.

If we revisit Agile Manifesto, it says

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

People are implementing Agile, based on their understanding and the main intention behind it is to meet quicker goto market plans. So does it mean that the team that is working in Agile mode should be more productive? Is it just to keep them under pressure always so that they forget everything else; even no time to collaborate with team members!

But as the teams are being made to achieve unrealistic targets that they set for themselves without doing proper analysis is an area of concern that should be addressed sooner than later in the software industry. Is it really to make teams more productive?