Jazoon 2013 – How To Do Kick-Ass Software Development

24. October, 2013

Jazoon 2013 badgeOne of the most important aspects of agile is to notice your problems and solve them. How? A good strategy is to look what others did. In “How To Do Kick-Ass Software Development,” Sven Peters shares his experience with “Kick-Ass Software Development at Atlassian” (slides on slideshare, video on vimeo). Yes, he have the talk wearing the “Kick-Ass Super Hero Costume“.

A short refresher what agile aims to be (slide 12):

  • better software
  • less overhead
  • faster development
  • happy customer
  • happy developers

This only works when you continuously improve. Legacy teams, can you hear me?

Kick-Ass Software

But before we can start: How do we know we build the right thing? Bad example: The Microsoft Kin. Never heard of it? They sunk about $1 billion in the project. Makes you wonder how you could miss it, right? (slide 25)

Better solution: Fake it. IBM made extensive experiments with a state-of-the-art speech-to-text system before starting development. How did they do it? They hired an extremely fast typist who remote-controlled word. Cost? Negligible. Result? Text-to-speech won’t sell – people can’t edit the text fast enough using words, they are hoarse after eight hours and the whole thing really breaks down in an open office space. (slide 27)

Use paper prototypes. Something geeks eventually forget: You can drag a piece of paper over a (wooden) desktop just like a window over a screen. (slide 28)

Quick and easy feedback: Easy to find, simple, fast to submit (slide 32). Customers love it! But remember to protect your developers. Gmail uses the “Sh*t umbrella” (slide 38). But not everyone is Google. Put each developer into a support seat once in a while. Not only can they solve problems much more quickly, they also learn to look at their work from the customer perspective (slide 42).

Kick-Ass Team

In most companies, there are way more developers than testers. Atlassian has a ratio of about 13:1. This creates bottlenecks and issues with accountability and scalability (slide 46).

Solutions: Dev X tests features of other devs. (slide 49)

Use “DoTing” – Developers on Test (slides 50 -56):

  • Give developers the same training QA receives
  • Pair testers with devs
  • “Blitz Test” – Once in a while, invite everyone in the company to try the product
  • Use test recipes
  • Split sessions (1 dev and 1 QA test the same feature independently)
  • Bug Hunter (have someone try really hard to break the app)

Remember “Quality is everybody’s responsibility.” (slide 57)

At the Jazoon, the slides about design were skipped due to time constraints.

Again: Department barriers slow you down. Work together as one team! Keep improving! (slide 69, see also: WIKISPEED in “Test First Saves The World”)

Kick-Ass Collaboration

The lonesome cowboy coder is a relic but teams always mean trouble. Interesting video of a heavy-traffic crossing without signals on slide 73. “Traffic Rules protect us from accidents” -> “Development Rules are protecting us from making mistakes”. Like we need a concurrency library in our preferred language, we need a “Fast + Simple Workflow For Parallel Coding.” Otherwise we will be slow and some people will enable their “god mode.” (slide 77)

DVCS make this simple. Create a branch for every task (slide 78). They should have short lives (2 days).

“Pull Requests can improve your code quality” (slide 80). This helps to spread knowledge. But keep an eye on the blame game!

Everyone in the same room would be great but it’s not always possible: People travel. You really want to pull some experts two weeks out of his family? (slide 85) Ask yourself: “Where do I work best?” The answer often is: It depends (slide 86). Make sure people can stay in the zone when they have to.

Make sure you can communicate effectively (slide 87). Emails look great (slide 88) but they cause problems (slide 90). Try chat. Invent your own Portal Device.

Most importantly: Remove friction!

Kick-Ass Automation

Developers automate everything for everyone else. Spend some time each week to automate a menial/manual task for them (slide 101).

4 steps to tame monster builds (slide 104-110):

  1. Instead of having everyone build everything, pass the artifact
  2. Run your tests in parallel. They are independent of each other as they should be, right?
  3. Have a build strategy. How often do you build what part?
  4. Make your stats visible. Use wallboards, information rediators.

Automatically disable flacky tests (113). Use SonarQube and similar tools to detect problematic code. Use Freud to find your own anti-patterns (115).


Remember managers are also humans (123).

Share stories of success and failure (124).

Remember: To be awesome, you have to step out of your comfort zone (126)

Jazoon 2013 – User Storytelling: The Lost Art of User Stories

24. October, 2013

Jazoon 2013 badgeIn her talk “User Storytelling: The Lost Art of User Stories“, Ulrika Park (blog, slides on slideshare) made a case to become aware of the spreading practice of “snapshot user stories.” As an example compare “give warrant to use the bonus” (slide 14)  to slide 16:

Elisabeth sees in the MyStore newsletter that she this month has got 12€ in bonus and that she has a total of 16,7€ in bonus on her club card.
E’s husband Claes go to the store. He has a club card too. “You can probably pay with your card” says E.

