trevmex's tumblings

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

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

#Agile2014 - Leadership at Spotify (Notes)

Anders Ivarsson, Kristian Lindwall

Scaling Agile @ Spotify: Tribes, Chapters and Guilds

At Spotify they organize around squads. Squads need to be highly efficient, vision, autonomy, personal growth, learning and alignment with the business.

Each squad completely owns a part of the product completely. There are three types of squads: Feature squads, container squads and infrastructure squads.

The product owner is part of the squad, but focusing on the question: what do we do and why? How do we align with the other squads and the rest of the industry?

Product owners do four things: Work with the world, work with the product, work with the squad and work with the process.

Agile coaches are all about improving squads. They concentrate on growing high performing teams, continuous improvement, ways of working and collaborating.

All the agile coaches perform one-on-one coaching with all levels of employees.

One of the things that the coaches discovered is that the squad members had no idea what they would be working on in two weeks, so they started to do Squad Road-mapping using a drawing of a road and a bus on that road. Visualization is key.

A chapter is a group of people that are in squads (which are cross-functional teams), but are the communities of practice for the organization. For example, there can be a tester chapter, or a front-end chapter.

A chapter lead guides development practices, helps to manage tech debt and assists in hiring.

Chapter leads spend 50% of their time in a squad and 50% of their time operating as chapter leads, but it is not a hard and fast rule.

  • The first thing that happens when you create a new team is they start to form. This is also called the honeymoon phase.
  • The next phase is a phase of conflict in the team, where disagreements arise and have to be sorted through.
  • If the team makes it through conflict they start to develop trust and caring for each other. This can make a team feel like the rest of the organization is “them” vs. the team being “us.”
  • If the team can break through the us vs. them mentality, then they can gel into a high-performing team.

Only teams that have reached that final stage, can they become truly autonomous teams. Which is the true goal.

So…how do you have high-performing autonomous teams…WE DON’T KNOW…but we WILL experiment!

The problem with teams that are TOO autonomous is that they can quickly fall out of line with the vision of the organization.

Why do we have teams leading teams? - Bad manager < Dysfunctional leadership team < Good manager < Strong leadership team.

The key is growing a good leadership team. That is the crux of the problem. Once good leadership team often fall into “old boys clubs.”

Tribes are groups of squads and chapters that work together towards a greater goal. The diagram seems easy, but the reality is much more complex.

The Spotify reporting structure is NOT flat, but the lines of communication ARE flat-ish. The squads and structure of the system itself evolved over time and continues to evolve. The structure has to be fluid enough to allow for evolution.

No Friday releases!

Squad (read: team) health checks are a great way to have a general understanding on which teams in your tribe (read: organization) need help.

  • Have a really fun workplace.
  • Embrace failure. Make it safe to fail without fear.
  • Build a culture where your employees are cared for.
  • Only with those three, can you actualize high self-esteem and creative fulfillment which lead to high performing teams.

Remember, you cannot just cut-and-paste “the Spotify model.” It grows out of a greater cultural environment. You have to build culture first.


#Agile2014 - Mutation Test: A New Way to Improve Code and Test

Joseph Yao

If your body is your code base, your test code are monitors on your body telling you that you are getting sick. Mutation test is a way to help you build your tests around your code.

What is a mutant? A mutant is someone that has changed genes to make them different.

What is a mutant in your code? - It is literally any change in your code.

So, what is a mutant test? - It is literally making any change in your code, and running your tests. If your change makes the tests pass, it is a survived mutant. If the tests fail after the mutation is introduced, it is a killed mutant.

If you have tests that still pass after you change your code, or mutate your code, you have a survived mutant in your code. THAT IS BAD.

If you change the logic in your code and do NOT change your tests, it is bad news. Your goal is to kill mutants. You want your tests to fail when you change the logic in your code. If they do not, you have more tests to write.

When you remove a line of code, and then run your tests and they all pass, that means one of two things:

  1. You are missing a test
  2. The code is actually not needed (rare)

We hope that automated tests are a safety net for writing buggy code. Therefore, a mutation test is a safety net for writing buggy tests.

Common mutations to test your tests:

  • Reverse your loop exit conditions
  • change your conditionals to always true or always false (remove conditionals mutant)
  • Change your minus signs to plus signs (math mutant)
  • Change your incrementation to decrementations (increments mutant)
  • Change constants to magic numbers or strings (in-line constant mutant)
  • Change your return value of your method, null for example (return value mutation)
  • Change your code to do nothing (void method call mutant)

Check out the PokerHands Kata - Given some poker hands, find the winning hand. Use TDD.

