Management Expectations in the Agile World
3 November 2015
Even though there has been phenomenal growth in being Agile recently, the adoption of the Agile culture from top to bottom is not seen in the majority of organizations. This has been a key contributing factor for the failure of Agile adoption. Part of this is management's control of teams even though companies say they are Agile.
We all agree that management should allow the ScrumMaster or the teams to be outspoken and build trust among teams. Agile principle No. 5 says, "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." How many organizations follow this principle?
A significant number of teams build projects using the traditional approach. They are driven by authority for completion of the project, whereby management concentrates on resource management and switches resources between projects and tasks.
Though the sixth principle of Agile says, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation," in reality, we notice management supporting and maintaining more privacy, thinking it can strive for perfection and disband the gridlocks. But in actuality, it's creating more fear and exercising more control, not building trust.
While feedback is essential, it's important that we follow a transparent method for providing correct inputs. Instead, individuals are being appraised by few antipattern metrics, which certainly breeds low morale among team members. I am sure that no developer acts autonomously and feels that he or she is being micromanaged.
Most managers are preoccupied with collecting metrics and make decisions around these metrics. Agile Principle no. 7 says, "Working software is the primary measure of progress," which is not considered at all. Rather, management is getting to various metrics that quickly derail the Agile transformation and negatively affect the organization.
This article discusses some of the metrics that I have come across recently that are anti-Agile patterns. I would like to highlight them and elicit your comments and suggestions.
Story point estimation
Antipattern: Disproportionate ratio of number of hours worked to the number of persons available during the sprint.
Breaking the pattern: Coach management and explain why story points are important for estimation in relation to hours worked.
Defects resolved by individuals
Antipattern: Using traditional methods for evaluating the performances of a developer and a tester in relation to quality.
Breaking the pattern: Monitor defects to ensure that teams verify fixes daily and that you deliver the right product. As one of the Extreme Programming practices says, "By working as a whole team, reporting defects within the team can be gradually nullified." However, the team's maturity does matter; the ScrumMaster and the engineering manager play vital roles in supporting the required changes.
Antipattern: In calculating the cost of a reopened bug, the cost is associated with the individual rather than the team.
Breaking the pattern: The entire team must focus on quality and truly believe in "We overIoryou."
Antipattern: Comparing the velocity of one team against other teams.
Breaking the pattern: Coach the business analyst involved to compare the team to itself rather than to other teams.
Use Agile metrics, such as acceleration, lead time, and release burn-down or burn-up, in a precise way. Instead, if management introduces (for his or her own benefit) the data for assessment and digs at an individual level, I am sure it wouldn't be a surprise if the engineering team were to skew the numbers for work logged.
Although it's important to check team capability and quality of coding, if the engineering manager adds value by asking questions and vetting assumptions during the planning phase instead of defining time lines, our principle "The best architectures, requirements, and designs emerge from self-organizing teams" would certainly be healthier.
We believe in the Agile principle that "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." But if management evades the Agile principles, engineering teams will become uninterested.
Team velocity is and should be a measure of unit that directs the team motion. If the velocity has been compared across teams instead of raising the bar of one team, I am sure that the last principle in our Agile Manifesto, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" will take a back seat.
New Agile metrics should be introduced where required. However, because we believe that transparency is the leg of the empirical process, it would behoove us to discuss these metrics with the teams before implementing them.
I am writing this article from my experience in real time. Please share your views on various metrics that your organizations are using that are not antipatterns but do support Agile adoption.
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.
Current rating: 4.5 (28 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.