Claes shops. When he will pays, no bonus is withdrawn from the sum at the cashier.
So he pays the whole sum and gets home. “Strange why can’t I pay with the bonus, how does this work”

E already has a registered user on mystore.se Sometimes she logs in to see her credit card balance.

E logs in and see the saldo “16,7€”. She clicks the balance and enters “events page”

There she sees that she’s bonus owner and that her co-bonuxcollector is Claes.

She gets information that she needs to sign warrant for him and choose the option to print a form.

She choose to print the form, checks Claes, signs the form and goes to the mailbox the day after.

2 weeks later she gets a letter from MyStore that confirms the warrant is verified. A week later Claes goes shopping. This time, the bonus is withdrawn from the total buy.

I think even without the highlighted parts, you can quickly see that the whole story is much richer than the “more efficient snapshots.” Moreover, it helped to expose some critical problems that no one noticed before:

  • Hidden expectations (user must already be registered)
  • This process takes four weeks! Do we really want that?
  • It helps more people. QA will be able to derive test cases from this. Developers will know much better what is expected from them. BAs will know which questions to ask.
  • It’s pretty easy to follow it, even if you’re not a software developer. Remember that these stories were meant as a means to communicate better with customer and managers?

A good story has these properties:

  • A hero
  • A platform
  • An enemy or challenge
  • Emotions (“how does this work?”)
  • Allies (cashier, web site)
  • A mission to accomplish

Everything is held together by a logical sequence of events.

Related articles:

Software Development Costs: Bugfixing

21. July, 2012

(Second part of three; first part is here)

Software has bugsthere simply is no way to avoid them. If you can’t avoid them, maybe you can handle them efficiently? Yes, you can:

As you can see, the cost of fixing bugs rises as time passes. Why is that?

There are many reasons:

  • When you find a bug a couple of minutes after you created it, you probably still have all the information in your head that is necessary to understand and fix it.
  • If you just created the bug, no code depends on it. As soon as you start writing unit tests and more code, fixing becomes more expensive because you start to have dependencies.
  • People might have gotten used to the bug and developed workarounds. If you fix the bug, this will have an impact on them.
  • A bug found in production is likely to be reported by a customer. Customers can’t see inside of your software, so extra effort will have to be spent to determine what the actual problem is. Google for “how to report bugs
  • When a bug is discovered at the customer, it might trigger meetings and scapegoat hunting. Think of it this way: A 1 hour 8 person meeting costs about $1’000. And no bug was ever fixed in a meeting.
  • Some bugs escalate to the top-level management. Imagine for a moment what it would mean for you if their CEO called your CEO to complain about a problem you caused.
  • Bugs might break expensive things, harm or even kill people or start World War 3.

This also explains why unit testing is so much more efficient to QA testing for many kinds of bugs: It simply catches them before they spread their bad influence.

So fix your bugs early, OK?

Related articles:

Software Development Costs

14. July, 2012

I’ve prepared a small presentation to give an overview of software development costs.

This diagram describes the costs/gain per feature.

Complexity Curve

The most simple curve, complexity, is easy to understand: Costs go way up as you add features. Adding another feature to an already complex product is way more expensive than adding the first feature to a non-existing product.

Bugs in Final Product

The number of bugs in the final product is harder to understand. As you add features, you also add bugs. The number of bugs per kLOC is an individual constant. We always make the same mistakes and we the number of bugs we create per kLOC is pretty stable, too. The number is different for each person but every developer has their own number and that number doesn’t change much unless external circumstances change dramatically. In fact if you create statistics about bugs found per team member, you can tell how many new bugs there will be after he added N lines of code (see “They Write the Right Stuff“).

That means every product has bugs. If the project isn’t a complete disaster, then the team will have found a way to cope with these. Or to put it another way: If the number of bugs grows too fast, the project will either be canceled or drastic measures will be taken to reduce the flaws again.

This is what the curve means: In the beginning, there will be few bugs because there are only a few lines of code. Remember: number of bugs = lines of code * individual constants. Each line that you don’t write reduces the number of defects.

As time passes, the number of bugs will grow just because lines of code are written. Eventually, that number will either explode or the team will find a way to keep the number in check.

Gain per Feature a.k. ROI

The last curve is for the marketing department. It describes the usefulness of the product for a customer as features are added. A product without features (a.k.a vaporware) is not very useful for a customer. The first feature will be the most useful … or it should be: Why are you wasting your and your customer’s time with features that aren’t the most useful?

But as you add features – and trust me, customers and marketing will try to get as many as they can get – the usefulness doesn’t grow as much anymore. Each feature comes with the cost of complexity: There will be more menu items, dialogs and buttons. The manual will get bigger. The customer will need to remember more to use every feature. That starts with remembering that a feature even exists and goes on with remembering how to use it efficiently.

At the same time, you started with adding the most useful features, right? So additional features, by definition, can’t be as useful as the first ones.

And eventually, the product will contain more features than any single customer cares about. New features will be added for new customers that existing customers don’t care about or that even get in their way (when menu items move around, for example).