If you mutate your code and your tests still pass, you have to ask yourself: What the hell? Do I need better tests? Is my code useless?

With TDD, you add a test, make it fail then make it pass. Well, that makes it so that you will not be able to make exhaustive tests. You need more than just TDD to have robust code and tests.

Mutation tests allow you to harden your test cases. The goal of your tests have to be to never survive any mutation tests.

Check out Pitest to help automate your mutation tests! So cool!

Mutate your code to test your test!


#Agile2014 - Best Job Ever (Notes)

Diana Larsen

Check out “The 3rd Guy” by Seth Rogen. It talks about the concept of leadership through the analogy of the guy that starts a dance party.

A leader needs first follower. One person alone it not a movement. The first follower does not make a movement. It is the third follower that really makes a movement.

Dance is a metaphor for leadership. Think about your work as a type of dance. A dance of people moving and working together.

Check out Benjamin Zander’s “The Art of Possibility.” You know when you have awakened people because you see their shining eyes.

I want you to love your work.

_Real_ work is hard, exhausting and miserable. This mentality is…horrible. There was a concept in previous generations that stated if you were not sweating and struggling, you are not doing _real_ work. Let us all hope that we have moved past this mentality.

That old mentality states that you work for the paycheck. You do not LOVE your job. You work for the weekend. …well that is a crappy idea. Why the hell would you want to spend a third of your life being crappy.

Why does agile matter? - With agile concepts, what we are really saying is that we should care about PEOPLE at work. The people matter, and when you develop your people, instead of grinding them to death.

It is hard to fall into a job that you love. You have to _create_ the job that you can fall in love with.

  1. Doing work you love to do
  2. Work with purpose
  3. Working and caring for your tribe

Doing work you love means thinking “I can’t not do this.” When you think about retiring from the work you do, and you can’t think of anything better to do with your life.

You love your job when you would rather do this job and fail than do something else.

Too many people say, “at least my job sucks less…” THAT is not work that you really love.

Edgar Shine, StrengthsFinder 2.0, etc. - On-line tools like this can help you understand yourself better.

Talk to your friends and co-workers. Share your stories with other people. By sharing your stories, you can better discover what YOU care about.

Think about what you do when your time is your own. What did you do when you could do whatever you wanted? When you were young, and did not have any other commitments. That is your true self. That is what you should seek out as a career.

The best job ever required work you love to do.

Work with purpose! - You can use the 5 whys to find the purpose of your work and why it is important to you. Start with the question: why do I do what I do? And you can keep asking yourself why until you find your REAL purpose.

It is helpful to find another person to ask the five whys to.

You spend SO much time at work that you NEED it to be a happy healthy place to be.

Teams need purpose, too!

Purpose has to be the foundation of a team. If a team doesn’t have a charter, doesn’t have an answer to the question “why?,” they can be lost. Or at least, they’re love of they’re work is lost.

It is helpful to know how _you_ are going to change the world.

Purpose inspires, focuses and motivates.

Purpose scales. When you have a purpose that connects you with others, your purpose grows.

In order to find purpose, you have to find meaning in your work. You have to know and deeply understand how your work affects other people.

Working on working together is the best team building we have ever done.

Finding the team that is your tribe is a primary goal of finding the job that you will love.

Trust is the bedrock of any team communication. You team members HAVE to trust each other. You can start by trusting first. Figure out what trustworthy people in your team do and gravitate towards that.

Start your meetings with appreciations, and end them with hopes and wishes. That can help you connect and humanize your team members.

After trust comes commitment. You have to be committed to the wellbeing of the team. And when you know that your teammates are committed to you and you are committed to them it builds trust.

Grab a chance to support your tribe. Commit to, not only your work, but your people. Commit to the other humans on your team.

From commitment comes the ability to handle conflict. Being able to get through conflict is one of the most important skills a team needs.

Only from conflict can creativity be born. And conflict cannot be bared without commitment, and without trust commitment can never be formed.

#Agile2014 - Implementing Continuous Delivery: Evolving your Architecture (Notes)

Rachel Laycock

Why do continuous delivery? - To get feedback from your customer, reduce the risk of releases and the get real project progress.

Sometimes you can’t have continuous delivery. When you have a huge and complex code base with a large amount of coders and testers.

Conway’s Law is THE LAW. You will always ship your org chart. If your org chart is large you can’t deliver fast.

You have to design your systems so that it is made of many small pieces that can be shipped independently, but work closely together.

It turns out there is a lot to continuous delivery. It is about not only architecture, it is about organizational alignment, release management, QA, CI, config management.

