Many project managers utilize a Lean-Agile approach when there is high change or churn in project requirements, significant lack of clarity in scope, high complexity to their projects, and/or a larger number of risks associated with such. As these approaches have gained wide acceptance in a number of industry verticals, there has also been an increase in the problems being reported.
In this article, we will explore some of the practical problems faced by Lean-Agile practitioners during development of a new product or service and/or the building of a solution. When facing these challenges, Lean-Agile approaches have certain inherent or built-in mechanisms and execution best practices.
At this stage, I want to inform that problems and subsequent troubleshooting challenges the occur in a Lean-Agile approach can be divided into two broad categories:
- Iteration-based
- Flow-based
Two Lean-Agile Types
Earlier, in one of my articles, I had mentioned that Agile is both iterative and incremental in nature. We also previously explored the differences between iterative and incremental development with an example. I’m using the Lean-Agile approach here because many aspects of Lean are becoming increasingly a part of Agile (i.e., pull system, just-in-time planning, flow, visualization, waste elimination, error-proofing, and small batch-size, among others).
When I referred to the two Lean-Agile types, the categorization is based on an incremental delivery aspect. Let’s understand these two types a bit more.
Iteration-based Lean-Agile
In this type, the iterations are prescribed. Each iteration is timeboxed to the same size. Each timebox results in a working a set of tested features. The team pulls the item from a backlog of features, decides which can be delivered at the end of an iteration and usually provides an increment at the end.
An example of this type can be the Scrum framework.
As shown in the above diagram, we have a number of iterations, and each iteration length is timeboxed to the same duration.
Flow-based Lean-Agile
In this case, the iterations are not prescribed. Rather, the emphasis is on flow while having incremental delivery. The team pulls item from a backlog of features based on their capacity, and it’s not based on an iteration timeline. When the feature is complete, it can be delivered. It’s usually based on a cadence.
The number of features that can be taken on is based on a work-in-progress (WIP) limit. An example is the Kanban method, which has its original roots in Lean manufacturing.
As shown in the above figure, there is no regular timeboxed iteration, but incremental delivery can happen in cadence.
With these fundamentals in mind, let’s now explore the problems faced by Lean-Agile teams. In some cases, I’ll be using the terms Agile and Lean-Agile interchangeably.
When the Product Owner is not Available Full-Time for the Team
This problem is predominantly seen in geographically distributed teams, where developers are working in one continent, but the product owner (PO) is operating from another. The product owner, while closer to the market, manages multiple products. This results in constraints because the PO is not fully dedicated to one team or present with them.
Any Lean-Agile team needs strong product ownership. This is crucial for success of the team and the product being built. The PO needs to be committed to the long-term objective(s) of the product (Product Goal or Vision) and continuously participating in the team’s project activities.
To resolve the problem of a PO being only partially available for the team, ensure that the PO is full-time, irrespective of the size of project or his/her location. An absence of this can lead to handicapped team performance and may even little value delivery.
To reaffirm, one of the principles of the Agile Manifesto is:
Business people and developers must work together daily throughout the project.
The PO can be the business owner or in some other structure, the PO can be paired with the business owner directly or via the Agile Project Management Office (PMO).
Nevertheless, the PO should be involved daily with the team members, not on a part-time basis. The PO is the team member who is responsible for the business success of the product. He/she is also accountable to the business.
When There is too Much Complexity in Product Architecture
As noted in the beginning, Agile approaches are designed to tackle complexity, but sometimes project complexity can be too high and one may not know where to begin.
In such a case, one can use:
- The concept of Sashimi, or
- Take a tracer bullet approach
Sashimi is a Japanese word particularly used within the context of food. In Japan, a delicacy is thin slices of raw fish and sometimes served with rice—it’s called Sashimi. Each slice of fish is complete in itself, as well as tastes similar to other slices. This concept can be applied in Agile.
When using Lean-Agile approaches, we develop functionality that cuts across all the layers of a product, which has multiple layers – say front end, middleware, and backend. We are not developing the backend first, or the middle part or frontend. Rather, we deliver functionalities by cutting across all the layers.
The tracer bullet concept is based on the idea of firing in the dark! When you fire a gun in the dark, it’s difficult to aim due to the lack of light. However, when the path of a bullet is lit up (tracer bullet), you can see the trail and use it to inform your next aim. In other words, the tracer bullet helps to improve your aim for subsequent firing.
You can say, a tracer bullet of functionality is very similar to a Sashimi approach. We see the path of a bullet passing through all the layers or a functionality consisting of all the layers of a product. We are shown the path to build other functionalities.
When Inaccurate Estimation Results in Delayed Delivery
This is another problem frequently seen irrespective of industry verticals. Developers, with all due respect to them, are generally optimistic people. The trouble is that when there are high uncertainties or complexities in a project, optimism may not be your best friend.
Estimates are often inaccurate because they are made in absolute numbers. For example, it will take five days to complete a feature/backlogged item or six hours to complete an activity.
One way to resolve this challenge is to use story points for estimation. Story points are relative estimation techniques and have unitless measure. Story points are relative estimates because they compare size, complexity, difficulty, and risks among other items being estimated.
To utilize story points, estimate the tasks (i.e., stories decomposed into tasks) into ideal hours. While the usual time unit used is eight hours a working day, it’s not always the case because of other activities such as meetings, unforeseen customer escalations, and interruptions, among others. When estimating using ideal hours, the time consumed for all non-productive, but necessary work is not considered.
This is depicted in the below figure. Ideal hours are considered here to be four/day.
When Backlog Items are Insufficiently or Improperly Refined
Backlog refinement is a common practice and widely used in both iteration- and flow-based Lean-Agile types. The team starts off on the iteration or can take the item to the flow of work.
Let’s consider an example of an unrefined backlogged item: As a user, I can manage my settings, so that I’ll have the setting related information.
This is not exactly a small user story, but a very big one. In fact, this story can be decomposed further into three:
- As a user, I can manage my address details.
- As a user, I can set or reset my password.
- As a user, I can set my email preferences.
The address part alone comes with multiple parts, and a user has to utilize multiple operations to manage it. For example, add, edit, and delete. For this purpose, the product owner or product manager needs to have a good understanding of (user) stories, as well as refinement techniques.
To address this issue of improperly refined backlogged items, one can use the Definition of Ready (DoR) skill. Definition of ready is a checklist, which needs to be checked off step by step to see if the team has all the needed information before working on the item. DoR can be used before the beginning of the iteration or before taking a work-item into the flow of work.
When a Deluge of Defects Occurs
There are many scenarios in which this can happen:
- Team is new to development
- The team has a lack of strong engineering practices, among others.
When the team is new to Lean-Agile development, it’s always a good idea to have training to understand the values and principles of Agile. The most difficult part, however, is the internalization of these values and principles (i.e., applying them daily during the project work). With a correct Agile/Lean coach, this understanding will be needed to sustain the project.
In addition, good engineering practices are not only necessities, but vital to stop deluge of defects and provide good-quality products. Some are noted below.
High test coverage and testing at all levels: You can implement high test coverage both at the system level, as well as unit test level, with automated test cases. The team should have testing at various levels, such as:
- Unit testing: Testing done at the lowest level.
- System testing: End-to-end testing of the full system or product.
- Smoke testing: Lightweight testing to ensure workability of the most important parts, and others such as black-box testing and regression testing.
Refactoring: Many associated refactoring is done within the context of software, but it can very well be applied to any product work. In fact, it’s a product quality technique with which you improve the design of the product through maintainability, but without changing the external behavior.
Simply put, with refactoring, you can change the internals of a product without changing the external behavior. With continuous refactoring, technical debt (i.e., legacy debt due to deficiencies in design, documentation, code (or product work), associated third party tools) is gradually reduced and defects are kept in check.
Continuous Integration: Any (product) increment given at the end of the iteration or continuously as in flow-based Lean-Agile, should be incorporated into the whole product. Post integration, the product still should work as intended.
Test first, develop next: In XP lingo, it’s called test first programming and in common Agile parlance, one can call it test-driven-development (TDD). Automated tests are written before doing the product work or creating the product. Next, work (or coding is software) is done to meet this test. This results in a built product with lesser defects.
Collective Ownership: In XP parlance, it’s usually referred to as share code. This concept says that the product work is owned by everyone in the team. You can also say, product quality is everyone’s responsibility.
When Rework or Incomplete Work Happens
While working with an iteration-based Lean-Agile approach, an increment can be achieved on a cadence or on-demand. One the principles of the Agile Manifesto tells us this:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or product).
If increments are not being delivered early and frequently, then the main purpose of going with a Lean-Agile approach is lost.
When the team delivers an increment, it must be fully “done” or complete. For this purpose, Definition of Done (DoD), an Agile artifact is used. Definition of done is primarily a checklist of items, which needs to be crossed-off, before a backlogged item or a story is considered finished.
To have proper work completion, the DoD should be exhaustive and clear. A sample DoD is shown in the below table. Only when a backlogged item has cleared the checklist of items listed in the DoD, is the work considered to be complete. Within this context, the issue of rework and/or incomplete work is addressed.
When Product Demonstrations or Reviews are Dysfunctional
While retrospectives are considered to be the most important practice in a Lean-Agile approaches, a close cousin is the practice of product demonstration or reviews. This is a very important event because Lean-Agile is fundamentally about value delivery to customers early and frequently, getting feedback, and customer collaboration – all of which happens in a demonstration or review collection.
While new teams can have failures during demonstrations, it’s also seen for experienced teams. Here are some situations that may occur:
- The (product) increment is not behaving as expected
- Features promised have been missing the demo
- The product crashes, or
- Worst of all – the PO and key stakeholders don’t accept the increment
Multiple dysfunctional product reviews can have a serious impact on the trust customers have in the team and equally, the self-confidence of the team who is delivering. To resolve this challenge, several things can be done.
Prepare early before the actual meeting: You should have a set of items or checklist of items prepared prior to the review or presentation. Not only should the team should take some time preparing for the meeting, but for an iteration-based type, they should use a checklist similar to the sample template below.
Next, while running the meeting, document the decisions being made. This event, as noted before, also involves getting feedback from the customer/stakeholders and incorporating that feedback subsequently. With an eager clientele, a number of enhancements, new stories, or workflows will come up and it’s important that you note them.
Towards the end of the meeting, ask for acceptance on the increment. The acceptance may be conditional or there may be a time lag, before formally being accepted, but do ask for this, as it allows the increment to be released. This also tells the team that the increment delivered has met the definition of done (DoD).
Above all, never cancel the meeting. Sometimes it’s possible that you have very little to show or even that you know your product increment may crash. Still, go ahead with this event, as you will get feedback, and can make course corrections, if needed.
—
There are a number of problems or issues that can come-up while implementing a Lean-Agile development approach. In this article, I’ve outlined some of the challenges along with possible solutions.
What are the problems that you face? What approaches do you take to meet these challenges? Let me know in the comment section below.
--
This article was first published by MPUG.com on 9th March, 2021.
References:
[1] Course: ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash
[2] Book: I Want To Be An ACP, The Plain and Simple Way, by Satya Narayan Dash
[3] Agile Practice Guide, by Project Management Institute (PMI)
