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?