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
As a project manager who does not have a programming background, I find it essential to understand as much as possible about the way developers craft solutions to business problems in their code design and implementation. The best developers I know follow a set of design principles and patterns that ensure strong, flexible, extensible, modular code. Writing on this subject at his website http://www.objectmentor.com/ , Robert C. Martin identifies a set of design principles and design patterns that all software development project managers should understand (see http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf ) Here they are in summary: Principles of Object Oriented Class Design The Open Closed Principle (OCP) - A module should be open for extension but closed for modification. The correct use of this principle and its related techniques allow developers to add new features to existing code without changing the existing code and by only adding new code. It