21
This is the sort of things people write books about, so this is just going to touch on a few things at an incredibly superficial level.
Autonomy leads to motivation: Research has shown that autonomy is a key intrinsic motivator.
Autonomy leads to ownership: By allowing teams to make their own decisions, they feel like the successes and failures of those ...
9
Surely they are more benefits, but two that come to mind:
Motivation:
Daniel Pink lists autonomy as a key component of the intrinsic motivation of people in his book Drive: The Surprising Truth About What Motivates Us.
Adaptation becomes more difficult when the people involved are not
empowered or self-managing. A Scrum Team is expected to adapt the
moment ...
8
This is a source of disconnect between Scrum and many real-world instances.
The Scrum answer would be that the Scrum Team is responsible. The Scrum Guide says that Scrum Teams are self-managing, which means that "they internally decide who does what, when, and how".
However, Scrum Teams often exist in the broader context of an organization. There ...
4
Your problem isn't instant messaging. Instant messaging in a remote team is a substitute for talking in a local team. Trying to say that all verbal communication should adhere to maximum efficiency and never saying anything unnecessary is... rather silly.
But.
It's equally silly for people to be constantly pinging each other (verbally or otherwise) about the ...
3
Most of your proposed workflow looks ok, but there is one thing that will bite you.
The Test case issue type should also be associated with a workflow that moves from states New => Under Testing => Success/Failure
No. A Testcase should have a workflow like New => Being Written => Ready for Execution.
Next to that, you should use an additional ...
2
This question isn't really about "too much instant message communication", but rather effective communication channels. A few things stand out.
I'm not concerned by the fact that the team doesn't always monitor their email. Email shouldn't be used for time-sensitive communications. I think it's reasonable for most developers to check their email ...
1
"Removing an employee" is strictly a managerial / human-resources matter.
The team should not realistically expect to be able to "vote someone off the island." Merely because they want to.
1
This seems ideally suited to an experiment:
Determine what value you are trying to get out of communicating as a team
Find a way to quantify and measure it
Run an experiment for a number of sprints
Review if the new approach had the desired impact
1
Effectiveness of communication and volume of communication are not the same thing. It is possible to be swamped by too much communication, especially if it is of the wrong type. It is also possible to be distracted by too much communication, leading to breaks in concentration and consequent time wasted by re-doing work or correcting the errors that may creep ...
1
Instant message communication is a 'must' for a remote team
Here is a chart showing the 'Richness of Communication Channel' prepared by Dr. Alistair Cockburn:
The curve at the top shows communications that are interactive. Face-to-face communication at the whiteboard is the most effective. The curve below shows one-way communications. This chart is old. We ...
1
It sounds to me like your very-small team also consists of, shall we say, "subject-matter specialists." And this might in the short run simply "be the hand that you've been dealt." But I think that you want to take every opportunity to emphasize that "we are all one team," and so, to the greatest extent possible, "we all ...
1
A really fun way is doing a Design Sprint. Followed by some Impact mapping and User story mapping.
Depending on your product get out of the freaking building and let the developers talk to actual users. Maybe research the Shiftup program to help you facilitate continuous innovation.
Bring the team together with the users and key-stakeholders, get and keep ...
1
As mentioned in other answers, you can go for story mapping exercise but first you may consider aligning all stakeholders to a prioritisation framework and high level objectives/ themes/ Epics (for the product you are building).
The main problem with the bottom-up approach is the divergence of ideas from different individuals which may or may not be aligned ...
Only top voted, non community-wiki answers of a minimum length are eligible
