One of the agile development ecosystem series: Preface and demand management ecosystem (Customer Value Orientation-work software-response to changes)

This is the first article in the agile ecosystem series (One, Two, Three, Four, Five ).

The so-called ecosystem refers to a series of creatures that depend on each other to survive. The ecosystem is often not one-way dependency, but mutual dependency and mutual promotion.

The same is true in Agile development. Typically, when a practice is difficult to implement, do not think that a simple system can ensure its implementation, but think about what causes its failure. For example, if every Hitachi Conference finds that everyone is not meeting on time or even not, what we need to do right away is not to ask everyone to have a meeting on time + the Meeting will be late for everyone to buy fruit + count the monthly ratio on time + ...... Instead, they should think about why these people don't come on time. They must think that this meeting is not very important. What they talk about at the meeting cannot help their work, but delay their time. In this way, we can find out the underlying problems of meeting failures.

In Agile development, the demand management ecosystem is roughly as follows (see the illustration in bold, which is an element in the illustration ):

 

Customer Value OrientationIt is the main idea of agile development demand management.

Agile development is believed to be closely relatedCustomer collaborationThe customer's requirements can be clarified better than the detailed documentation, and the stagedWork SoftwareAdditional invitationCustomer participation in reviewThis makes it easier for customers to correctly supplement requirements and accept products than to review requirement documents.

I believe that the software after the change will be more valuable to the customers than the software before the change, so agile advocatesRespond to changes. Work products are provided to guide customer changes, so that customers can better describe changes correctly and accurately. Iterative delivery enables important and necessary changes to be delivered in advance, it doesn't happen until the end of the waterfall model.

Pass requirementsPriority sortingAnd iterative delivery, first of all, can ensure that important needs can be delivered to the customer; secondly, can ensure that important changes are temporary, can give up the secondary needs that have not yet been developed as an exchange; once again, we can ensure that the product owner (PO) will give priority to analyzing important requirements without putting them into development in a fuzzy state.

Only the highest-priority requirements will enter the next iteration, so few changes are more important than them, and these requirements have been analyzed in depth, so the product owner has the confidence to promiseNo changes during the iteration PeriodIn exchangeTeam commitmentTo maintain deliverySustainable paceOccurred.

Embrace changeIt is an active and controllable process supported by various practices such as customer collaboration, priority sorting, and work software, rather than passively "being changed and embraced ", the Unity of Opposites Between "no change in the iteration period" and "Embracing Change" must be based on these practices.

Customer Value Orientation-work software-response to changesThese three are the core content of the Demand Management ecosystem. The following describes how the demand management ecosystem works from an analysis of a problem.

 

"Why does the customer leave the review meeting blank? Let's just say that we can continue to develop some features ?"

This is a very common scenario. The simple and crude processing methods include:

1. If no comment is made at the review, it indicates that the function is accepted.

2. After the conclusion of the review, the functions that have been completed must be checked and accepted in writing.

3 .......

However, these are only practices that execute scrum rudely, without obtaining the spirit of scrum.

After careful analysis, the customer has many reasons for doing so, some of which are not easy to control, and others are the opposite:

1. The Representative sent by the customer is a "small role" and cannot make decisions for the customer.

2. Our software is not a "workable" software in the customer's eyes, so he cannot or doesn't want to draw conclusions too early.

3 .......

There are various solutions in the actual environment to solve the "uncontrollable" problem of type 1, but they only work in size. For example, copy the function of each review to the owner of the other party to pay attention to the function, and invite the end users of the function to participate in the review. For more information, see the specific analysis.

There is much more to do with the "controllable" Issue 2.

What is workable software? In the eyes of developers, working software can easily be equivalent to running software, "it can run on our test server, we also have automated scripts that can automatically run and test their functions ......" But in the eyes of customers and users,Work software is the software they can use now.. For example, if a word software can be edited but cannot be segmented, the title can be inserted, but the font size is the same; the picture can be inserted, but it is only a link that needs to be double-clicked to open ...... These three functions are vital functions, but software that temporarily joins them together cannot be used by users. It is better to make a "only editable for the time being, but it can be segmented and indented. It is suitable for writing simple text without complicated format, for example, in a private email (another option in outlook is to use word to edit the email) ", even if the customer does not accept this as the final product, however, it can be understood that in such a scenario, the software is not easy to use, and where to improve and so on.

Perhaps in order to make this software, we have broken the priority sorting to some extent ("inserting a title" is more important than "indent ), however, it makes "deliverable" and "Customer Review" a reality. In fact, from this perspective, we are producing software in a way driven by customer value, that is"Executable software" should be defined from the perspective of "customer value-driven".

Well, the answer to this question comes out: we generally divide the product backlog into severalStory GroupEach story group can be delivered completely. In advance, we invite the customer to participate in the sorting of story group development, so that the customer can know when to release the feature and to review the feature by themselves; after seeing a complete set of functions, the customer is more likely to come to the conclusion of "is all this feasible?". If they want to, they can also deploy and try it out in advance ......

I personally feel that although I cannot be superstitious about its universality when applying agile practices, I should never immediately deny them when encountering setbacks or attribute the problems to the culture and company environment; as developers and management personnel, we are very likely to do less or more things.

Some readers may see the important ecosystem line "don't change during iteration-team commitment" on the right side of the figure, which will be mentioned in future "plan tracking.

 

Click to download the free agile development textbook: Martian agile development manual