Architecture is stuff that is hard to change.

Architecture has to deal with inescapable truths, like: networks are always unreliable.

Software architects are like town planners. They have to think about the big systems, and let the tech leads and devs design the buildings.

Be careful not to be an ivory tower architect (also known as an enterprise architect). Fortunately, most architects today work closely with devs. YAY!

Conway’s Law dictate who is “them” vs. “us” in your organization AND your code.

Fred Brooks said that the design that occurs first is almost never the best solution.

Your organization has to be flexible enough to allow you to redesign, because YOU WILL GET IT WRONG (and that is okay).

The most common type of architecture: The Ball of Mud.

Balls of mud lead to dependency hell, and architecture failures.

Everybody gets tech debt. Just don’t be reckless about it!

We are all dealing with legacy code. If you can’t do continuous delivery on GREENFEILD code, you are doing something wrong. It is legacy code that makes the problem difficult.

The strangler pattern says that you should have a facade around your project, and slowly replace old modules with new modules one at a time. The trap there is that most folks stop halfway through, leaving you with a much worse system then you started with.

The rub is that if you don’t change the structures of your teams, you can never really restructure your architecture and have it stick.

Keep things small!

Micro-services: SOA done well. When you create small decoupled services, it is good for everybody!

Your services should have smart modules and dumb pipes.

Your services should have language-agnostic APIs: REST, AMQP, …SOAP (lulz) Regardless all your services should agree on how to shake hands.

The application shouldn’t know how you communicate with other applications.

The golden rule: Can you deploy without changing other parts of your system painlessly!

When your services live independently, if one service fails it doesn’t take down every other service… but you have to BUILD it that way!

There is a trade-off to micro-services and SOA: your systems get VERY complex across services. That is not too easy.

What helps here is standardization of communications and frameworks makes your systems easier to conceptualize.

Evolve your architecture!

When you design your architecture in the beginning of your project, the irony is that you don’t know about your system at the beginning.

  1. Delay your decisions until the last responsible moment: Don’t make all your decisions all at once, or all up front. Care about the priorities. Don’t be an enterprise architect! One of the important things to think about are what your system shouldn’t do.
  2. Architect for evolvability. Use metrics on your code. Use tools like Sonar, New Relic and the like to see where you are going wrong.
  3. Postel’s Law: “Be conservative in what you send, be liberal in what you accept.” (and validate the hell out of what you get)
  4. Architect for testability. Don’t put code in stupid spaces, like your database. Write test harnesses that act like real users.
  5. Conway’s Law. You can’t fight it. You have to make sure your org chart looks like what you want to ship.

To write a well-architected system, you really are developing well-architected people.

Job satisfaction is the number one predictor of well-archtected systems.

There is no easy way to do continuous delivery on legacy systems easily. But it is doable!


#Agile2014 - Managing Technical Debt (Notes)

Fadi Stephan

When your requirements are rigid, you start to accrue debt. When you are prohibited to change the system, it gets worse.

When the system is fragile (a.k.a. no tests), changing one thing can make the entire house of cards fall.

When the devs play whack-a-bug, a.k.a. constant bug fixing, the system suffers from death from a thousand cuts.

When a system is full of cut-and-paste changes it makes it hard to change the system as a whole.

The number one reason we add technical debt is DEADLINES.

When we over-architect solutions, we build overly complex architectures that make small changes very difficult.

Bad Design - When your code base is built on a fundamentally flawed design you are going to have a bad time. DO NOT just fix the bugs. Make the change.

Poorly skilled developers also help to add to tech debt.

Technical Debt = Principle + Interest

The interest is the pain we have when trying to work with the system as it exists. Without the interest, it is not tech debt, it is just deferred work.

Adding tech debt to a product effects the cost of changes to the product for the worse.

With no design up-front you can move faster early on, but if your product is long-lived it will hurt you in the long-run. With good design, you will be slower up-front, but be able to increase longevity.

There is no such thing as a controlled environment.

Never skip your unit tests!

Whenever you say, “I’ll go back and fix it later,” you are fooling yourself.

The key is that not all debt is bad. Sometimes debt is needed, like to buy a house or a car. When you know how much debt you are taking on and you know you can afford it, it is OK.

Reckless tech debt is when you have no time to design something (bad), inadvertent tech debt is when you just don’t know what you are doing (bad), prudent tech debt is when you know what you are doing when taking on debt (not so bad), or when you made a mistake and realize it later (not so bad).

Only short-term focused debt and long-term debt are good times of debt. Focused debt is confined to one well-defined area.

Valid reasons to take on tech debt: “You can’t move Christmas.” Some deadlines are real. (Some are not!)

In software development, bankruptcy is a total system rewrite. That is painful!

Add tech debt estimates to user stories (High/Medium/Low).

Adding tech debt to user stories allows us to better understand the prioritization of stories.

Using Sonar to evaluate the complexity of your code bases is a great way to evaluate tech debt. You can use that to attach a dollar amount to fixing tech debt. That helps you convince non-technical people that dealing with tech debt is important!

There is a Tech Debt Plugin for Sonar. How fun!

SQUALE is another tool for identifying tech debt automatically.

ROI = (Value - (Technical Debt + Cost))/(Technical Debt + Cost)

How much debt is too much debt? - When there are opportunities that pass you by because you are dealing with too much tech debt, THAT is too much debt. If you do not have the bandwidth to pivot, that is too much debt.

Pay debt with high interest first.

Code with a lot of churn should be the places you focus your efforts.

Do one thing at a time, and do it based on the skill sets of the team! And train the team on the things they do not know right now.

Tech debt is not only for code, you can attack tech debt on your PROCESSES as well!

You want the team that is producing the code addressing the tech debt. Make sure that EVERYBODY works on tech debt, not just one member of the team.

Dedicate 10% of your team’s time on tech debt. Make sure that every user story takes tech debt into account!


#Agile2014 How to improve Flow Efficiency, remove the red bricks (Notes)

HÃ¥kan Forss

Wait time is non-value adding. Required waste is non-value adding. Only actual demand adds value.

The vast majority of time spent on a non-flow efficient project is either waiting or required waste. Very little “work” is done when everybody in the project needs to be perceived as 100% utilized at all times.

The difference between resource-utilized systems and slack systems is one of focus. In a slack system, the focus is on the customer, not on utilizing people and machines.

Go read “This is Lean”

High resource efficiency makes sense in some industries, for example, having an oven in a steel mill up all the time makes sense, since it is VERY expensive to shut off the oven.

High flow efficiency makes sense in some industries as well, for example, the fire department needs to be able to respond as fast as possible, and it doesn’t matter if most of the time the fire fighters are not fighting fires.

In high resource efficiency systems there is high utilization, long lead-times, lots of work in progress, large batches and a focus on unit cost. Lots of waiting and slow to change.

In high flow efficiency systems there is low utilization, short lead-times, very little work in progress, small batches and a focus on customer delight. Very little waiting and fast to change.

What lean is: the concept that organizations should START with flow efficiency in our processes, then move towards resource efficiency. We start with slack in the system to allow for change to occur as needed and to respond fast.

When we concentrate on flow efficiency we usually see between 1-5% value added of total lead time.

Two archetypes: the busy bee and the kata guy.

The busy bee (who is always working on something) will always be context-switching to make sure that they are “being productive.”

The kata guy will have downtime, but they are always working on one thing at a time to completion.

When you organize for resource efficiency, you spend more time on required waste and wait time. The key is to follow the WORK, not follow the workers.

What is most important to your customers? How much your workers work, or how fast the work itself is completed.

Do not look at the cost of each flow unit (worker), look at the cost of the system as a whole.

Will it offend people (managers) if you have downtime? Well…yes. Some people will be offended, but when moving to a flow efficient system, take it slowly to get everyone in the system used to the idea.

Everyone should have some low-priority work to do in idle time. But the importance of being flow efficient dictates that the low-priority work can be dropped at any time to do higher priority work. The problem with resource efficient systems is that ALL the work is high-priority and it takes a long time to spin up on.

Effort estimation is flawed!

Estimating the amount of effort a piece of work will take almost always does NOT include an estimation of wait time, making those estimations not useful at all when trying to predict when a piece of work will be completed.

Estimating work completion by examining historical data and probabilistic forecasting is much more accurate for understanding when a piece of work will be completed.

How do you improve flow efficiency? - Focus on reducing wait time first! Then focus on reducing required waste.

Yes, but…how do you really do it? It is really hard to take a resource efficient system and convert it to a flow efficient system. The solution is to drop resource efficiency.

"Don’t play cone soccer" - You want to not be focused on "just your job," you have to be able to see the entire system. You want to be able to visualize your end-to-end flow in your systems to see WHAT the job is.

Move from large batches with low frequency to small batches with high efficiency. That means smaller features. Slice first, independent of business value, even before thinking about MVPs. Deliver continuously, or at least more often. Shipping is king.

