We Lost to Agile: Part II

3 February 2014

Rohit Ratan Mani
Diebold Systems Pvt. Ltd.

"You are as fast as the slowest member of the team."

The proverb sums up a concern while implementing Agile in an organization.

Whenever a new idea is presented in front of a group, everybody looks with skepticism to the presenter and fears the unseen impact of the change. And this is what my friend is facing while trying to run an Agile implementation project. In my earlier article "We Lost to Agile," I summed up my discussion of the impact of implementing Agile in an organization for a few of the roles. Picking up the thread where I left off, I will summarize my views on how different departments are impacted by an Agile implementation within an organization, for these roles:
  • Senior management (already discussed)
  • Product management (already discussed)
  • Sales team
  • Developers
  • Testers
  • Development and testing managers
  • Project managers
  • Quality/process/audit team
  • Accounting team
Sales team
This layer brings in the real feedback from the users. This is the team that faces the heat from customers, and Agile brings the sales team closer to what is being developed. The current process lets the sales team understand and familiarize themselves with the application features, but Agile brings in details on which the sales team has to become familiar in less time than they have now. Getting a demo as part of Agile development is one way the sales team can always be updated as to what is being prepared for the customers.

The impact of moving to Agile would be:
  • Reduction in churn-out time for new features
  • More involvement in the development cycle
  • Low learning time for new features
  • Frequent updates to sales (showcasing latest releases)
The selling point is that the quicker release cycles of new features are going to increase the sales for the team. The downside is getting more involved with SDLC and understanding new features.

This layer might presume that they are going to be the team most impacted by this change. Actually, this is every team's feeling. This layer needs to get accustomed to more discussions, changing requirements, working alongside the testing team (a rare sight), and stand-up on the commitments. A feeling of working independently without red tape can bring out better performance. For an individual performer, this layer needs to become a team player. The process overhead of creating lengthy documents and waiting for approval is going to be reduced. There will be more automated unit testing to be done, which means the method of coding will need to change.

The impact of moving to Agile would be:
  • More responsibility on individual tasks
  • Less documentation
  • Upgrading to a different coding method
  • Becoming a team player
  • Involvement in more discussions
The selling point could be an environment that makes the work of a developer reach customers quickly. Though requirements evolve as development progresses, direct coordination and discussions with the product manager bring the developer close to the deliverables. A developer can learn new and better approaches. There is no sword (invisible or otherwise) that is hanging over the developer's head to meet a deadline set by some superiors.

As frequent releases are made, at times it may be that there are multiple versions of the application in use by the customers. This would mean there would be reports about issues and new features coming from multiple versions. This would make configuration management a challenge.

This layer is critical for a successful product release. One of the key reasons for not getting a tester to work with the developer is management's idea of evaluating a tester's work. In many organizations, the performance of a tester is measured in terms of the number of bugs that are raised within a project. The more the bugs, the better the appraisal. Well, in Agile we need to make the testing team work with the development team to nullify any bugs that might come up within the SDLC.

Also, testing would move from manual to automated as much as possible. This would bring about a change in the thought process of the group. This layer can also play a critical role in bridging the gap between the technical (development team) and the functional (product manager) for the project.

The impact of moving to Agile would be:
  • More collaboration with the development team
  • A move to automated testing
  • Less documentation
  • Becoming a team player
  • Involvement in more discussions
The selling point could be the task of moving away from monotonous manual testing to more automated testing. The idea of moving out a working product to the customer can be a good motivation for working along with the development team. There might be concerns about retesting a feature as it evolves; however, as we target to move to automation, this concern can be taken care of.

As there might be multiple versions of the application in the field, maintaining multiple versions of an automated test is going to be a challenge for the configuration manager.

Following an Agile delivery, I will continue to document my discussion of other stakeholders in another article. Meanwhile, I share this article for your comments. We might have missed out on points that we should consider. I look forward to comments to get those points added to the list. Happy reading!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.7 (3 ratings)


Be the first to add a comment...

You must Login or Signup to comment.