Feed #124

Agile

The 11 habits of highly effective Agile delivery teams

The Ultimate Scrum Reference Card

CSS

Initial, Inherit, Unset, and Revert

Flexbox Patterns

Why do Chinese websites look so busy?

Engineering culture

Bugs and cracks

What Starbucks Can Teach Us About Software Scalability

Shit Rolls Downhill - Brave New Geek

InfoQ eMag: Designing Your Culture
Some interesting things:

Sahota: “Bottom-up change is a myth.
Top-down is where it’s at. In every single client I have worked with, the bottleneck is the leader. For real change, leaders must lead. It starts with their behaviour. This creates an upper bound on what is possible.”

1 - Awareness: A culture model creates a language for talking about culture and creates an awareness of where we are now.
2 - Desire: Case studies help people understand what is possible so they dream of a better future culture.
3 - Ability: We use techniques such as reverse-seniority reporting, leading through context, delegation poker, etc.

Why is it so difficult for organizations to change their command-and-control culture into a culture that supports agile?
PP, PG, and NN: “This is a great question. The data shows that cultures of trust and ownership are highly productive (check out the work done by the Great Place to Work Institute). Most leaders don’t know how to create a culture of trust and ownership. All they know is command and control. It is the way we were raised and often the behavior that got us into senior positions. In some cases, it is how we were rewarded: by being the ones who knew everything and could tell everyone else exactly how to do their jobs.”

PP, PG, and NN: We believe and have found that great things happen when there is a culture of trust and ownership.

What happens when a leader trusts a team that is not capable yet of taking ownership?
(see answer in document)

How can leaders address situations where teams might fail?
(see answer in document)

KrisMap looks intersting.
Also let’s take a look at Laloux culture model, there is also a video.


The Myth of the Software Rewrite
Interesting but what’s the cost of “lots of automated tests and then work on refactoring”. Wouldn’t be cheaper/faster to just start from scratch ?
Follow-up: Software Rewrite: The Chase
I agree, the “awful chase” is a good point. This is why it is critical, in case you chose a rewrite, to be very clear about what you’re trying to achieve, and what you won’t do straight away. I disagree regarding the “path [that] leads to code of the same maintainability”. Teams have learn new methodologies and practices since the original code base. It is likely code will be of better quality. But developers will have to be carreful about that too.


Software engineering

Saving 13 Million Computational Minutes per Day with Flame Graphs - The Netflix Tech Blog

Have Software Developers Given Up?

The 80% rule

How Etsy Formats Currency

JavaScript MVVM — You’re (Probably) Doing it Wrong

Fragile Automation