- How would you do Open Friday it with a distributed team?
Probably less often 😉
Is there a time when people meet anyway? Then, then.
Do only a few people work remotely? One attendee said that remote people attend via a laptop, which their “local” colleagues carry around.
- What do you do if you’re few people (in this case: 6)?
Depends on what problem you want to solve with OF. If it’s knowledge transfer, try brown bag lunches. Invite outside people. Maybe pair up with another small company, if you don’t do supersecret stuff.
- How do you ensure people pitch sessions?
In BarCamps you have to pitch a session, if you’re attending a BarCamp for the first time. Not the route I’d go, though. I’d try to ask people individually, to pitch a session and help with finding topics. I’d make sure there’s at least 2 people ready to be the first pitchers so that other feel comfortable following.
- How often should you run an Open Space to try to establish it?
Not just once. At least 2 or 3 times. Before the 1st one I’d hang up these 1-pagers explaining Open Space, so that people know what to expect.
- How long did it take for people from all departments to take part?
People from product teams joined first. They were used to self-organizing as well as the slack day. The others joined bit by bit and it took at least 2 months (= 8 OFs) and several encouragements that, yes, “everybody” did mean “everybody”. Now the OF opening ceremony has 50 (summer holidays) – 80 participants (out of 120 employees).
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?
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
<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
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.
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
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.
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