Skip to main content

Newbie questions: A case in wordpress plugins development

Last post 04:07 pm October 23, 2020 by John Matthews
3 replies
08:02 am October 22, 2020

Hello fellow SCRUMers.

Newbie here about to implement SCRUM for the first time in a wordpress plugin development company. I am paralised however as my situation is not the typical big software project example and I can't figure out how to implement it properly. I was hoping to find some wisdom in this forum. I will give you some background information first.

5 years ago while running my ecommerce business, I found that there were some ecommerce plugins on Shopify that were not yet available on WooCommerce, the platform I was using. After much though, I decided to pay someone to develop them for me since I don't know how to code. I founded a small side company of just 2 developers that helped me create the software I wanted for my ecommerce business. Since I was putting a lot of money and effort into this, I though I may as well sell those plugins in the marketplace. Looking back, I made every mistake in the book from a product development perspective. But nevertheless, I got the plugins I wanted and I have kept the software company alive with just one developer working part time, mainly for support and bug fixing. We developed a total of 6 plugins, and the company still get sales as of today though not significant revenue.

I am now ready to sell my main ecommerce business, I have freed myself and I'm ready to start my next venture. I though about the time I was involved in plugin development, and though I was a disaster as a project manager, I really enjoyed the process of developing software. So I have decided to get back to it, with a new vision, a new team, and a new tool: SCRUM. 

I have read the book "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland. I have hired a lead developer and I have started hiring other developers. The idea is to have a team of 5-7 people and develop over 100 plugins of different sizes.

I have been wondering how to best structure labor. I have talked to a couple of experienced coders friends of mine, and they both recommended that each developer takes over a plugin, as opposed to a team with people specialised in different areas working on all plugins at the same time (back end, front end, support, bug fixes, etc). My friends do Agile development, though they never used SCRUM.  Their reasoning being, a cross functional team might end up waiting on each other for the plugin to move forward. Since they aren't that big projects (estimated 2 months development on average) then they are better off doing everything concerning a particular plugin themselves.

One more thing to take into consideration, I am not a coder. I can't quality check their coding skills. The idea of cross functional team sounded appealing to me because I will be able to get each developer to give feedback to each other and to me, it would be easier to have scrum planning meetings and assign scrum points to the tasks when everyone is involved. I though that if each is responsible for their own plugin, it may be harder for me to assess the quality of their work or detect problems early on. Also if someone leaves the company, that knowledge about the plugins they created will need to be transferred to a new person. This problem might have some simple solution like integrating a process where they will be looking at each other's work weekly or monthly and provide feedback.

If I were to let each developer do their plugin, I have no idea how to implement SCRUM as that's a team of 1 doing a sprint for multiple products (whatever they are developing now plus bug fixes and new features for plugins they already released).

On the flipside, if I create a multifunctional team, I am also unsure how to do it in a way that will be efficient and organized.

I hope you are able to shed some light, and thank you beforehand for your help.


06:56 pm October 22, 2020

Their reasoning being, a cross functional team might end up waiting on each other for the plugin to move forward

Why? What would stop the people you hire from self-organizing, and from working in an efficient way each Sprint, so  any hand-offs and bottlenecks are minimized?

Is each plug-in so small, and trivial, that a collaborative team development effort would seem unreasonable?


11:42 pm October 22, 2020

I think this is a really interesting scenario.

Further to what Ian Mitchell has said, Scrum expects the Development Team to be self-organizing, so you should aim to always be in a position where you can trust the team, and where the team are willing to accept collective accountability.

Also regarding the last thing he said, consider whether Scrum really is right in your context. It really might be, but pay attention to the emerging evidence, and be prepared to respond to that.

I did read a few things that you said and considered that there's a particular need you have for quality, which you seem to want to manage by assessing the quality of work done by each individual.

Scrum has a concept: the definition of "Done". This can be an important control for you. You should set the expectation that quality never drops the level defined in this definition. You might want to work with the Development Team in defining this in a way that is simultaneously something that the developers can use within the team, but also so that you and any potential stakeholders could also understand what "Done" means.

