Agile For Prudes

12. November, 2013

The article “WORKING IN A WANNABE-AGILE TEAM” points out a common problem in agile: It really exposes you and most people simply are prude.

Unlike many people want to make you believe, they are aware of their own flaws and how much a certain process humiliates them – it’s a skill everyone adopts at an early age, and therefore almost completely subconscious.

Since there is no way to be agile without looking at the team’s issues, the solution is to offer them something else instead.

In my experience, the easiest foot to get into the door is testing. When customers ask for features, ask “How would you know that it’s working correctly? Can you give me an example?” Yay, acceptance tests for free.

People struggling with a piece of code that fails all the time in interesting ways? “How do you know it’s wrong? What would be right? Maybe we could write a piece of code that makes sure it stays right from now on?” Yay, unit testing.

“Can you write a test?” “You can’t test that!” “…. You wrote software that can’t be tested? Seriously?” “… No, of course you could test it but …”

The best part: It focuses on solutions. When suggesting tests, no one can get into the blame game. Everyone can get involved. Customers, managers, developers, everyone understands tests. And they offer the most value for the least investment.

When people have started testing, they become interested in other things as well: Agile planning. Listening to the customer. That’s when you can start to change the culture – you now have some trust that you can spend.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2013 – Successful Collaboration in Agile Software Teams

25. October, 2013

Jazoon 2013 badgeIn his talk “Successful Collaboration in Agile Software Teams,” Martin Kropp lists the key factors for collaboration in agile software teams. (slides on slideshare)

For me the most important points were (slide 6):

“Agile collaboration is …

  • Face-to-face
  • Regular
  • Often
  • Informal
  • Openly
  • Under equals
  • Focused
  • Transparent
  • Respectful
  • Flexible

No is no “Agile by the Book.”

After that, he lists the usual pain points:

  • Hidden leaders
  • People sending assignments by email
  • Meetings without purpose and goals
  • Missing tools like chat, video conferencing
  • Physical vs. the digital whiteboard (slide 18)

Modern technologies like large touchscreens will make things better (slide 23).

A word about open-plan offices: They are the best tool to reduce productivity. See these articles to learn why:

1 Comment | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

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

Finally

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)

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

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:

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2013 – Visibility Shift in Distributed Teams

24. October, 2013

Jazoon 2013 badgeLike many agile tools, distributed teams make problems more visible. Pawel Wrzeszcz listed a couple of those in his talk “Visibility Shift in Distributed Teams” (slides on slideshare) and gave ideas for solutions.

One of the first issues will probably be trust. If “working at home” is believed to be equivalent to “spends add time on Facebook”, you have a trust issue. Managers worry that their “underlings” stop working as soon as they are out of sight, colleagues worry that they have to do all the work for the slackers. You have a “value vs presence” conflict.

Value here means “value for the customer” – how do they profit from what the team members do? Presence is about control. A need for surveillance is always rooted in distrust.

The solution here is to make progress visible: There should be a central place where you can see who works on what and what their progress is. You can have a web site that lists any changes made to the project sources – most DVCS give you this for free. Set up CI and use public backlogs to track progress. If everything else fails, you can send an email with daily status updates. Have meetings where people focus on what they have achieved and what keeps them from reaching their goals.

“Value delivered” should be king.

The next challenge is usually communication. During face to face, about 55% of all information is conveyed nonverbal. Tone makes up 38%, the words alone count for a mere 7%. In other words, if the text in this post lacks 93% of the information you would get if I explained the same to you in a personal meeting (source).

This why you must have a video conferencing system of some kind. It’s not nice-to-have; lacking one is like sabotaging the project.

Also be aware of the effectivenes of your communication channels. Tune narrow channels.

Use video conferences for daily standup (short, personal), chat for discussions (longer, open ended, needs transcription, not very formal), phone calls (complicated, personal, urgent), face-to-face (important). If you have a distributed team, make sure they meet face to face once per month. Flying them in might be expensive but not doing this might ruin your chance of success.

Be more personal in video conferences. Pawel mentioned the “4th question” to form bonds: Which book did you read lately? How do you exercise? This is the social glue that you need when you don’t work in one place.

Use retrospectives regularly to identify important problems that the team wants to solve.

Related articles:

Leave a Comment » | Conference, Software | Tagged: , , , , | Permalink
Posted by digulla

Software Development Costs: Bugfixing

21. July, 2012

(Second part of three; first part is here)

Software has bugs – there 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:

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

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.

Related:

1 Comment | Software | Tagged: , , , | Permalink
Posted by digulla

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.

Context

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

Risks

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:  volatility, uncertainty, complexity and ambiguity.

Related:

Leave a Comment » | Conference, Software | Tagged: , , , , , | Permalink
Posted by digulla

Jazoon 2012: How to keep your Architecture in good Shape?!

28. June, 2012

Ingmar Kellner presented some tips how to prevent your architecture rotting into a mess. When that happens, you will have these problems:

  • Rigidity – The system is hard to change because every change forces many other changes.
  • Fragility – Changes cause the system to break in conceptually unrelated places.
  • Immobility – It’s hard to disentangle the system into reusable components.
  • Viscosity – Doing things right is harder than doing things wrong.
  • Opacity – It is hard to read and understand. It does not express its intent well.

(Robert C. Martin)

According to Tom DeMarco, your ability to manage this depends on control. And control depends on measurements – if you can’t measure something, you can’t control it.

How rotten is your software? Look for cycle groups (some package X depends on Y depends on Z depends on A depends on X):

  • They tend to stay
  • They tend to grow
  • They are a strong smell

Ingmar showed some examples in the JDK 6 (lots of cycles) and ActiveMQ (lots of cycles in 4.x, much better in 5.0 but again growing since then).

What can you do?

Use a consistent “architecture blueprint” that makes it obvious which layer/slice can use what. In the blueprint, layers are horizontal (presentation, domain, persistence) and slices are vertical (everything related to contracts, customers, users, and finally common code).

You will need someone with the role “Architect” who “defines the architecture, thresholds for coding metrics, identifies ‘hot spots'” and developers who “implement use cases, respecting the architecture and coding metrics thresholds.” All this is verified by a CI server.

At the same time, avoid “rulitis” – the false belief that more and stricter rules makes things “better.”

Some rules you might want to use:

  • The blueprint is free of cycles
  • Package naming convention that matches the blueprint
  • Control coupling and cycles with tools
  • Use tools to control code duplication, file size, cyclomatic complexity, number of classes per package, etc.
  • Reserve 20% of your time for refactoring

Following these rules can help to reduce costs during the maintenance phase:

  • 50% less time
  • 50% of the budget
  • 85% less defects

according to a study conducted by Barry M. Horowitz for the Department of Defense.

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

When Agile Fails …

18. June, 2012

When an agile approach fails, then remember rule #0: No dogmas.

Agile is all about being non-dogmatic. If a rule doesn’t work in your case, find something that works.

You need UML? Use it. UML only slows you down? Drop it. UML might have some value for you in some specific cases? Apply it in a smart way.

Leave a Comment » | Software | Tagged: | Permalink
Posted by digulla

« Previous Entries
%d bloggers like this: