Most guidance on Agile is directed at team members in such roles as Product Owner, Team Member (including developer, QA engineer, and UI/UX designer), and Scrum Master. This leaves some with the impression that there is no place in Agile for traditional organizational leadership roles with manager or director titles.
On the contrary, people in manager, director, and VP roles are essential to the success of an Agile organization. To be effective, they need to practice discipline, discernment, and discretion
Discipline – through Lean/Agile Governance principles and practices
IT Governance happens, intentionally or otherwise. Agile leaders should be deliberate in creating the right degree of formal governance for their organization that will allow teams to thrive. A recent survey by Scott Ambler and Associates found that Agile Governance has a significant effect on creating conditions that allows Agile teams to thrive.
Discernment – by participating in as many team meetings as possible
Scrum Team ceremonies are the place a leader can identify patterns and practices that are helping or hindering team success. By silently participating and observing team member interactions in such settings as Daily Standups, Sprint Planning, Backlog Grooming, and Sprint Reviews, a leader can identify opportunities to influence individuals and the team as whole. Throughout team development phases, team members will welcome the guidance of a coach and mentor whose purpose and intent is to help them achieve their potential.
Discretion – by resisting the urge to use traditional command-and-control techniques
Many of us in leadership roles have formed habits that damage team autonomy and empowerment. We’re too quick to determine and direct, when instead we could foster collaboration and healthy convergence among team members.
Engineering leaders often are in their positions as managers because they were successful as individual contributors and showed some aptitude for leadership. Not many have had training and experience that allows them to develop the skills needed to coach, build and inspire others. Effective leadership requires that you take deliberate steps to move out of the individual contributor sphere. Lyssa Adkins illustrates the sphere of influence for an Agile leader this way:
The need for effective Agile leaders has never been greater. Recently, there has been a considerable amount of attention drawn to the failings of at least one prominent Silicon Valley Unicorn in the area of culture and ethics.
The failure has been demonstrated at every level in the organization, and is especially noteworthy because of the explicit participation in toxic and demeaning behavior exhibited by some in engineering leadership roles. They assumed, and company executives reinforced the belief, that they needed to encourage and reward aggressive, individualistic patterns and practices, the very things that are anathema to effective, productive Agile teams.
Popular posts from this blog
Defects and Risks are often dealt with in a subjective, emotional way. That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue. The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization. I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization. Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
The problem of demand for IT services and project resources exceeding available supply is something every organization faces. I was asked again recently about how Agile helps with demand management. Agile addresses the problem in several ways. First, an Agile team's highest priority is to satisfy the customer through early and continuous delivery of valuable software. Unbridled demand almost always will exceed resource capacity, but increasing flow of finished work from the development organization definitely results in higher levels of satisfaction from those who produce the demand. Further, delivering working software frequently, from a couple weeks to a couple months, with a preference to the shorter timescale, means a team satisfies demand on a more regular basis and on a timeframe that corresponds to the customer's ability to absorb and implement new features and enhancements. Finally, Agile processes promote sustainable development. Sponsors, developers, and us