I strongly recommend you read the Scrum Guide, re-read it a couple of times, and step back into it for reference from time to time (note: the guide is due to be revised sometime this Autumn, although the essence of Scrum won't really change).

And one key cautionary note I'd sound is that Scrum is only designed to work in its entirety. If you choose to only implement parts of it, it will no longer be Scrum, you might lose transparency or inspect & adapt opportunities, and then it may no longer function effectively as a framework for empiricism.

Often when you use Scrum, things can be uncomfortable (maybe even painful). You then have to work out how to solve those problems in your context. The challenge is changing behaviours and processes without masking them by deviating from the Scrum framework.

 

I have hired a lead developer and I have started hiring other developers. The idea is to have a team of 5-7 people and develop over 100 plugins of different sizes.

Scrum doesn't recognize terms, such as lead developer. It's a common concept (and I even work with team leads) but it can really impede self-organization and collective accountability, because whether explicit or not, there are often expectations for a lead to take extra responsibility.

What are you expecting this lead to do? The more they tend towards being the one who tells people what to do, provides reports on the team or individuals, or that you will potentially fire if things go wrong, the more likely you are to damage the ability and willingness of a team to self-organize. If there is a power imbalance in the team, i.e. the lead has the ability to affect the salary or job security of a colleague, then it's very likely that team members will struggle to speak up effectively in certain situations.

Contrastingly, this team lead could be mandated to act in more of a servant leadership stance, generally declining to be the decision maker, and focusing on growing a collaborative culture within the team, and helping the other individuals and team as a whole grow and become the best that they possibly can. Success for this lead might be that no-one even notices that they even have a distinct title. Ultimately (and in combination with proper team accountability), the entire Development Team or Scrum Team may take full or partial responsibility for hiring and firing decisions.

Did you consider who will be the Product Owner. You might be the obvious choice, or perhaps you will consider appointing and mandating someone else to do this. Does that role (as described in the Scrum Guide) sound right to you?

Lastly I'd like to point out that you made no mention of having a Scrum Master. Whether you hire a dedicated Scrum Master, or someone fulfils this and another role (e.g. one of the developers is also the Scrum Master), don't leave this decision until the end. A good Scrum Master would already be useful to you, as they can probably coach, train and mentor you, as well as offering practical assistance with setting the foundations for an effective team and product development process.


05:15 am October 23, 2020

Thank you Ian and Simon for your answers, I really appreciate it!

Is each plug-in so small, and trivial, that a collaborative team development effort would seem unreasonable?

Now that you put it that way Ian, no they are not that trivial. After reading your answers I think team effort across plugins is the way to go, but with flexibility to let them decide and test the best approach. After all, the strengths and weaknesses of each approach will be revealed as we improve our process.

Scrum doesn't recognize terms, such as lead developer. It's a common concept (and I even work with team leads) but it can really impede self-organization and collective accountability, because whether explicit or not, there are often expectations for a lead to take extra responsibility.

That is really true, Simon. I hadn't though about it. Thank you.

Did you consider who will be the Product Owner. 

Lastly I'd like to point out that you made no mention of having a Scrum Master.

Initially I though I'd fill both roles, but after doing some research I learnt that's not a good idea. I think I would be the product owner while the developer I've already hired will be the SCRUM master for now.

After giving it more though, I decided not to make each plugin a product. Instead, the product will be the suite of plugins and functionality that we offer ecommerce owners. Though the plugins can be self-contained, they are just stepping stones towards a multi-functional software. Any user may decide to use our full suite or just parts of it.

In that sense, during SCRUM planning the team will decide whether they want to tackle plugins on their own or collaboratively depending on the kind of tasks in the backlog, always taking into account that we need to have a releasable product increment by the end of the sprint. All plugins are the team's responsability and no one person will be responsible for any particular plugin.

Thank you both for your input.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.