Creating Successful Teams in Joomla

One of the things that's often talked about in Joomla is how to create effective teams. Recently, there have been several teams in the developer community which seem to have fallen apart. This post isn't about trying to blame individuals but look at what we can learn, and improve things so that teams can be more effective and Joomla can get better quality features whilst using its volunteers efficiently.

There's no Guarantee Code Will Be Merged

Sometimes, leadership has trouble giving reassurance to teams that features will get merged. There has been a history of auto-merging code that's been proposed which has turned out to not work (e.g. Tags and Install from Web). This has meant that when people have proposed code, PLT has been reluctant to guarantee merging it. This has therefore led to people being reluctant to join teams and invest significant amounts of time when there is no guarantee that features will get merged. Giving detailed proposals on the technical details doesn't even work. The Install from Web team gave a detailed set of proposals on how their plugin was supposed to work, which the PLT approved. However, the code still turned out to be such a significant problem that when original team members left, people struggled to maintain the code and it's currently in the process of being rewritten from scratch. I think it's a sad reality now that, based on previous experience, it doesn't matter if PLT approves a project - that when code gets submitted there is going to be a second review phase where code can and may well be rejected or heavily amended - despite what the team has historically proposed and had approved.

The Wrong Team Leaders?

When someone has an idea in a Joomla project, they often get appointed leader of a team to work on the project. However this could be one of the issues. Often people have a great idea but don't have the ability to manage people who sign up to their idea. People who come up with the ideas are coders and people without management skills. Whilst they can often organise people into groups in the short term to work on features - they struggle to deal with people leaving or objecting to the code being written. I think sometimes we need to look for team leads to help the original person implement a vision to help keep the team co-ordinate and help deal with disruptive influences.

One Member Teams Don't Work Either

Isn’t it great what you can achieve when adopting “just do it” @MVeeckmans #joomla10

— Brian Teeman (@brianteeman) August 6, 2015

I think it goes without saying that the "just do it" motto doesn't work either. We've seen countless people take up this mantra and burn straight out of the project again.

Roadmap's Don't work in Joomla...

I believe that one of the biggest failures in Joomla was the roadmap. It was a great idea in principle that should have given developers the ability to plan what features should be in releases. However in practice it just didn't work out. Repeatedly when teams have fallen apart leadership have had to either delay the roadmap or drop features from the roadmap. This means that people expect features and releases at a given time and we have repeatedly either not delivered features, delivered rushed features or not provided features at all in a delayed release. So far we have been unable to provide a solution for this. The other issue is that when solo contributions do some in outside of the roadmap - how do you deal with them? If you add features into the current release it takes away efforts from the roadmap releases as very rarely are features mergeable - at minimum they need testing time but often also need tweaks and changes in response to bugs. Contributors also (understandably) when they submit a feature don't want to wait for a year so that their feature gets on the roadmap and gets to a point where the release is ready.

... and neither does Agile Development

I also believe that agile development just doesn't translate to the volunteer world. Agile Development got taken up by the Joomla 4 Architecture team; however it is already clear that we are far far behind where we aimed to be under the Sprints devised in Denmark. In fact the majority of the coding according to the latest docs for the first sprint hasn't been written (source: https://volunteer.joomla.org/working-groups/joomla-4-architecture#reports) Many people just fit in Joomla when they can. Asking people to estimate the amount of time they have months in advance just doesn't work and doesn't allow for changes of personnel - different people are going to need different amounts of times to complete tasks.  

What's the "Correct" way of helping Contributors?

BIG CAVEAT: Creating a team with Joomla is never going to be error free. Any set of arbitrary statements I make here will not mean that a team is guaranteed to succeed and have code accepted. This is just a list of things I've pulled out from my own ideas and experience in the project will both successful and unsuccessful teams.

• Submit a fully formed idea to the PLT: First impressions count. And that includes feature requests to Joomla. If you submit a feature to the PLT that doesn't seem thought through then it's likely going to be rejected
• Be ready to accept change: When an feature goes public, there will likely be huge arguments. Whilst often there is unjustified criticism by people who understand how things work - there will almost always be things that you can pick up and use to improve your idea
• Have a co-lead in larger projects: When creating a larger team, ensure there is someone to help you run it - this helps to avoid burnout and allows both of you to take time out for real life issues without the project being massively affected.
• Don't be pressured by Joomla's Release Cycle: The choice to move to . If you are working on a small project there will be a chance in 6 months (as we aim to release a new minor release roughly every 6 months). If you are on a larger one as part of the roadmap, then your leadership liason should be in constant communication with you ensuring you get help where necessary.
• Try to ensure you have a low bus factor: Most projects that do get undone get undone by someone important leaving the project because of real world commitments.  Whilst obviously you can't avoid every pitfall, try to ensure that there is someone who is aware of what's going on and how things are being done publicly, so that if someone does leave the team, then others can pick up
• Regular Team Meetings: Something that has started happening recently are bi-weekly or even weekly Google Hangouts for teams in Joomla. I can't emphasize enough how useful these are to help the team being aware of what's going on inside the project.