Avoid projects - project work implies large batch work. Units of work need to be smaller to move faster.

Blockers and Impediments are your Gold and Gems for improving flow efficiency.

Little’s law FTW!

When you plan for less than 100% utilization, you can respond to emergencies better. You also get the side effect of getting time to improve the system in that down time as well.

Driving down work in progress is good for the overall flow of a system. This will help to uncover process improvement changes that need to be done.

Every process has a bottleneck!

You can never go faster than your worst bottleneck. Therefore, if you maximize the work for non-bottlenecked units, you will start to pool up work AT the bottleneck. So, it is ideal to keep all units running at the level of the bottleneck to ensure constant flow.

But how do you do this? - WIP limits. Limiting the work in progress applies back pressure on the higher work-producing units.

So, just make up a WIP limit and experiment. Change the WIP limit every sprint and see how it works. Eventually you will see where the WIP limit will be looking at the data.

The King’s Formula - when resource efficiency increases in a low variability lead time rise, but in a high variability system, lead time rise much faster.

Try to avoid swarming on work in an ad-hoc process.

Unnecessary process variability should be removed. Some types are needed, others are not, like swarming on work.

Swarming on work means having everyone on a team stop what they are doing to solve a problem.

"A bad system will beat a good person every time" - W. Edwards Deming

#Agile2014 Curing Featuritis (Notes)

Todd Olson

We want simplicity, not complexity in most of the products we use. Adding more features often do not result in extra sales.

When we cramp features into our products, we start to make them feel stupid if they cannot figure out how to get things done in your product.

We need to change the way we think about success. Value is greater than throughput. If you ship 20 bad features, those are still bad features…

When you measure people on throughput, you get a lot of features, but not a lot of value.

When you ask the customer if they want feature A or feature B, they will say they want both. Customers are no good at speculating the future use of your system.

Don’t try to predict. Experiment.

Build something and give it to your customers. Don’t try to guess or ask what they want, instead have your customers play with your experiments. Evolve the successes and dump the failures.

Ask the customers where the real pain is. Start with something and iterate with the customer feedback in mind.

Build slack to incorporate learning. Don’t make your schedules so tight that you cannot deal with the feedback you get from the customers.

We often confuse not knowing about a feature vs. a feature not being good vs. a feature not being useful. You can have a useful feature with a too-high barrier, or a good feature that isn’t useful. Or maybe the customers just don’t know about a feature existing at all.

Making sure people know about your features are almost more important than the features themselves. Your customers full-time job is PROBABLY NOT using your software, so pointing features out to the customers is a good thing.

"Shouldn’t your UI be discoverable?" - well yes, but the average US attention span is about 5 seconds. That is very short. When you make complex features your customers are less interested in complex systems.

Guide your customers to collect better data. If your goal is making the perfect UI, you will constantly be searching. there is no perfect UI. You just have to continue to educate.

Practice hallway usability testing. Your co-workers are a great sounding board.

Testing is a fantastic way to try out new UIs.

If we can prove that customers know about a feature AND that they think it is a good feature, but they are still not using it, it might just not be useful. That feature should be de-prioritized.

You have to understand “what is better” for your customers and try to avoid vanity metrics. If your metrics do not provide value back to the customer, those are useless metrics.

Questions to ask when thinking about what to measure

  • What are the goal(s) of your software?
  • What problems are you solving?
  • How are you providing value to your customers?

Looking at WHO is using a feature matters. If you have a feature that is only used once a month, but the one person that uses it had the buying power in your customer’s company. That less-used feature becomes very important.

Feature funnels - This is the concept of trying to convert people to use a feature to get to an outcome they desire. This works exactly the same as marketing funnels. We can analyze what customers do and where they fall off when trying to use a feature.

REMOVE FEATURES! Less features are better. You don’t have to remove the feature, but you can hide it. The more buttons you have the less your customers will use your products.

Take things away from customers. Making clean UIs with less features makes it more likely that customers will use your products. Some of your customers will complain, but that is OK.

Hide the features that you have to have JUST to win deals. If your sales people need you to implement something stupid to win an elephant, do it, but make it hard to get to. That is A-OK.

Prefer to remove features. If customers complain loudly, you can always add them back, but make sure your customers care in the first place.

Never assume that your customers understand your system.

Remember the goal is value. Experiment. Experiment. Experiment. Do it now. Your product will be better for it.


#Agile2014 Cost of Delay workshop (Notes)

Joshua Arnold, Ozlem Yuce

This workshop ran through exercises from the Cost of Delay concepts on the Black Swan Farming website. Good stuff, worth checking out!