Net Objectives Lean-Agile Framework

Note: We are in the process of moving this material to our portal which will include it in both an online visual format as well as an online book format.  Please ask questions on the portals' forums.

After 15 years of experience in Agile, Net Objectives' has discovered the actions and organizational structures that companies must adopt to achieve Agile at scale.  The Lean-Agile Framework (LAF) is Net Objectives' codification of what the dozen or so practices that must be mastered for effective software development.  Knowing what these are is only half the challenge, however.  Getting there is the other.  Depending upon your organization's culture, service/product offering, current technical debt,  physical arrangement of people and several other factors, how to transition from where you currently are to manifesting the activities the framework requires will vary.  Our Lean-Agile-Roadmap provides guidance to help organizations transition from where they are to the LAF.

In the last decade of the 20th century, the methods for technical agility - ATDD, TDD, emergent design, design patterns, ... - were introduced and explained.  During the first decade of the 20th century, how to be effective at the team with Agile methods has been demonstrated and continues to improve.  In the last few years, Lean and Kanban have been showing how to extend those successes throughout the enterprise.   

The Lean-Agile Framework is a collection of the necessary activities than an organization must master in order to be effective.  We are not claiming these are unique to us.  The key is to realize if you don't accomplish certain core practices and follow certain key principles, you are unlikely to be successful at scale. Organizations need to first understand what these methods are and then determine their best way to achieve them in their organization.

The Lean-Agile Framework organizes the necessary practices to follow into four groups::

Business Stakeholder and Portfolio Management

  • Business stakeholders must identify, size and sequence the work to be done with a focus on delivering the maximum business value quickly
  • Continually prioritize across the product portfolio (analysis and delivery)

Cross-Team Management and Cross-Product Architecture

  • Make dependencies across projects visible (proper architecture)
  • Plan the work to be pulled from the required teams from shared backlog
  • Focus on sustainability of realizing value by attending to an architectural roadmap of your software 
  • Avoid delays in workflow and feedback across a product's value stream

Team Methods

  • Build in small increments while managing your work-in-process levels. This creates quick feedback cycles while lowering the impact of interruptions.
  • Use an Agile team method where team can self-organize within the context of the bigger plan. If you can't create pure cross-functional teams, create them to the extent possible.
  • Use explicit policies to create visibility within the team, across teams and to management
  • Manage work in process within the team. Focus on finishing work before starting new stories.

Technical Agility

  • Use Acceptance Test-Driven Development to achieve understanding of what is to be built before starting coding
  • Begin with the end in mind – understand how integration across the teams will take place
  • Use proper technical skills to minimize technical debt

An expansion of each of the above:

  1. Business stakeholders must identify, size and sequence the work to be done with a focus on delivering the maximum business value quickly. The most important items must be selected for implementation and Minimum Business Increments  (MBIs) or their equivalents (MMFs / MVPs), must be used to define these
  2. Continually prioritize across the product portfolio to select the most important capabilities to be built and delivered.
  3. Make dependencies across projects visible. That is (provide an holistic, architectural, view of what is being worked on must be undertaken to ensure work is not done that inadvertently adversely affects other components of the system
  4. Plan the work to be pulled from the required teams from shared backlogs in order to facilitate coordination of the teams' work. Doing so provides a context that they can work within.  This works much better than attempting to have them coordinate themselves. 
  5. Focus on sustainability of realizing value by attending to architectural roadmap of your software. We must attend to the overall quality of your systems in order to be able to go fast in the future as well as now.
  6. Avoid delays in workflow across a product's value stream.  Delays cause extra work. Extra work is waste and tends to further overload typically already overloaded teams.  Delays can be managed in many ways.  Common ones are using feature teams and managing queue size with work-in-progress limits.
  7. Build in small increments while managing your work-in-process levels. This creates quick feedback cycles while lowering the impact of interruptions. It also allows for the changing directions if required. Most companies operate in an environment where something that wasn't planned for needs to be addressed This could be a new idea from a high-level business sponsor or a severity one errors.  In any event, interruptions will happen!  Claiming they won’t by having a set iteration that can’t be changed is just hope over experience. 
  8. Use an Agile team method where team can self-organize within the context of the bigger picture.  All Agile methods respect people's intelligence and ability to innovate.  However, teams can't just do what they want.  They must work within a bigger context that helps create the bigger picture results needed - delivering business value across the organization.  See Cross-Functional Teams Eliminate Waste and Manifest Lean to understand why this is so critical. See Creating Teams When It Doesn't Seem Possible.
  9. Use explicit policies to create visibility within the team, across teams and to management.do not mean fixed.  Explicit policies do not mean fixed.  It means that they are explicitly described so both everyone knows what they are and so that we can test our understanding based on what actually happens.
  10. Manage work-in-process within the team. Focus on finishing work before starting new stories. Shortening cycle time is one of the best ways to improve flow.  Cycle time can be shortened by limiting work-in-process to be no more than the capacity of the team. Too much WIP creates delays which creates additional work to be done.
  11. Use Acceptance Test-Driven Development to move QA and support up to the front of the value stream.  It is possible to avoid misunderstandings in requirements.  However, the right people must talk to each other at the right time in order to do this.  This is one of the best trim-tabs we know of.
  12. Begin with the end in mind.  Consider how you will validate what is written as well as integrate it.  This is particularly important when multiple teams are involved and in embedded systems.  While limiting work-in-progress (WIP) may provide solutions if a steady team structure will do the job, very often other methods, such as dynamic features teams, may be required.
  13. Use proper technical skills to minimize technical debt such as  emergent design, automated testing and continuous building.  Incremental construction requires fluid code.  This requires the ability to build code in small steps (emergent designs) and be able to evolve as needed.  Building in increments also allows teams to have their work be interrupted at set points.  This will enable new ideas to be developed to come into the development cycle without significantly adversely impacting the efficiency of the development team.