Elements of transformation
Preface:
There are many agile frameworks available in the market to improve agility. But there are essential elements required as part of organization's readiness to embrace any agile framework. Organizations may establish those essential elements through the implementation of the agile framework or focus on them ahead of implementing the framework. If organization is already walking the journey of agility, applying these essential elements will be helpful to amplify the outcomes.
Essential elements of the organization readiness includes, organizing around,
1. the Product (Backlog),
2. the Cadence (Time) & events.
3. the Team (People),
4. the Technology (Quality)
In this article we will discuss the first element, Organize around the Product (backlog)
What is a Product?
Definition of product may vary depending upon the domain and context. Let's begin with,
Mike Cohn's definition; A product is something (physical or not) created through a process that provides benefits to a market.
The Scrum Framework: Product is a vehicle to deliver value and has established stakeholders, user and team identified.
What is a Product Backlog?
Product Backlog: Agile Alliance defines Backlog (Product Backlog) as the single authoritative source for things that a team works on.
The Scrum Framework defines the product backlog as emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the scrum team.
Thus; Backlog is a single source to visualize the total amount work to be done to create or enhance the product that benefits the market. We will discuss importance of creating the single source to manage the Product Backlog.
Organization Setup
In the matrix and super-matrix organizations, each department employs different tools for content management and progress monitoring system for eg Sales department tracks upcoming sales demos in spreadsheet, product development group maintains the product enhancements list in the Confluence, Architects and designers establish wiki pages for the list of technology upgrades, business operations group may have their tickets in MyServices, customer support groups triage their tickets in Remedy. Development and Testing groups use JIRA to track their progress, Infrastructure, Configuration Management and other supporting teams may have their own tracking systems and so on.
Unit of work gets multiplied through the different buckets. for e.g. perm fix ticket for the permanent resolution of the production incident is duplicated as JIRA ticket in the development team's bucket. or the line item in the upcoming sales demo spreadsheet finds it's fraternal twin in the Product Management's confluence page or as a JIRA ticket in the development group's backlog.
Department level metrics present the statistics around the amount of work delivered by the department to indicate their performance.
What happens to the Product Backlog?
Organization loses it's sight on the total amount of work to be done for the product. It's shredded and embedded in different tools, different department wide metrics.
This is where Systems Thinking comes in the picture. David Anderson in his book Essential Kanban Condensed defines Systems Thinking as a way of understanding how a system behaves as a whole rather than through analysis of isolated component parts. System in this context is a product; a vehicle to deliver value. Thus an integrated view of all the work to be completed for the product is absolutely fundamental to continuously enhance the value delivered to the customer.
Is it possible to build an integrated view of total amount of work to be done for the product that encompasses across all the departments from Sales to Support and beyond?
Is it possible for the leadership as well as members to organize around this integrated view than department wise activity list?
Integrated View; single authoritative source
Integrated view establishes the big picture for each product, thus it is a first step towards creating that single authoritative source, single source of work. This single source of work should be visible and accessible to everyone in the organization; Big Visual Information Radiators (BVIR); like a arrival/departure boards at the airport or scoring board in the stadium. We will soon find that support tickets are competing against the sales demo work or product enhancements are at a twist with the problem tickets for permanent resolution.
Connection to Lean Thinking and Value Streams
Advocates of Lean thinking will connect it with the value stream exercise. Lean Enterprise Institute, established by James Womack, defines Value Stream as all the actions, both value creating, and nonvalue creating, required to bring a product from concept to launch and from order to delivery. Thus concept of organize around the product is aligned with the concept of Value Stream.
Conclusion
This integrated view & BVIR is the beginning of organizing around the product (work). This should lead to organization restructure for e.g. forming cross-functional teams or managing flow to deliver faster to the market, prioritization of the competing & conflicting requirements, identifying the right agile frameworks and help in building the shared understanding of organization's vision and value it's delivering to the customer and market place at large.
References
1. Mike Cohn; What is a product: https://www.mountaingoatsoftware.com/blog/what-is-a-product
2. The Scrum Framework; Product Backlog: https://scrumguides.org/scrum-guide.html#product-backlog
3. Agile Alliance Glossary: Product Backlog: https://www.agilealliance.org/glossary/backlog/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'backlog))~searchTerm~'~sort~false~sortDirection~'asc~page~1)
4. David Anderson; Essential Kanban Condensed: https://kanbanbooks.com/free-kanban-book-downloads/#ekc
5. Lean Lexicon; Value Stream: https://www.lean.org/lexicon/value-stream
