Eliminating detailed requirements or that extensive design specs or perhaps the problematic or stage-gated governance that ends up hindering progress, that un-necessary sign-offs with independent delays and all other counterproductive processes are what we are up against when choosing to implement lean agile methods.
There is certainly no definitive lean method, however, the framework is or should be standard across different organisations irrespective of the solution or business model.
Scalability is a key factor here, organisations want a process that fulfils their business needs. This has not always gone well with all parties involved in software delivery as what is usually loudest is the “Do what I tell you to do” policy. I.e. a concrete top-down approach with no room for bottom-up feedback thereby indirectly hindering the freedom necessary to drive creativity across delivery.
What if an organisation can eat their cake and have it? i.e. a feedback loop that allows teams to feed values that get embedded into the structure or framework which also feeds back down to team level thereby everyone having their way. This usually sounds easier than done, but a simple lean agile framework can do the magic if all parties are patient enough to see through the process.
This article simply highlights the big picture of a lean-agile structure required to build the complex solution or system that solve the problems of today. The three levels that make up a lean-agile framework are:
- Team Level
- Program Level
- Portfolio Level
-
Team Level
These are the front-line soldiers of the agile delivery process with key responsibility to write and test the codes that deliver value. This team is usually made of a maximum of seven-nine members although it’s not the end of the world to have more considering some teams are committed to building large features hence an additional one or two extra team members will do no harm.
For this value to be fully achieved, the development team should be supported by architects, Quality assurance, Database and IT specialists. In satisfying this objective, some organisations follow a cross-functional team model whereby each team will have a group of Developers, QA/Testers, IT specialist, and a Database Engineers, Ideal but most cases impractical since resources will always remain scarce in the world of software delivery and management.
In many other cases, team members may have more than one skill which might be useful in for the team, but this must be incorporated into planning since one, two or three team members may have to divide their time to perform more than one type of activity. Whether this is ideal or not, it’s certainly not a topic for today for this article focusses only on highlighting the lean agile picture.
One thing we do know is that teams are self-organised and self-managed to either deliver features or components. While Feature teams focus on delivering vertical user-facing initiatives, component teams focus more on building shared platforms or middle layers that support the delivery of features. Most large organisations will have both. These self-managed, self-organising team should be flexible enough to change to organisations potential changing need or priorities, but also must be static enough for at least six months to go through the storm, norm and form phases.
The roles in a typical agile team are:
- The Scrum Master/Agile Coach
- The Product Owner
- Developers
- Testers
The Scrum Master/Agile Coach is always recommended even if the team is not practising Scrum. He/she has a duty to serve the team and help them transition into an agile way of working and help manage the relevant agile ceremonies. In addition to the team, the Agile coach also helps in aligning the organisation towards the agreed or proposed agile framework intended to deliver value and some organisations by call this role the agile project manager.
The Product Owner is responsible for prioritizing requirements (User stories) and managing the product backlog. This is a role that is also very important even if the team is not practising scrum as this have proven to deliver breakthrough in simplification of teams work. This product owner role also clearly falls in-line with item number four of the agile principle ie business people and developers must work together daily throughout the project. The PO represents the business within the team.
Developers and testers write and test code and will work in sprints. Iteration is the keyword associated with the work they do as new functionality is built in short time-boxed events called iterations also termed as Sprints if the team is using Scrum. It must be noted that each sprint will deliver value of which this could be a full flesh functionality or a valuable increment leading to a full functionality.
The above key roles will work together to plan, build, test and demonstrate functionality to stakeholders, inspect and adapt and finally the entire process is repeated.
-
Program Level
The program level is responsible for the Agile Release Train which is also time boxed but with a variable scope hence taking us away from the iron triangle of project management.
In a lean agile methodology, the program Level comprises of additional roles, processes ad requirement artefacts and usually suited or relevant when building larger scale systems or products.
This level of lean-agile method helps manage:
- Releases and Potentially shippable increments,
- Vision, features and the program backlog
- Release planning
- Roadmap and product management
Releases/Potentially shippable Increments:
There is a goal here to set up a structure that enables teams to produce a shippable increment but then again what really should be considered shippable? Why should a particular item be shipped within a particular time frame? How will the business expectation be met? What are the standards for refactoring, testing and which compliance process is in place to ensure an overall quality that meets the legitimate business objectives?
Important factors like customer licensing and service agreements, customer overhead and business disruptions, user training, potential disruptions of customer existing operations during regression or defects are all considered and managed accordingly within the Release management category of the program level.
Some organisations will have a dedicated release manager for this role which usually should make things a lot easier for the team.
Vision, features and the program backlog:
Just as a Release manager can be introduced in the category above, a product manager can be introduced here. The responsibility will be to maintain the vision of the products. The vision answers questions like:
- What problem is the solution solving?
- What features, and benefits will it provide
- It answers the whom, what and why questions
- Performance reliability
- Platforms and standard that will support solution.
Answers to the above questions will constantly keep both the team and the business focus in investing time and resources only on what adds value to the overall business objective and goal.
Release Planning:
The art of working in cadence, the beauty of breaking features into stories and adding agreed stories into iteration cadence based on the knowledge of their velocity births the release planning process which comprises of inputs of the vision, objectives and the desired features hence making up a batch for upcoming release based on priority.
Teams gather in a single location and discuss their inter-dependencies, negotiate scope with product management guided by the understanding of their known velocity which therefore determines which stories can feasibly be in the upcoming release(s)
This activity has both tangible benefits like having everyone onboard and participating through collaboration in determining what should be in the next release train and also an intangible benefit of which teams subconsciously endeavour to meet their commitments.
Roadmap and product management:
A series of planned releases and their relevant dates are usually mapped in the roadmap. The release panning activity feeds from that data while the roadmap, on the other hand, focusses on a series of many potential releases and their possible timeline. The release planning will always focus only on the next release and a cadence of three, six or nine weeks is ideal for each cadence.
In summary, the roadmap represents the organisations ‘plan of intent’ for future releases and is usually managed by the product manager within a lean agile setup.
-
Portfolio Level
The big picture made up of teams or individuals dedicated to managing the investments of the organisation or enterprise by directing the overall business strategy falls within this group. The artefact derived here are:
-Investment Themes
-Epics and Portfolio Backlog
Investment Theme:
The establishment of the investment objectives for the organisation driven by the vision of all programs falls within this group. The portfolio managers, business owners and other high-level roles are responsible for managing this category and will help drive the epics that support her investments.
Here, Portfolio managers are responsible for creating unique value propositions that different solution from existing marketplace and create a competitive advantage is usually derived and proposed at this level by gaining feedback both externally and from the team and program level.
Epics and Portfolio Backlog:
The highest level of customer expression is called epic. They are intended to deliver the value of an investment theme and the portfolio managers will do well to identify, prioritize, estimate and maintained these epics within the portfolio backlog. The recommended estimating metrics for this level could be the t-shirt sizing ie small, medium and large which will later be decomposed or broken down into features, then stories making them ready for implementation by the team.
Again, for all these to happen smoothly, there must be good collaboration between the team level program and portfolio level. They all meet during release planning even and discuss any difference or mis-understanding thereby guiding everyone on the same page for the delivery of the next cadence.