trevmex's tumblings

Java Coder, JavaScripter, Rubyist, Functional Programmer, Agile Practitioner.

Solarized Dark for Slack

We use Slack at work for intra-office communication. It is a great tool, but I don’t really like the default color scheme. Fortunately, you can customize it (well at least the sidebar).

I like Solarized colors, so I set about making a Solarized Dark Sidebar Theme. Here is how you do it:

  1. Click on your name in the bottom right and open Preferences:
  2. Click on the Sidebar Theme tab on the left.
  3. Click the link on the bottom of the pane that says: Feeling adventurous? You can customize your theme and share it with others.
  4. Copy this line:
    #002B36,#073642,#268BD2,#93A1A1,#268BD2,#93A1A1,#B58900,#859900
  5. Paste the line in the box at the bottom of the dialog:
  6. Click Done.

And voila! You now have solarized Dark colors in your Slack Sidebar:

Enjoy!

 ()

#Agile2014 - Beyond Budgeting - an Agile management model for new business and people realities - the Statoil implementation journey (Notes)

Bjarte Bogsnes

You can be as agile as you want at your team level, but once your hit the enterprise level you will hit a wall. Scaling agile is hard, and scaled agile might not look a lot like agile at all.

Beyond Budgeting is a methodology to scale an organization without falling into the trap of a command-and-control culture.

Budgets are often a very bad yardstick for evaluating performance. Budgets and traditional management can be a big barrier to improving performance.

The Human Side of Enterprise teaches us that there are two theories of how people get motivated. Theory X and Theory Y tell us that people are motivated with strong control and rules (X) and people are motivated by being given power and freedom (Y).

Beyond Budgeting is all about moving your processes towards a dynamic style and your leadership towards a values-based system.

Statoil explains their system in The Statoil Book

Beyond Budgeting was pioneered by Handelsbanken back in the 1970’s

Beyond Budgeting is NOT no budgeting. You have to figure out how to allocate resources, but it is given a disproportionately large role in business.

A budget is a target, a forecast, and resource allocation. The first step is to separate budgeting into these three steps, and then focus on improving and optimizing each individually.

"Do I have the budget for this?" is the wrong question. Ask "is this really necessary?," "What is good enough?," "How much value is this creating?," "Is this within my execution framework?"

We want to move away from traditional detailed and annual budgets and towards a budget that increases autonomy and flexibility.

We want to make our decisions at the last responsible moment .

Simple is not the same as easy!

Moving towards a more dynamic mode is an attempt to simplify, but it certainly is not easy.


 ()

 ()

#Agile2014 - I don’t keep my code clean, I just turn the lights off! (Notes)

Scott Dillman

Hey you. Go read Clean Code by Uncle Bob. It is a good book!

You should care about keeping your code clean! It is important for your code to be readable, especially to other developers.

We spend 10x times READING others code, as opposed to writing code.

Messy code, a.k.a. code that is hard to understand and is poorly tested, slows us down. When you have to deal with that type of code you are much more likely to make mistakes. Ramp up time is longer when code is messy. All these factors make it hard for developers to add new business features.

Why isn’t your code clean? - “Good enough,” deadlines, “I didn’t write it!,” “I’ll clean it up later…” There are a LOT of excuses we, as developers, make for writing messy code.

"Management won’t let us do it" is NOT an excuse. If your manager is telling you how to do your work, maybe they should be doing the work.

Leave the campground cleaner than you found it.

Coding standards matter! Make sure that your team establishes a standard.

There are a lot of great refactoring tools in your IDE (IDEA and ReSharper are especially good), take some time to learn them.

Duplication is the enemy (in production code, not tests).

Delete your commented out code. Delete your unused code (you can find unused code with static code analysis).

Don’t abbr. your code

Naming matters, make names that make sense, are descriptive and understandable.

Include “good” comments. JavaDocs are good comments. Bad comments are comments in the code. Comments inside methods tend to be a code spell to extract a method.

Keep your classes small. Keep your functions small. Keep your features small. Keep your X small is generally a good rule.

 ()

#Agile2014 - Women in Agile (Notes)

Diane Zajac-Woodie, Doc Norton

Are agile practices guilty of gender bias?

We all have hidden biases that start when we are babies. The goal is to realize they exist to make them not hidden.

There is an empathy gap in our society. We underestimate the failing of people that are going through things that we have not gone through before.

We are surrounded by images of strong successful powerful men, and hyper-sexualized women.

We favor the familiar over the novel. This helps to explain why we are more uncomfortable with conflicted gender roles (e.g. a boy playing with a doll).

The media is a big part of creating this gender bias. Our society trains our girls to be either nurturing or attractive, that is the only options they have.

We learn social norms for gender very early on in our lives. At a very young age, we start to realize the patterns.

We inadvertently teach our girls that they should not be strong, smart or opinionated.

When members of a group are made aware of a negative stereotype they do worse on tests. Just the reminder that the stereotype exists affects results.

