Few Simple Tweaks to Boost Value Shipping

I have used following simple tweaks to produce great benefits in our endeavor of shipping value to the market.
To implement these tweaks we spent zero money and it does not ask for any certification either.  All it took was an open mind and some practice.  
Maybe this could help your teams too.

1) Parallel Testing:: It needs some mindset change. All it requires is Dev+QA participation while PM/PO describes the User Story and a common desire by Dev+QA to produce good code.
An additional benefit of this practice would be, QA folks will stop thinking that "Logging MORE bugs" is the yardstick of their performance.
QA folks would start writing the potential pitfalls (aka TestCases) even before Developers start coding, and WHILE they are coding. This would immensely help the Developers to produce good code. QA folks would inculcate a thinking that NOT allowing a bug to creep in, is the real yardstick of their performance.

Even a mason knows the right time to use his plum bob is, while building the wall, not after building it.

2) Merge Columns:: On your wall board (whatever board you call it) you should *NOT*  have 2 separate columns for “Development” & “Testing”. Having these 2 columns is as good as giving a license for having silos for "Dev" & "Testing".
Just merge these 2 columns into a single column and call it “Building”. You will see the magic it makes for collaboration, particularly between Coding and Testing functions. 
A work-item (UserStory / UserStorySlice) in this column becomes joint ownership of Developers & Testers. Any work-item will come out of this column, only when Developers AND Testers feel happy about it. 
You will see how radically it reduces to and fro between Dev & QA.

3) Vertical Slicing:: Slicing User Story needs zero money. However it needs some practice by PM/PO. It also needs some change in the way PO & Dev decide to ship. It needs some curtailing of ambition for Shipping the entire User Story in one go.
This sounds a bit counterintuitive, but this is extremely effective as it avoids a good amount of wastage from being built.

4) Information Radiator:: Radiating only those metrics that matter is crucial. Deciding your North Star metrics involves some thinking, actually a good amount of team thinking, (sometimes involves heated arguments within the team). A team needs just 2 things for an  Information Radiator
(a) a brutally transparent way of working and (b) a large monitor placed in a common area.
Placing your Information Radiator in the corridor on the way to the coffee machine (like something shown below) is a perfect choice. Radiating the information to ALL (within the team as well as outside the team) is the key. The money spent on the large monitor will be paid back 100 times in a matter of 2 months. 

Information Radiator nudges us to focus on the right questions and helps us to avoid wasting time on bike-shedding.

5) Acceptance Criteria:: Start working on a UserStory only if it mentions some Acceptance Criteria (even if it is minimal). Inculcating this discipline of mentioning Acceptance Criteria costs zero money and this practice will reduce the chances of getting a boomerang from the customers. It nudges the PO to develop good outward focus and that hugely helps the PO while describing the User Story to the team.
At the same time, the team (particularly the Dev Team) must keep in mind, that insisting on Acceptance Criteria is just to nudge ourselves for a better discovery process. It should not be treated as a Contract. 

Well-Refined Backlog

Who does not want to have a well-refined backlog?
Unfortunately “well-refined” does not have a universally accepted definition. Neither it is a DIN standard. 

So, any team, any org can have its own interpretation of a “well-refined” backlog. 
Here is my interpretation of what I mean by “well-refined” backlog. It consists of 5 aspects.

1:  User Stories should/must be sliced. The thinner the slices, the better it is. 

2: PO should have a fair idea about the Value of each slice. Value as it would be perceived by the Market/Cust. Even though this is always an educated guess, a PO who knows the pulse of users/market will be able to take that educated guess. 

3: Eng folks should have a fair idea about the Cost (Effort) of each slice. A rough guesstimate is preferred rather than chasing the illusion of an Accurate Estimate. In fact, chasing this Accurate Estimate has some seriously damaging side effects.

4: PO should have a fair idea about the Acceptance Criteria of each slice. This will nudge the PO to be outward-focused.

5: PO should have a fair idea about whether this slice is needed now, or it can wait. Again, when PO is outward-focused, s/he can easily take a call on this. 

A well-refined backlog automatically helps the team to prioritize their work as per the RoI it will produce.

A well-refined backlog will help the team to radically reduce the "waste" since the team is encouraged to build, showcase, & seek feedback on slices, rather than shipping the entire User Story. 

A well-refined backlog will save a truckload of time that would have been spent on "accurately" estimating User Stories.
Since the team anyway would not be building the User Story in its entirety, it would be meaningless to estimate a User Story in its entirety.

Agile WoW and Fluff v/s Crux

 A few days back, I happened to see a team discussing enthusiastically about all this "A"gile stuff. I was a mute spectator, but their discussion taught me a lot. 

The discussion was about team agility and related things. Everybody was very vocal and keen to share their point of view. The discussion went something like this....

A: It is not a framework; it is just a toolkit.

B: I think it is more of a mindset than a toolkit.

C: I agree. It is less of a framework or toolkit and more of a mindset and methodology.

B: Let me put it like this... it is just a set of working practices based on values.

A: To me, it appears like loosely worded principles, guiding us to a value system.

B: It is loosely worded, but it is intentionally loosely worded. 

D: What matters is a collective mindset where everyone respects everyone. Giving respect is most important.

B: Don't you think transparency is more important than respect ?

D: No. Respect is very crucial. Once you respect everyone, transparency follows.

B: OK.

C: But respect alone does not mean anything unless everyone feels psychological safety.

B: Yes, psychological safety is very important. How can we improve psychological safety?

D: I read somewhere that you can not improve anything unless you measure it.

B: Cool, how can we measure psychological safety?

A: We can invite HR folks here. They are good at all such things. They must be knowing some good consultants for this.

C: Last week I came across a consultant, & she was talking about Beyond Agile. 

A: Beyond Agile… that sounds so cool. Like Enterprise Scaling and things like that?

C: No, she said now the concept of Enterprise Scaling also has become old.  She was talking about Systems Thinking and Design Thinking and SineFine Framework or something like that.

B: Sounds very exciting.  Should we have some training on these things?

C: Yes, that will be exciting.  I think we have some training budget left, correct?  Or I can manage some more budget if required.

E :  Guys, Can you talk a bit softly?  Please ??   I am on a phone call.  I am talking to a customer to get some feedback on our last delivery.  This feedback could be important to us.

I was wondering whether Agile WoW is an acronym for “Agile Ways of Working" or "Agile Ways of Wording". 
I have been seeing organizations where Wording is winning over Working. 
Unfortunately, Fluff is winning over Crux.