During my first agile transformation, we had a highly adaptive organizational framework for proposing changes.  Within Holacracy, the a non-hierarchical organizational structure, there is a governance process which allows any team member to propose a change to structure, roles, or policies within their circle. If any change passes, they could then work with their rep link (the elected representative chosen as the voice of the circle within other circles) to bring this policy to other parts of the organization.

One of the challenges we faced with our agile adoption was basic understanding of Agile, and what ideas and principles were espoused that the organization valued.  A group of agile coaches on my team got together and drafted a policy that we would put forth in a governance meeting.  The basic rule of acceptance for a policy change in governance is that if there is no substantiated objection from a circle member in the form of proof that the policy would somehow move the organization backward, then the policy would pass. This bias toward action allowed us to swiftly adopt a few new roles and policies that would ultimately accelerate our agile adoption.  I went into much more detail in my experience report at the Global Scrum Gathering, San Diego, California, in March 2017: Scrum for Hardware: The Story of A Rapid Agile Transformation. You can check out the slides on SlideShare

The Policy

Technology will use an agile approach to product development.  Agile is a set of values and principles around which an iterative and adaptive process can be built. Many agile frameworks, including Scrum, provide simple sets of roles, practices, and values.  These will guide our process improvement efforts and decision making.  By removing unnecessary unpredictability, we’re better able to cope with the necessary unpredictability of continuous discovery and learning and deliver valued products to customers.

We use Agile to maximize responsiveness to changing customer needs. Our teams work directly on delivering business value. We implement empirical process control with rapid feedback loops to incorporate inspection and adaption into our work.

We integrate lean systems thinking into our work in order to eliminate waste in our processes and continuously improve.  We integrate test-driven development (TDD) and use hypothesis to drive development with the end result in mind in order to deliver fully functioning and integrated systems.

We emphasize decision making from real-world results rather than speculation. We divide our work and our time into short work cadences, known as sprints, typically two weeks long. The product is kept in a potentially shippable (properly integrated and tested) state at all times. At the end of each sprint, stakeholders and team members meet to see a demonstrated potentially shippable product increment and plan future work.

Within our Agile framework we have three roles:

• Technical Product Owner (TPO) – drives the product direction
• Team Agile Coach (TAC) – dedicated to team health and performance
• Development Team – provides the energy and development work

We use Agile to efficiently utilize resources and maximize value for the customer. We test and validate assumptions about customer needs before heavy investment in developing products. In adopting these practices we optimize team efficiency and efficacy, maximize value for our customers, and outperform our competitors.  

This policy was the first of many designed to clarify and socialize the principles and values we wanted to adopt as an organization. We published it in our internal governance platform for Holacracy, GlassFrog, and anyone could review at any time.  I believe it had incredible value in serving as a place for people to look for information and then research on their own.

Until the Next Iteration . . .

Jason