Imposer syndrome impacts about 70% to 75% of the population, and it is especially prevalent in women.

When a woman has to get up in front of people, they tend to feel much more uncomfortable taking credit for their own capabilities. To that point, they often don’t ask for their fair share of pay when the time comes as well.

Women are less liked when they don’t fit the female stereotype. This is true for both men and women.

Women are interrupted MUCH more often by men AND women in the workplace.

Men speak 75% more than women do. Having the seat at a table is NOT the same as having a voice.

We have listener bias in the sense that we feel women talk more, but that is not really true.

This bias implies that women’s opinions tend to be ignored more often.

What all this leads to is a diminishing of women in the workplace. We marginalize women, which makes us lose the power of half the population.

When all these biases combine, women get overlooked.

Women pick mentors, men pick sponsors.

Are agile teams different? Does the agile mentality make women more equal? Less? Or the same?

Stop apologizing when stating your opinion.

Using a speaking token can help give more control to team members at to stop people from interrupting each other.

When pairing, women should NOT have to always come over to a man’s desk to pair. It should be equal.

Stop interrupting women (or anyone for that matter)!

Practice gender flipping. Would you say what you are saying to a woman to a man?

Stop reminding women that they are women!

Use gender-neutral pronouns - “they” FTW!

 ()

#Agile2014 - De-scale Your Organisation! (Notes)

Olaf Lewitz

Increase trust -> Invite people to make choices -> Reduce org structure -> Repeat

"Normal" is something very very individual. We often start out life very curious and eager to learn. We then copy behaviors from others, and our definition of normal mutates.

Most of the patterns we pick up, we pick up before our birth and in our early childhood.

We should change our model of learning from “seeing” to “touching.” When you use the metaphor of touch, you get the concept of connection to others that you do not get with the metaphor of sight.

It is important to give your peers and clients a choice. A choice to stay the same, or to change.

"Fanatism is redoubling your efforts when you have forgotten your aim." - George Santayana

We often, in the agile community, forget our aim and fall into the trap of redoubling efforts around tools and processes.

"The reality is that scaling agile doesn’t work." …or at least the way we are doing it right now doesn’t work.

What do you mean by scaling? - Taking the processes that make a team succeed scale to the entire organization.

A large part of the work in a large organization is all about covering your ass (CYA). When your corporation is founded on a series of lies, it will fail.

The problem is that Agile is not a process. You cannot cut-and-paste it. Agile is about challenging the way we do the things we do and change them.

We are always trying to manage scarcity, no matter how abundant our systems are.

We humans have a fundamental conflict of wanting to be a unique individual and wanting to be accepted and loved. Because of this we invent false identities to use in groups. We sacrifice authenticity for attachment.

Most of us have dealt with skeptics and cynics. We often fall into their patterns to feel safe and belong, but this is POISON to a healthy life.

You deserve to love what you do. So, why is this so damned hard? Because, most of us accept the love we think we deserve.

Life is full of ambiguity, and ambiguity makes us, as humans, very very scared.

When you are in an environment that allows you to get empathy and compassion and you receive empathy and compassion, you have a space that values trust.

Fear is not a good state to be in.

A lot of conflict comes from fear, nothing more. This type of conflict is bad and unhealthy.

When you realize that everyone has fear, fear of rejection, fear of shame, you can start to develop empathy.

We are primed to judge ourselves and others. We we judge others and other judge us we formate a culture of shame. And shame leads to fear.

When everything you do or say is categorized as right or wrong, you shut down.

"Right, wrong, better, worse, good, bad" - These are all words that shut down others and hurt your relationships.

Look into the context of a situation, only within a context is judgment possible.

Software is not limited by very many boundaries. Your framework or system is not limiting your software.

The word “Engineering” is limiting our thinking about how we create software. It is an unneeded bounding box.

We pick operational role models that are available to us.

Management was born in slavery farms in the US south. Management was formally invented in 1911 to say that we will pay same people (managers) to think, and everyone else (the workers) to never think.

Toyota killed management in 1970 when they required all of the workers to THINK.

Micromanaging managers are not needed in software.

Is management, measurement and estimation relevant now? The answer to all three is NO. The problem is that we are so afraid to question that, we do not change.

How do we realize that amongst this fear? - We experiment, and move slowly.

Don’t throw away your models, but add mysteries to your models. Models are rigid and fixed. They don’t change, but we DO change.

The way we think about software development limits or thinking.

We value people.

Nothing is more powerful on the planet than a team with people that know what they want, and know what others on the team want.

Create a KrisMap - Create a persona of the team that defines the team by asking them who they want to be.

"Scrum takes all of the shit that is under the carpet and throws it in your face!" …you can choose to put it back, but you can also choose to clean it up.

Politics tax: the percentage of time people spend on covering their asses. - This is where most of the waste in your organization occurs.

Stay weird. Be awesome. You are a good person. You have value.