Get certified - Transform your world of work today

Close

Management Expectations in the Agile World

3 November 2015

Bhargav Ram Vedula
Dell International Services


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.
 

Reopened defects

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."
 

Velocity

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.



Article Rating

Current rating: 4.5 (28 ratings)

Comments

Madhavi Ledalla, CSP,CSM,CSPO,REP, 11/3/2015 9:46:43 AM
Nice read on anti-patterns of Metrics, well written Bhargav!
Sonal Bajpai, CSP,CSM,CSPO, 11/4/2015 12:11:10 AM
Great Article Ram!!!! Having moved to Agile its more of a mind shift rather than a process being pushed on people this is something that organisation, Team everybody have to understand. With all the hierarchy existing in the systems to fit the Role of Scrum Master and giving all rights to him/her of bringing up the change has become a real challenge in the companies. The biggest anti pattern to me is the old pattern setup of delivery. Just by following Scrum practices we are not Agile and rarely do people understand that. Great Article !!!
Sivakanth Badigenchala, CSM, 11/4/2015 12:16:44 AM
Nice article Bhargav. From my experience, i still see the defect count as the measure of performance of an indivdual and teams with zero defects are looked at skeptically.
Vijay Bandaru, CTC,CSP,CSM,CSPO, 11/4/2015 4:23:52 AM
Good one Bhargav, these are some of the culprits for the Agile to fail and strong coaching needed for management in terms of changing their mindset to give importance to value than # of defects, or effort spent etc. They really need to understand the agile values and principles in order to change their thought process
Anonymous, 11/4/2015 8:45:32 PM
Great article Ram. You have well analyzed and given a good thought process. There is definitely a change required in organization.
Uma Mahesh Rao, CSP,CSM,CSPO, 11/6/2015 12:34:20 AM
Great articulation Bhargav.
A problem clearly stated is a problem half solved !!
Nidhi Kohli, CSM, 11/10/2015 5:09:50 AM
Thought provoking article.
While we cannot over-look the reasons which drive management to ask for metrics, I think the problem lies in the shortsighted outcome feared based on metrics analysis. Also, individuals are easy to target rather than dig through the root cause which again results in command and control. Agile is finally about how teams and the stakeholders act and react in different conditions. One of the ways by which self-organizing teams can be allowed to nurture and move forward on becoming Agile is to give them space to show results even though their initial output may not be encouraging.
As Lyssa Adkins says that a truly charged Agile team will say "bring it on" provided they feel secured on "becoming" Agile.
Purnima Julka, CSM, 11/17/2015 2:53:54 AM
Ram, its indeed a very nice presentation of real life situation. However, under Reopened Bugs section, the bug fixing generally gets assigned to an SME considering the priority and urgency. And yes the onus should still remain with the team and not that individual:) And wonder how about the credit of fixing it timely!
Suresh Konduru, CSP,CSM,CSPO, 12/8/2015 5:06:29 AM
Very nicely written Bhargav. In fact, one of my most recent Agile coaching assignments faced the Velocity anti-pattern you mentioned here. A senior leader in the organization expressed that some teams are delivering higher velocity while some teams are not, and requested for measures on how the Velocity can be streamlined across the whole line of business. This kind of management thinking is sure an impediment for a true transformation.
Anonymous, 10/25/2016 6:07:14 AM
Very well explained Bhargav. Definetely a thought provoker for all who claim they are Agile.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe