Continuous Improvement Models over the Years

DEEP Agile

Key Agile Success Factors (Mitch Lacey)

Key Agile success factors:

1. Demand technical excellence: make XP practices mandatory. Neglecting these is one of the reasons why teams are not able to produce shippable code at end of sprints.
1. Sustainable pace
2. Collective code ownership
3. Pair programming
4. Test driven development
5. Continuous integration
6. Coding standards
7. Refactoring
2. Promote individual change and lead organisational change
1. Individual response to change is not enough
2. Organisation should also be able to respond to change. Institutional transformation is essential. 
3. Make sure management is educated, trained, on board and participating in agile/ scrum implementation
3. Organise knowledge and improve learning
4. Maximise value creation across the entire process

Starting Agile Journey

1. Start without calling yourself Agile.
2. Don't buy into standard stuff practised elsewhere and adopting in your workplace -- Spotify, Netflix, etc. have a context; Simply monkeying them in your organisation won't make you agile.
3. Grow your Agile organically.
4. Understand the context of your organisation, the whys and wherefores and why exactly you want to go Agile.
5. Implement a holistic agile framework --
1. Make your entire organisation agile
2. Consciously and diligently remove organisational impediments to agility
3. Restructure your teams -- self organising, self sufficient teams, fix procurement, fix operations teams, fix support teams, etc.
4. Fix your funding model
5. Fix your procurement
6. Fix your portfolio management; make it lean
7. Define agile framework pertinent to your org.
8. Grow home capability; if you must hire, hire people including agile ones in permanent roles.
9. Kick out consultants, you don't need them. 
10. Coaches are good, however ensure you have only very senior folks who have implemented it in other organisations. Get them into the organisation fold instead of contracting. 
11. Avoid remote work for Agile coaching. It won't work.
12. Likewise as far as possible avoid remote work even for day to day Agile.
13. Remove the stupid concept of hot desks. It isn't working anymore, and for Agile it definitely doesn't. Instead have a dedicated room / space for the teams. 
14. Reduce vendor dependency. Bring down the vendor count.
15. Don't allow HR to lead the Agile transformation. 
16. 
    

Funding in Agile

Traffic Lights vs. Roundabouts - Agile - Bjarte Bogsnes

• To get good performance in traffic -- safe and good flow of work
• Traffic Lights: Those managing are those programming the lights. Based on some historical data, and some forecasts. Not entirely fresh information. No authority to act on information (traffic lights). Much easier. Rules based system. 
• Roundabouts: Alternative. Drivers are in control. Based on fresh, here and now information. Proven that roundabouts is more efficient - because access to fresh information. Difficult to drive in because it requires more competence. Value sets required to manoeuvre in roundabouts. We are much more dependent on the value system of other drivers. We have to interact with people in a very different way. It is a self-regulating management model. 

Flow efficiency

Scrum retrospectives - focus on what?

Focus on improving desirable outcomes, not on playing by its rules. Don't focus on how you can improve the implementation of scrum, rather focus on the value delivery. 

Influencing agility

Problem with Gartner's "Combine Design Thinking, Lean and Agile" Diagram

1. Problem Solving happens before Execution, thus indicating a Big Upfront Planning. 
2. Each sub process is indicative of a functional silo with handover between them

Overall, this appears Waterfallish.

Scrum vs. Kanban (Henrik Kniberg)

Scrum and Kanban Summary

=================

Scrum

====

1. Split your organization into small, cross functional, self organizing teams.
2. Split your work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item.
3. Split time into short fixed-length iterations (1-4 weeks) with potentially shippable code demonstrated after each iteration. 
4. Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration. 
5. Optimize the process by having a retro after each iteration.

Kanban

=====

1. Visualize the workflow. 
1. Split the work into pieces, write each item on a card and put them on a wall. 
2. Use named columns to illustrate where each item is in the workflow.
2. Limit WIP. Assign explicit limits to how many items may be in progress at each workflow state.
3. Measure lead time -- average time to complete one item, sometimes called cycle time. Optimize the process to make lead time as small and predictable as possible.

Scrum vs. Kanban

==========

Three Amigos

PO Maturity Levels

Source DZone

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.

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).

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. 

NBUFD for Agile Change

• The concept of No Big Up Front Design is applicable to Agile change management (Design) as well. 

• One view is to have every piece of organizational change in place before the transformation can be initiated / continued. Another and more rational view is to work along the way in each initiative, identify the non value adds and remove them.

• The intent to deploy agile coaches is to ensure changes happen across teams that will meaningfully contribute to and transform the organization in their quest for enterprise agility. The notion along this journey that having a x number of coaches, each with their own view of what Agility means will lead to "Agile Fragmentation" may be ill-conceived because the intent is not to have a centralized control over the experience, rather it is to organically grow the abilities of team and in this the agile coaches support and help in clearing the obstacles via NVA removals.

Importance of various personality traits in an Agile Team - Mckinsey

Fractals and Agile

Fractalfoundation.org

A fractal is a never-ending pattern. Fractals are infinitely complex patterns that are self-similar across different scales. They are created by repeating a simple process over and over in an ongoing feedback loop. Driven by recursion, fractals are images of dynamic systems – the pictures of Chaos. Geometrically, they exist in between our familiar dimensions. Fractal patterns are extremely familiar, since nature is full of fractals. For instance: trees, rivers, coastlines, mountains, clouds, seashells, hurricanes, etc. Abstract fractals – such as the Mandelbrot Set – can be generated by a computer calculating a simple equation over and over.

Mathematical fractals are generated by applying a feedback loop to a system.

Z = Z2 + C

Tathagat Varma. 

• Mathematical fractals unlike natural fractals can keep self repeating indefinitely. 
• They are the best examples of - Simplicity leads to complexity.
• They appear complex, but are essentially repeating a basic shape repeatedly, infinitely.
• Fractals are nature's mechanism to replicate organization without exhibiting a central control. 
• Agility could be modeled as a fractal behaviour of software teams to ensure the core focus on agility loop is always retained, despite scale.
• In practice, the notion of agility at each level would undergo changes but the core behavior of agility loop gets preserved, and allows agility to grow scale free!

How Agile relates to Fractals
=====================