Building the right thing?
This article of mine might be interesting for you
Interesting thoughts about Feature Toggling
Idea one: separate feature launches from
- You can deploy the code for a feature long before you launch it and nobody will know
- You can completely rewrite your infrastructure and keep the UI the same and nobody will know
Idea two: run multiple versions of your code at
You can repeatedly switch between two backend systems and keep the UI the same and nobody will know
You can deploy a non-user facing change to only a
small percentage of servers and nobody will know
You can offer different user interfaces
to different users and nobody will know
Manage the different versions within your application
—> Branch in code
Three types of Feature Flags:
1. Development on user facing features
2. Development on infrastructure
From: “Always ship trunk” slidedeck by Paul Hammond
I just came across this screenshot. I really like this way to structure tests.
What do you think? Would that be helpful in your team?
Make sure to follow Kevlin!
Lots of things have been said about SAFe. These 2 things bother me the most (via @henrikber)
- In a complex situation the solution needs to emerge through inspect and adapt.
- People that are doing the work know best how the work should be done
SAFe violates these 2 arguments
Article from David Anderson that highlights those 2 arguments.
The Kanban Method will coexist with SAFe in the marketplace. People will choose between a modern 21st Century approach to complex situations or a familiar 20th Century approach to change and their software engineering processes.
Check out http://scenarioo.org by @zuehlke_group
"Automated documentation of applications through UI tests"
Great 10 tips. I would add 1
- Skip the “Agenda” slide
- Make “Tell Stories” #2 of priorities
- Pass the Trapdoor test
One minute in your talk, a trapdoor opens and you have another 1 minute left
1 thing to remember?
- Make em laugh
People don’t remember what you say, but how you made them feel
- Paint Pictures
- Show & Tell
- Skip the “About Us”
- Shorter wins… Always
- Open body language
- Why you?
Nobody else can tell this story better than me
- Share your weakness
- Tell Stories
Great story behind this slide deck from Alberto Brandolini (Zio Brando)
Great article about the “Agile Mindset”
Make sure to checkout this diagram!!!
Great article about work and life at Google and how to balance it.
Get started with
…for any organization, there are four steps you can take to start your own exploration and move from hunches to science:
- Ask yourself what your most pressing people issues are. Retention? Innovation? Efficiency? Or better yet, ask your people what those issues are.
- Survey your people about how they think they are doing on those most pressing issues, and what they would do to improve.
- Tell your people what you learned. If it’s about the company, they’ll have ideas to improve it. If it’s about themselves – like our gDNA work – they’ll be grateful.
- Run experiments based on what your people tell you. Take two groups with the same problem, and try to fix it for just one. Most companies roll out change after change, and never really know why something worked, or if it did at all. By comparing between the groups, you’ll be able to learn what works and what doesn’t.
And in 100 years we can all compare notes.
Great article about story mapping
Taiichi Ohno on fooling westerners:
“I’m proud to be Japanese and I wanted my country to succeed. I believed my system was a way that could help us become a modern industrial nation. That is why I had no problem with sharing it with other Japanese companies, even my biggest competitors. But I was very, very concerned that you Americans and Europeans would understand what we are doing, copy it, and defeat us in the marketplace.”
He went on to say that when Americans and Europeans came to visit Toyota that he did his best *to confuse them* as to why Toyota was so successful.
“I explained it by talking about techniques, like quicker machine setups, reduction of the seven wastes (*muda*) and other techniques with Japanese names like *kanban* and *kaizen*.
I did my best to *prevent the visitors from fully grasping* our overall approach. Today, I am ready to be open and explain fully what we did. We are now strong enough to deal with any competition.”
I am still amazed by the greatness of this man!
The problem with TDD I think is:
"TDD is harder to practice and TDD is harder to get ‘right’ than other tools."
Not saying that your favourite tool is an easy tool to use ;-)
- TDD is a combination of: Thinking, Coding, Testing, Refactoring.
Let alone “Testing”, lots of people (including myself) get already the “Thinking” wrong.
Here an example of 2010 when I got the Thinking wrong
- Additionally to those 4 there are lots of other skills needed: Mocking, CleanCode, Emergent Architecture, ATDD, …
BTW: Did I say that Refactoring is very hard?
My video interview about: Clean Code, Testing and Continuous Improvement
If you havent been on a internet-less island you probably heard about this blog and the google hangout conversation.
Here are my thoughts to that
Completely unrelated to TDD/UnitTesting I really enjoyed 2 sentences from the hangout:
"In order to understand/define something, I like to understand how it came about"
"If an idea is obviously bad, find a cheap way to try it."
"If an idea is good, someone else has tried it before"
What are the experiences of a large group in a tier-one financial services firm adopting Large-Scale Scrum (LeSS)?
Things I wanted to highlight: