15. Lean not agile: Staying away from "agile"

Out of various dictionary meanings of lean, I choose to use "not fatty or lacking excess flesh". In product management, it could mean delivering small quantities of value with every release, and delivering it right.

Agile means quick and alert, characterized by ease of movement. It focuses on delivering values quickly, and adapting to change.

Agile is one of the proposed ways to develop product releases to utilize learnings fom lean manufacturing paradigm, however it focusses too tightly on development and not on overall lifecycle.

Even in development teams, as it has been acknowledged, "Agile" has been misunderstood, and mis-implemented, because most of the people just got into "agile" because they heard about it in a conference, or somewhere else. The basis of agile was not understood, it is just followed as a rule book of product development. Agile is thought of as a way of reducing buerocratic documentation and relaxing stringent discipline of current practices, and shifting blame of delayed product release to stakeholders.

That's why I tend to stay away from using word "agile", and focus on principles of "lean manufacturing", which have been proven to bring visibility amongst everyone aboard, emphasize on regular communication, enhance disciplined collaboration, and make successful products time and again.

14. Lean Learnings 2: What not to do?

This is sequel to an earlier post, and captures aspects that are commonly get out-of-sync between product stakeholders and development team.

1. This is top priority because CEO asked: Many such reasons are cases where stakeholders do not have visibility into resource estimates by development team, and/or product teams do not have visibility into business value as perceived by stakeholders. Such stories may not mature rightfully with acceptance criteria, and fitness of derived value in long term product ecosystem will be low.
2. Believing user story is a requirement specification document: Having user story on an index card is a good start. Along the way, it is important to capture conversations in other forms of documentation, and should be track-able from user story. I call this process "maturing" a user story.
3. Acceptance criteria is not as important as statement of need: Statement of need is, again, a start. Acceptance criteria is confirmation of need, and should be carefully penned down, and as a indicator of size of user story.
4. Describing how to implement a story: Agile product development teams own the process of development, and are expected to know the product well enough to decide "how"? This should be respected; business analysts and product managers should concentrate on crisply defining "what"
5. De-prioritizing technical tasks: This is common mistake with mature products, since business stakeholders do not have visibility into business value of technical tasks. In a user story, it is important to capture the cost of not addressing such needs, so that stakeholders and product development are in sync.

12. Emphasis on "stop the line"

As product matures, a secret backlog is growing. The items in this backlog never seem to be as cool or interesting as the shiny new features described in the user stories of the product backlog. Where user stories tell us what we want the system to do, this secret backlog tells us all the things the system does, that we don’t want it to do… This secret backlog is our bug-list.

While implementing user stories feels like progress, fixing bugs feels stagnant. User stories end up getting all the attention and are prioritised relative to each other whilst bugs just sit there, waiting for their turn and decide their fate.

Sometimes, bug get their turn when its too late!

Why?

1. I guess because outbound folks (marketing, sales) and customers do not have enough visibility into impacts of not fixing bugs or waiting too long.
2. Bug reports are not in same format/system as user stories (product backlog), it’s hard to determine relative priorities when it feels like you are comparing apples and pears.

What to do?

1. "stop the line" strategy: as much bugs as possible should be fixed before working on user stories.
2. transparency: giving visibility about bug list with stakeholders helps everyone in understanding short term and long term impact of bugs and reduce discrepancies in perceived business value/ROI
3. integrated systems: keeping bugs and user stories in same systems helps in prioritizing them at the same time.

11. Stopwatch: Just in time

In an earlier post, I talked about "stop the line", but did not mention preceding concept of "just in time".

For product management, "just in time" may mean

• Committing to a user request as delayed as possible: This gives us a opportunity to collect maximum information about the request, and keep collecting more until it is finally the time to make a decision.
• Delivering the response to customer as early as possible: Don't keep it on shelf. Deliver it hot and fresh.

As delayed as possible does not mean forever; just-in-time also implies that every activity in the stream must be timed (stopwatch concept), and if any work fails to start/end by stipulated time, then it is considered late.

Along the same lines, it is a good idea to have timed product releases. It is a fairly strong concept in my opinion especially if you are working with a product with difficult consumption. Any software product to be deployed in an enterprise level environment is a good example.

A timed release gives organizations opportunity to plan for upgrades/deployments, as they can expect more stability compared to last release. Complemented with constant visibility into development status, the whole process becomes even more easier.

10. Accountability to internal customers

Ian and I had a chat earlier this week about accountability of product manager's work and some techniques to improve internal communications.

Product managers operate with a mindset of a customer proxy, and try their level best to deliver maximum value to users.

At much as the above statement is true, a product manager can achieve faster value delivery cycle, if he/she starts to see developers as consumers of his/her work, i.e. starts being accountable to developers as well as customers.

As counterintutive it as it seems just like other lean manufacturing observations, this is a way of respecting developers and their opinion.

9. Lean learnings

One of the key factors that enables businesses to regularly deliver value and have successful products is the ability to respect people who work to develop the product.

As an example, a developer is the best judge of complexity of code and what resources it takes to develop quality code. It is a product manager's job to balance business values, and it is important to instill it in development team, but at the same time, it is important to respect developer's commitment and knowledge.

Too pressing negotiations result in weak scaffolding and inadequate quality of code, which may not become apparent immediately, but seriously impact value delivery in future releases.

If a product manager wants to consistently deliver value to users, one of the effective ways is to deliver bite-size (not too big, not too insignificant) change in business value with every product release. This has many advantages:

• Less amount of testing is required
• Less amount of documentation is required
• Less amount of field/user training is required

In general, it becomes easier for developers to develop it, and it becomes easier for users to consume it. When developers get visibility into such realization of value, they are encouraged to deliver faster releases.

Another related and important lean manufacturing concept is "stop the line" (more about it later). As a product grows from infancy, there is another tug-of-war between development and delivery teams. Development team wants to cleanup/refactor the code, or even rewrite an entire feature, but challenge for delivery team is to justify this expensive move. Past experiences in many organizations have proved that respecting core team's decision are less expensive in long run, and enables regular delivery of value.

Many businesses have also achieved similar or better results by allowing development teams to undertake less work than their capacity, and allowing time for maintaining quality and even innovation.