Yammering helps (to get rid of emails)

Is your inbox overflowing? Mostly with company internal mail? Yet, you and your colleagues still miss vital information? E.g. a year too late you find out that colleagues in France did the exact same work your team did?

That does seem to be a common complaint. Not where I’m working, though. I get maybe 2-7 emails a day. At most half of these require an answer or action on my part. It used to be many more, about 25-40, which is still little by many people’s standard. So how did the whole company – not just me – reduce their mails and everyone is still vastly better informed?

Yammer.

Don’t know what “Yammer” is? Think “Twitter” but just with people from your company and you join / follow groups instead of individuals. (You can follow individuals but that has never made sense to me. Unless of course I want to stalk someone and want to read their every thought even those in group “Dung worms of South East Asia”.) Continue reading

Na na na na na na na na Bug Slot!

<Sing title to the melody of the batman theme song>

In the company I just left we had a weekly bugslot to stay on top of defects: 2 hours every week during which all developers fixed bugs at the same time. It’s not a perfect solution but solved a number of pressing problems:

  • Discouragingly high number of bugs – accumulated over a long time
  • No overview / documentation / communication of what was fixed, what deployed, and what left to fester
    • We had no bugtracker. (The developers never reached agreement, which one to use.)
    • The same bugs appeared again and again, their symptoms often fixed by different people, so that no one recognized patterns
  • No order given in which to fix
    • Decision if and what to fix fell back on each individual dev. And as bugfixing took time away from the sprint and the team commitment…
  • About 30% of all developers were new hires, yet unfamiliar with the systems
    • The systems weren’t documented, so the new devs had no chance to fix bugs on their own. It was left to the “old” ones, who groaned under the additional workload

The situation in my new workplace is similar enough that I suggested a bugslot as well. It  has a good chance of doing the trick again.

How exactly does a bugslot work?

  • 2 hours each week for fixing (non-urgent) bugs
    • At the same time every week
    • All developers at the same time
    • Pick a week day and time that most developers will be there. Lunch time’s holy, though 😉
  • Before: Order the bugs. What needs fixing first is first in line
    • Can be done by product owner, stakeholder such as costumer support, …
    • Publish the list highly visible
      Continue reading

Getting things done: Daily goals

Searching for ways to stay more focused on the stories, several of our teams use the following trick: Each morning during standup they set themselves a daily goal.

Daily goals (“Tagesziele”) for each team member

In some teams these goals are for the whole team, in others each team member sets a goal for themselves (or pairs). Either way works fine for us and achieves several things:

  • It creates a mini-deadline that helps those who thrive on deadlines and for whom the end of a 2-week sprint is to far ahead
  • Finding the next day that you reached the goal gives a sense of achievement (a bit more than moving stickies)
  • If the goal doesn’t change (because it’s not reached) it becomes blatantly obvious that there is an impediment and you can thus address it

Daily goals for a team

So if you’ve got problems focusing or with impediments not being raised, daily goals might do the trick 🙂

PS: In case it wasn’t obvious: The teams set their own goals, not someone else.

Eliminate Waste: Caretaker of the Week

Apparently I’m stuck on the topic of decisions, but whereas the last post was about manifesting decisions, this one is about avoiding them. Well, at least a certain kind of decisions: The kind where teams need to do something regularly, but it doesn’t matter which team member does it, as long as it gets done. Let me give you some examples:

  • Who takes care of ad-hoc support requests in a team of admins doing kanban
  • Which scrum master writes the weekly “What are the scrum masters doing, anyway”-email
  • Which team member attends the SoS. (In my workplace the SoS is a stand up of team members, not the scrum masters.)

Because each of these decisions is tiny and not very significant on its own, people are sometimes reluctant to agree on a long-term arrangement that eliminates the string of tiny decisions. They figure, they’ll just take them each time they present themselves, because, hey, tiny, right? What ill could possibly happen?

Turns out, a variety of ills: Continue reading