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.


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:


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:


Helicopter Management

23. April, 2013

Helicopter managers

  • Suddenly appear out of nowhere after longer periods of (felt) absence
  • Create huge gusts of dust
  • Make high and immediate demands for change
  • Vanish as fast as they appeared

As a friend of mine once said, “managers are a service.” I don’t bother my manager with my daily work (that’s what I’m paid to do) but for things that I can’t solve myself. When I need feedback and someone else starves me. When I need a tool but the company doesn’t give me budget or the authority to sign it. Things like that.

Helicopter managers don’t help. Most of the time, you don’t notice that they’re there. When the suddenly jump to action, a lot of dust gets blown around. But dust isn’t important. Usually, you can safely ignore dust. Dust only becomes a problem when it’s disturbed. As soon as it gets airborne, it can blind or suffocate you.

Since the helicopter manager is always in a hurry, they don’t have time to see change happen. They just start it. But they’re not there when the flaws and shortcomings of the change become apparent.

When you suffer from one of those, always keep a bucket with dust around to clog their engines.

 


Rob Williams: More Reasons Why Software is Hard

27. April, 2012

Interesting read: More Reasons Why Software is Hard


When to micromanage

11. December, 2009

When it comes to work, there are two extremes: There are those people who are enthusiastic and, once started, can hardly be stopped and there are the ones which think “Monday, 9:00am, and the weeks still isn’t over”.

Micro-managing the former will make them quit (or as Joel Spolsky put it: “Doesn’t micromanagement turn smart people into robots?“). Not micro-managing the latter will result in no work being done.

Which explains nicely why it’s a pleasure/pain to work with some craftsman: Some of them love their job, they delight in producing a perfect result which will make the customer happy. And the other ones can’t be bothered.


What’s Your Mission?

2. November, 2009

There is another nice article from Joel Spolsky: Figuring out what your company is all about. It’s all about

“We help $TYPE_OF_PERSON be awesome at $THING”

So what do you work on and how does it help your customers to be awesome with something? If you can’t answer this simple question, then you should sit down and ponder why not. It will help you to achieve your goals.

There is one point about the article, though. Joel says: “We help the world’s best developers make better software.” Uh … only the best? How about the vast majority, the good ones?


Testing: Pay in Advance or Afterwards?

2. February, 2009

In a recent post, I talked about people ignoring the cost of some decision. In his blog “Joel on Software”, they talk about the same thing: How easy it is to fall into the “we must have strict rules” trap to protect ourselves against some vague  fear of failure. Only, humans are really bad at sticking to rules. Or are they? Maybe it’s just that reality doesn’t care so much about rules because things change. If you built your castle on the belief how well strong walls will protect you, the swamp around the basement is not going to care. You’re going down, chummer.

So we end up with a lot of rules which make exactly one thing simple: To assign blame. I’ve been working for a big company where we have a strict process how projects were to be set up. There were lots of documents and forms and comittees how to start a project and a lot of documents describing how to end it (put it into production, what documents to file, who to inform, you name it). It was a great process (in the sense of “big”, mind). The actual writing of the code was explained in a document which contained a single page. On that single page, they talked on how they would strive to write excellent, error free code and that they would use a proven strategy, the waterfall model.

They built a huge, shiny castle on nothing.

If you go to a bank and tell them you have lots of $$$ and you need to pay some big bill somewhere in the future, their first question will be: How you want to make that money work for you in the meantime? Just letting it rot under your desk is not very smart, right? You should invest it somewhere, so you will have $$$$$ or even $$$$$$$ when it comes to pay the bill. Which makes sense. Contrary to that, when we write software, we tend to spend our money first instead of parking it in a safe place where it can return some revenue, being ever vigilant to be able to pay as the bills show up. Which is harder than just sitting back and relying on some mythical process someone else has written on a piece of paper a long time ago.

So when you ask: “Should I write tests for all my classes? For every line of code? How should I spend my money?” Then my answer will be: I don’t know. How can I? I know nothing about your project. But I can give you some ideas how to figure it out yourself.

“Should I write tests for all my classes?” That depends on what these classes are meant for. The more low-level the code, the more tests you should have. Rule of thumb: Tests yield more result in the basement. Make sure the ground you’re building on is sound. And behaves as you expect. The upper levels are mostly built from lego bricks. They are easy to take apart and reshape. They are exchangable, so you can get away with fewer tests. But every bug in the foundation will cripple anything above it.

“For every line of code?” No. Never. 1. It’s not possible. 2. Maintaining the tests will cost more than the real code. 3. Tests are more simple than the real code but you still make a constant amount of mistakes per lines of code. So this will only drive the number of bugs through the roof. 4. Strict, fixed rules never work (note the paradox).

“How should I spend my money?” One word: Wisely. Wisely means to think about your specific problem and find the unique solution. Do you know in advance how much each piece will cost? No. So the best you can do is a staggered approach: Invest a bit of money, check how it plays out. If it works well, spend more. If it doesn’t, scratch it, learn, try something else. Which you will be able to do since you didn’t put all your money on a single horse.

So what if your three month venture into agile development didn’t really work out? All you lost is three months. Other projects are deemed a “success” after going over budget by 100%, using twice the time that was estimated (and none of them were shorter than a year). But you will still have learned something. You paid for it, that wisdom is yours.

Use it wisely.


Management Is The Art of Choosing What Not To Do

23. July, 2008

From Rands in Repose: “… management is the art of choosing what not to do …”

If you want to know more about management told in a way an engineer can understand, consider Rands’ book “Managing Humans“.


Link: “Karl Fogel explains how to herd cats”

11. May, 2008

See this post in Paul Harrison‘s blog.

It basically explains the biggest mistakes in leading an Open Source Software (OSS) project.