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.

Key: Product Release

A few pointers as a product release criteria:

1. Modularity: Product should be broken down into individually releasable modules. The benefits are far-reaching during product maintenance.


2. Visible communication: Whats new/removed should be clearly communicated to users. Include list of bugs fixed (with # if possible) to make consumption of product easier.


3. System abuse: Install/Uninstall/upgrade testing should be thoroughly done before releasing the product. In my experience with customers, this is a real bummer if not tested properly. If there are any embeddable modules, they should be easily consumable too!


4. Regression: As obvious as it sounds, this is also the major pain area, and should be clearly stated in release criteria.

Many other pointers for a enterprise level software are listed here.

Key: Product Backlog

1. Product backlog should only contain items which provide business value.

Product backlog generally start getting cluttered with technical tasks, without considerable visibility into business value, which makes it difficult to judge right priority.

2. Product backlog should not contain items which cannot be consumed in next 2-3 product releases.

Having too many items in product backlog clutters, and makes it difficult to make priority decisions.

3. User stories to be consumed in next 2-3 sprints should be mature with acceptance criteria.

Freezing acceptance criteria too early or too late may require rework, so apply "just in time" strategy to freeze them at the time they are ready for consumption"

4. Precise feature statement

Feature statement should be a one-liner statement of demand. Use of conjuctions (“and” or “or” or “if” or “until” or..) generally means features are being clubbed together and candidate for decomposition.

Almost all industry experts agree that writing feature statement in first person is very effective in stimulating thought process clearly.

As a user, I want/need to do something, so that I can achieve this

4. Acceptance criteria should be limited but not scarce

Acceptance criteria is the confirmation of expectations. It should be bite-size chunk of business value, but having less than 3 bullet points will make user story very small and difficult to manage and provide visibility into. Having more than 7-8 items generally means story is getting larger, and should be broken down.

5. Release criteria must be a product backlog item to be discussed and check-listed in every sprint

Many of the technical tasks including system abuse parameters can become part of release criteria, and should be allocated some time for execution during every sprint.

6. Entire product backlog items must be prioritized using stack-ranking and estimates.

Initial resource estimation and stacking user stories is a good way of visualizing product roadmap. Generally, I prefer to stack rank for every quarter with 100 point estimate for every stack.

For a enterprise product with 2 releases a year, quarterly stack ranking for 3 releases (6 stacks) is a good idea.

13. Wow! I need it: Blending pre-requisites and exciters

• A house without a bathroom is useless. (prerequisite)
• A family needs 3 bedroom house, will not consider 1 bedroom, but 2 or 4 will still do. (the more the better, but more expensive)
• The view from the house is amazing, I want it!(exciter, unique selling point)

Many features are included in product just to excite a customer to initiate a sales process, but are seldom used. Other type of features are absolute must, just to enter the market, and will be used by almost every user.

However, developing and maintaining exciters is expensive. For example, a builder may buy a expensive land to ensure good view from every house, but may lower down the quality of building material to sell it at a market prevailing price. Almost everyone wants to have good landscaping in their neighbourhood, but is seldom willing to pay for it.

This is where segmenting the market becomes important! For sale to high volume, price-conscious market, usability will be more important than view, but for low volume, quality-conscious market, an amazing view will override pricing concerns, and resource allocation for designing and implementing exciters will no longer be an evil expense, but prudent investment.

To capture a larger market segment, most desirable and middle path is to design a must-have feature is such a way that it becomes a exciter for the high-volume, price conscious market, and advances a product's competitive edge.

Exciters that do not satisfy prerequisite or performance needs should be kept to a minimum, but in any case, exciters should be allocated top priority because they are by definition what satisfies the customer and/or market need.

Bottom Line:

1. Innovation: Finding solutions to prerequisite/basic needs so that they become exciters for the market, i.e. sufficiently implemented and high customer satisfaction.
2. Amount of implementation effort must be controlled by limiting the number of exciters that do not satisfy prerequisite need, and not the quality.
   

Looking ahead

There may be possible scenarios, where initial lower quality/implementation detail is acceptable, and can be progressively improved (for example, fuel efficiency of car). Of Course, the better the implementation, the more customer satisfaction there will be, but at the cost of higher investment.

On an average, for every 10% increase in user stories of enterprise level software, system testing time increases by 100%, and deployment times increase by 30%.

lastly, it might be prudent to keep "will not implement" user stories in traceability map, to avoid duplicate user stories in future.

Inspired from here and here

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.