This is one reason why everyone feels that Google or Apple products are so easy to use: They work really, really hard to reduce the number of features in their products.

Next week: Bug fixing costs.


Jazoon 2012: Agile Chartering: Energize Every Project Liftoff

4. July, 2012

In her talk “Agile Chartering: Energize Every Project Liftoff,” Diana Larsen presented approaches how you can set up your agile projects. Why is that important? When a rocket is launched into space, a lot of preparation happens to make sure the move from ground to space is smooth and successful.

Software projects often ignore this important step.

For example, it would make sense to check the commitment of team members. Commitment comes in two flavors:

  1. Yes, I want to do this
  2. … with the other members of my team

Another important question that each team member will ponder is WIIFM – What’s in it for me? Answers to these questions will have a huge impact on the success of a project.

Regulations are important but don’t forget that the human brain has a limited capacity. If you want them to follow the rules, you must restrict them to five tops.

Member Shields

Another strategy is to create “member shields” where each member writes their name on top of a shield like shape. The shield is then separated into four quadrants:

  1. Which skills to I bring into the team?
  2. What do I need to be successful in the team?
  3. What’s in it for me?
  4. Something personal. No dark secrets, just something that turns you into a person.

Write a motto below the shield.

Put those in a place where every team member can see them.


Make sure that the team members know where the team fits into the organization. Post a 10’000 feet view of the company somewhere.


Agile development is all about risk management: Notice them, rate them, discuss them, act on them.

Good places to look for risks: Team boundaries and interactions: Who depends on the team’s work? On whom does the team depend? Does the team have everything it needs?

What does the team know about the future? What do we not know? What are opportunities and threats?

Remember the PAC triangle: Purpose – Alignment – Context. Every move of one corner influences the other two as well.

Also a lot of risks have their roots in VUCA:  volatilityuncertaintycomplexity and ambiguity.


Jazzon 2011, Day 3 – Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

26. June, 2011

Turning up the heat – techniques for self-organizing teams – Joseph Pelrine

Joseph reminded us that teams always organize themselves, if we want it or not. Those social forces are pretty strong which is why agile methods have given up to fight with them. Instead, they try to prevent the worst and/or alert you early of problems.

The most important three words of the talk: “Leave them alone.”

But the result is probably not going to be the way you want. Also, team building this way can take a long time. Or it can be surprisingly quick. It can take as little as 2 seconds for a group of strangers to clap in unison (as he demonstrated in the presentation using the audience). One reason why this works is because we wanted it to happen. If part of the team refuses to be part of it, you’re in trouble.

When we say “self-organizing,” who or what is this “self” really? It’s a “system” composed of a group of people and their environment. This simple fact is an often overlooked. Renovating a shabby workplace can be better for quality than a raise or bonus. Listening to people and acting on their input is more effective than bringing in external consultant. Usually, they are brought in to make the “act upon” part more easy.

Every such system defines its own rules and responsibilities. Without any regard to what people want or what happens to them. Martyr anyone? The problem: We want people to do what we want without us telling them. Only if you ignore (part of) the system, you will fail because the forces in the system can be tremendous. Again, agile lists methods that often work but you should still be aware that there are reasons why changes to the system fail.

For example, Art Kleiner came up with the Core Group Theory: For every system, there will be a small group of people who control the system. Dictator in a dictatorship. If the boss doesn’t take control, the system still enforces that the “underlings” follow – they will make fun of the boss but they will still follow orders. Most often to the letter. Financial crisis: Small group of greedy people almost ruined the world’s economy.

One important point is that you need energy from the outside if the system’s equilibrium isn’t what you want it to be. Say your developers aren’t testing enough. You need some incentive for them. This external energy is consumed but it doesn’t necessarily alter the system permanently.  For that to happen, you must look at the system (people + environment) and find a way to make sure it’s in the system’s best interest to change (and not only in the people’s best interest!)

How can you do that? You turn up the “stress” or “heat.” Note that too little heat and nothing will happen. The resistance of the system will simply swallow your efforts. Too much heat and the system will retaliate or overreact. So it need to be applied with care.

One way is to use the physical formula PV = nRT which means pressure * volume = temperature. You can increase the temperature (the heat) by increasing the pressure (add more tasks) or by reducing the time to complete the tasks.

Another is to look at the system as a star with five tips: Attractors (like bonuses), boundaries (who is on the team, who isn’t), identities (who was which role/responsibility), diversity (homogeneous systems tend to inbreed) and environment.

Which means you can try these things:

  • Offer a price like a holiday or free pizza for all (attractor)
  • Add/remove people to/from the team like mixing the testers with the development team.
  • Move a difficult customer to a different support guy
  • Bring in new blood and ideas
  • Get them new computers, remove the telephones so they don’t get interrupted every 11 minutes.

Remember: Changes are like really long hikes; one step at a time.


%d bloggers like this: