Why big team cause problems?
There are a few reasons why big teams cause some management problems:
- Difficulties with Communication
- Too many relations in team Different goals and style of work
- Too much time for team members support
To count how many relations can be in the team, you can use next formula:
Here n is a count of people in the team.
So, if there are 4 persons, then there are only 6 relations. But when there are 10 people in the team,
we will have 45 relations.
A lot of relations cause problems in communication.
Sometimes it is very hard to divide work in such team. But with good management you can provide
very good threading of development, so pretty big issue will be done very fast. For example, there is
Issue where we need to provide some changes in different tiers of a system. One person will develop
such issue a few Sprints, or just whole Sprint. Theoretically, it can be possible to divide this work
horizontally on adding changes to Database, development of Business logic, frontend, etc. But also
you can try to divide vertically into sub-issues. In any case, it will help to solve issue faster.
Manage roles and responsibilities in Team
In Scrum-driven teams there is very popular idea that team is a self-driven mechanism. It is popular
to say that all team members have equal positions, equal influence on a process. For nice productivity
each team should consist of “right” people with “right” skills. As far as team is first of all a group of
people, so to work productive they should have Leader.
Every big team should have:
- Technical Manager (Team Leader). This person should take care on all management and Issues management activities
- Technical guy (not only Team leader but at least one more person). This person will help to solve tricky technical issues.
- A person, who like to solve hot issues
Safety and motivation
Share responsibility, a lot of people likes to feel themselves responsible. Responsibility for some part
of work will increase quality of the result.
It is nice if someone in the team takes role of Scrum master, and will take care of daily meetings,
plannings, etc. It is nice when somebody will take care of deploy process, etc. In general, it is nice
even make somebody responsible for some Module, part of functionality.
Give person chance to be responsible for work, but make this responsibility internal (do not say to
Customer or Product owner that John is responsible for some part of functionality).
External responsibility is a job of Team leader.
A nice thing is a Sprint Demo. Give chance to show your work on demo, but take care and support this
process.
The team should be the safe space for your team members - helps to improve skills and do the best.
Work results and motivation
One of the coolest motivators is a recognition of results. It is extremely important to know that work
you made is important and will be used by somebody.
When team finishes some functionality, it should be delivered to Sandbox/Production environment
ASAP. It is very bad practice when person can wait for code review for a few weeks. Or, team is waiting
for Customer acceptance for a few weeks. It is a right way to demotivation.
Improvement through communication in team
The only way to make team really good is to improve internal team communication. It is very
important to discuss everything what is needed: every Issue, every problem, every news. It is a very
nice way to improve the level of engineers through communication and knowledge sharing.
Here are a few tips for team-work-communication:
- Pair programming
- Collective Issue solving (distribute Issues in such way that a few team members will working onthe same issue together)
- Combine weak and strong Developers for cooperation
- but sometimes combine strong developers for solving some complex issue
- Provide meetings, where complex Issues and Solutions will be discussed
- Provide possibility to visit different Development events
- Organize collective reviewing and discussing of articles and videos from different conferences
Mentorship and professional expertise
Small team - power of individual(each person have huge impact, source of knowledge - person/team
leader).
Two-pizza team - power of Team work(each individual influence a lot, but source of knowledge -
whole team).
In bigger team it is easier to teach young engineers - small influence on team performance.
Do not hesitate to involve some external experts(if possible). This will help to look at solutions from
another perspective.
Planning as a way to predictability
In general, there is no matter do you work by Scrum or other Agile framework or methodology. But
you should provide plannings. Planned scope of work - predictable result. It is very important both for
Customers and Development team to work in safe space without stress and “happy” surprises.
Spend some time for planning and this will help to increase the quality of engineering. When team
understands the Issue and discussed all parts of functionality they need to provide for Issue, they can
work more relax.
Another nice trick is to provide grooming sessions or pre-planning activity. This will help to predict
some complexity in development.
Team should know a business Goal
We are working B2B, so our goal is to improve Business. Team should add Value for business each
iteration - be valuable.
To make best, Team should understand WHY? should they do the issue and WHAT Impact? will this
issue add.
Teams that understand business goals of issues are working much more productive.
Continues feedback
Each person wants to know if he/she do well. There are a lot of ways how to provide such feedbacks,
but the main idea is to provide it continuously.
You can solve or even prevent a lot of problems if you will pay attention on results of each your
teammate with some frequency.
There is no need to wait for some Performance review sessions to give feedback to person.
If You as a Lead/Manager see that person has been making some mistakes (bad code quality,
overestimates issues, postponed work, etc.) say about this. This method called “One minute
Reprimand”. As far as feedback is immediate the mistake can be solved very fast. With One Minute
Reprimand people hear it seriously and your message is easily conveyed to them.
If you see that person is growing as professional, or you found some brilliant work was done, give
Compliments to this person. This method called “One Minute Praising”. People will want to receive
such immediately compliments each time and will improve their results.
Code reviews are also one of the greatest mechanism to give feedback and to improve quality of work.
It is nice when there are at least 2 reviewers on each commit. Code review is also the way how to give
One minute Reprimand or One Minute Praising.
Such methods are much more productive in comparing with Performance review sessions that typically
provided every 6/12 months. But such sessions can be used together with immediate feedback for
summarizing.
Help to improve work and results ASAP.
You can read more about “One minute” management in Kenneth Blanchard book.
Quality as a mainstream
Software engineers are responsible for functionality they have developed, not a Quality control
engineers. That is why the main focus should be on Engineering, not on looking for Bugs and after that,
fixing them.
Only Software with good Architecture and considered Solutions will work nice enough from User
perspective.
That is why it is very important to use the best practices, design patterns, providing Unit tests,
Automation testing. It is very nice when engineers finishing their work with development testing.
Good code reviews decrease Bugs count during Testing process → faster delivery → happy client.
Of course, team should have QA engineer, but manual testing should not be the main tool of Bugs
catching. It’s more like User acceptance testing.
Support process
Support is a part of work in development process. If team is using Scrum, then Support should be a
part of Sprint. There is very common problem that the most count time developers spends on support
Bugs fixing. This is the right way to demotivation.
There are different techniques on how to solve this:
- Plan each Bug as task(give an estimate). But it is very often when Developer doesn’t know the root problem of a Bug and can give very small estimate.
- Reserve some time(e.g. 20% of Sprint) for support issues
- Use Bug per day, Bug per Person per day techniques and include this time like “risks time”
Give chance to relax
Software development is a pretty hard job, that is why it is important to give Team possibility to relax.
If you are working using Scrum framework, then very good practice is Stabilization sprint. Provide
Stabilization Sprint once in 3 Months and your Team will be happy. Stabilization sprint is not relaxing,
it can be used for fixing sole old Bugs, code refactoring, etc. But this is a little bit easier than Issues
development from scratch.
Sometimes it is nice idea to take small count of issues in Sprint and take some Refactoring issues, this
will make possible to have time for self-education.
cool tips!
ReplyDeleteThank you, Michael!
Delete