Sample customer journey map

Sample customer journey map

Prager's Law - Virtuous improvement cycle

Courtesy: Daniel Prager, PhD, Agile-Lean Consultant

https://www.linkedin.com/feed/update/activity:6499809347621740544/

PO Maturity Levels

Source DZone

PI Planning Refresher

Courtesy Theburndown.com

Portfolio Level

Strategic Themes --> Epics

Epic definition & refinement
Portfolio Backlog construction

Program Level

Epics --> Features

Feature definition & refinement
Program backlog construction

Team Level

Features --> User Stories

PI Execution

SAFe 4 PI Planning Step by Step

Story Mapping

Ron Jeffries on the need for Technical Practice in Agile...

• I was going to write this out, which I don’t usually do with my tweet storms, and decided not to. So I have no idea where we are going.
• Topic is pressure on developers, and what they can do about it.
• It is common for developers to be put under pressure to deliver more, faster. I would say it is endemic. This pressure is invariably a bad idea. I believe it was Ward Cunningham who said that warming programmers’ feet did not make them go faster.
• The usual result of pressure is that developers invisibly turn down the quality dials, perhaps delivering raw code faster, but certainly delivering defects faster as well. 
• Adding pressure to programmers is a trick that never works.
• Now comes Agile. Agile asks us to deliver working software frequently, every couple of weeks or sooner. I believe the main value of this is that it focuses the customer-developer conversation on reality rather than fantasy, enabling more productive collaboration.
• However, to do this trick of continuously delivering working software, developers need to learn new things, things not typically taught in school and not typically learned on the ordinary non-Agile job.
• If you’re delivering continuously, your design must grow and evolve: you surely didn’t have it figured out in weeks one and two. Design evolution is done via /Refactoring/, a discipline of improving code’s design without losing functionality or breaking things.
• Refactoring is rarely, if ever, taught in schools. It takes time to get good at it. If you’re already in some incremental, iterative Agile effort, and you don’t know refactoring, your design is falling behind every day.
• Since refactoring needs not to break things, and since the design may need improvement anywhere, a comprehensive suite of tests is a necessary — if not sufficient — safety net for refactoring.
• This, too, must be done incrementally. We call this TDD and ATDD among other names.
• I could go on. The point is that to perform well in an Agile frequent-delivery situation, developers need to know a suite of capabilities that they’ll not have learned in school and that they’ll not have learned in pre-Agile situations.
• Most developers do not know these things at all. They’ve had no opportunity to learn them. That’s just the way of things.
• So here come old Agile, he come groovin up slowly, he got expectations he one holy terror ...
• He say “Come together, right now, and code for me”.
• And they don’t know how. They simply can’t do it. So old Agile, he’s pretty new to the game, what does he do? He reverts to what he knows, and puts pressure on the team.
• It says right here in the Agile playbook that the team /will/ deliver working software every week or two. Will, do you hear me? Read my lips, get me that working software or I’ll know the reason why.
• Yeah, well, we do know the reason why: they don’t know how.
• Does this happen every time? Of course not. Nothing interesting happens all the time. But it happens often, too often. And it’s good for no one.
• It’s not good for the project: it goes slower than it might, and then slower still.
• It’s not good for “Agile”: it doesn’t deliver what Agile promises, reducing Agile’s ability to do good things.
• It’s certainly not good for developers: it puts them under more pressure than before Agile.
• To me, there’s only one way out of this loop, and that is for developers to somehow learn the things they need to know. Ideally, companies would help them. Ideally, organizations like the Scrum Alliance would help them.
• Ideally, people would live in peace and harmony.
• Ideally seems not to happen as often as it might.
• Still, the only way out that I see is for developers to learn these skills. They may have to do it largely on their own. There are materials out there, often pretty affordable. We need to help them find those.
• It would be good if there were more support for the creation of those materials, a consortium or something, some group to fund the creation of what’s needed. 
• It wouldn’t be just charity, not at all. Why not?
• There are around a million Scrum Masters in the world. That suggest that there must be about five million developers who need this information. Ten bucks a month from five million people is enough money to go around between creators and backers
• I don’t know how to make that happen. I’m quite sure it’s needed.
• Agile cannot thrive without technical practice. Developers mostly don’t know the practices. For Agile to thrive, we need to help developers learn what they need to know.

Scrum Impediments

Impediments in Agile are a form of waste. 

• The scrum master's responsibility is to identify the impediments and help remove. 
• SM gets into picture when the impediments are beyond the ability of the team.
• Everyone within the team identifies impediments.

Examples of impediments (leanagiletraining.com):

1. Blockers of user stories

2. People issues

3. Unskilled resources in team

4. Technical issues

5. Lack of knowledge

6. Operational issues

7. Managerial / organizational issues

8. Process issues

9. Disruptions

10. Business / customer issues

11. Etc.

Value Stream Mapping (VSM) - How To

Value Stream Map: The Graphical Visualization of the Value Stream is called the Value Stream Map.

It shows the diagram of all the major steps involved in delivery a product or service from supplier to customer. 

How is it different from a Process Map?

It is a High-level process map, however with additional customer data, process data, information flows to get sense of where a value is added and where there is a waste.

It is used to:

1. Map flow
2. Understand dependencies
3. Identify and Understand sources of waste
4. Remove waste
5. Re-create an efficient process

* If you want to view a certain step in detail, you can then create a detailed process map for that particular process block.

What if you don't have hard data?

• Walk the process
• Observe
• Obtain estimates from people
• Get collective estimates of project team

Defining BDD in a single Tweet (Dan North)

Using examples at multiple levels to create a SHARED UNDERSTANDING and SURFACE UNCERTAINTY to deliver software that matters.

1. Stakeholder + PO talk about business needs.
2. PO, Dev, and and tester collaborate around requirements
3. Agreed upon requirements are defined as english formatted scenarios (Given, when then...).
4. Developer uses scenarios for automated tests
5. Tester also uses scenarios as basis for their tests.
6. Automated tests report back against features and scenarios

VSM Limitations

Limitations of VSM:

1. Finding deficiencies and getting rid of them is not the way for improving performance of a system.

2.The definition of what a value stream is, is itself fuzzy:

a. It doesn't capture all specific actions

b. VSM should be typically applied to product, but often gets applied to product families with little guidance about what constitutes those families.

c. VSM is cumbersome when product variety is high and volume is low (Media team has more than 20 product / product families; and we are looking at only the 10 important activities in each stream, not looking at all the activities in each stream).

2001 Snowbird Resort Utah Original Pictures

Emphasis on "Being Done" in Agile - 90% Syndrome (Mike Cohn)

Courtesy - Mike Cohn

• We often fail to gauge the magnitude of an effort until we are well into that effort. 
• For this reason, conventional estimations are not quite accurate.
• Ask a developer how "Done" something is and you get to hear "90% complete". A week later ask him again, and you get the same reply "almost 90% complete". This happens because the developer has gauged the scope of work incorrectly. He fails to anticipate all that is needed to complete the work.
• The 90% syndrome means the developer is certainly making progress, however is progressing at exactly the same rate as his understanding of the problem's scope.

Example

=======

Microsoft's development of MS Word began in September 1984 and was estimated to take 12 months. Nine months later, the team realized it will take another 13 months to complete, and an year later the team estimated 11 months. 

For three years, MS Word was estimated to be an year away. The product was ultimately shipped 5 years and 3 months later.