Hello. New-ish PM here. Sort of a noob question here but I work with a software development team of 13 people, and we just shifted to ClickUp for all task & bug management. It seems like a really awesome tool that can scale well, but I’m afraid a lot of my team members will get overwhelmed by it. In the past, we’ve tried using Trello, Notion, and most recently Asana. We failed with all of them.
Before this, we weren’t exactly following AGILE. We borrowed some stuff from it, like daily standups and using a kanban board, but that’s mostly it. This time, we want to do it right. We want to follow Agile Scrum properly so we can improve our productivity. We want to do things right, and I really want to make sure nobody gets overwhelmed by ClickUp so they can start using it on a daily basis and possibly even like doing it.
I took a Scrum Basics course on Lynda and got familiar with the terminology and such. We defined roles such as Product Owner and Scrum Master, and we’re ready to roll. But all this is going to be useless if we can’t get the team to follow the methodology enthusiastically. So please help me with this. Any and all advice is welcome, especially from veterans who might have faced similar situations before.
9 Likes
One major point:
The process and the toolset is what will be useless, not your roles and people.
Every tool you use has to create a benefit for your team and yourself. Why did you go from digital tool to digital tool? What problem did ClickUp solve which Asana or Trello didn’t?
If you’re serious with working agile I recommend you this: Screw all tools. Everything you are used to. Start (!!!) with a retrospective: figure out what your team and you need to work. JUST do that. Then leverage what scrum gives you: inspect & adapt what you’ve built and inspect & adapt the toolset, process and how you build it.
Neither yourself, nor your team will use a tool it doesn’t directly benefit from using.
That’s why most teams start with a physical bord: it’s simple and very easy to adapt.
You should worry way more about the slicing, your wip limits, value chain, queue times and so on. Tools are just this: tools.
If you’re serious with introducing a tool, make sure that the users of these tools directly benefit from using it.
9 Likes
@NatashaMartin, Yeah, tools follow process for sure. People will use what adds value, out of necessity when following a process. It’s definitely a useless battle to try to be a tools enforcer, i.e. “Thou shalt update status!” That said, a team leader can model good process and tools usage. Kind of gentle nudges to do certain things, tidy up, etc. The retrospective can help suss out where the process falls down and where the tool fits into that.
8 Likes
@AngelaBlue, Yes, I’ve dealt with this before and I’ve been that guy myself at times. It is no fun, and I don’t want to be the tools enforcer. However, I do honestly believe there is value in creating good processes and helping the team understand why they’re important.
7 Likes
Very much agree to this. Nice.
7 Likes
Hey @ChristieDook, thank you for the response.
I do understand that the tools are not the primary problem. And I didn’t mean to imply that the roles or the people will be useless. I only wish to narrow down the underlying problem enough so I can start looking for a solution. I hope that makes sense.
Could you give me some tips on how to conduct a fruitful retrospective? Anything that would help me get the team to really open up and talk about the problems they’ve faced in the past?
6 Likes
It seems like you’re hoping that changing tools will help you fix your team’s development process. The tool is just going to help the team manage and measure their work as they iterate, it wont enforce the rules of agile on team members who havent bought in to the process.
Perhaps you should step back and figure out what major inefficiencies your development team has in their process, quantify and communicate what impacts those inefficiencies are having on the team, and then decide if following strict agile principles will fix it or not.
You might find out you just have a weak Team Lead and/or dysfunctional team members who need to be held accountable.
6 Likes
@PriyaVarma, I definitely agree.
On the topic of accountability, do you think you could share some advice on how to encourage team members to be more accountable? And if you don’t mind me asking, in your team, how do you deal with someone who has shown repeated unaccountability?
5 Likes
I will agree with the previous answers - the problem isn’t the tool, it’s the lack of process. In addition, you seem to want to use a project/dev tool for product. This won’t ever scale for you.
I’d recommend looking into proper product tools instead.
5 Likes
@BethanyGrey, Okay, what tools would you recommend?
4 Likes
You can’t software your way out of a process problem.
First examine what process issues you are experiencing: shifting priorities, over or under commitment, lack of velocity or a culture of improvement.
Then pick the most important one(s) you want to improve (if you have many to choose from, don’t pick “all”). Make sure everyone is committed to improving those issues, even to the exclusion of the others.
Then develop a plan to improve those issues. If the plan doesn’t involve/require ClickUp, then re-examine why you’re switching, or at least why now. Make sure everyone knows the plan and commits to following it — everyone doesn’t have to agree the plan is the absolute best way to improve the issue(s); just that those are the most important issues, and that the plan should work, and therefore they will commit.
Agree how you will measure success.
Then work the plan. If anyone isn’t working the plan, remind them that they agreed the issues being addressed by the plan are the most important, and committed to following the plan to address the issues.
Measure success, as often as possible. At the end of each sprint at minimum.
Much of this is from The Five Dysfunctions of a Team by Patrick Lancioni, which is a quick and useful read.
4 Likes
Amazing insight. Thanks.
Will definitely take a look at it
3 Likes
Agree with all of the answers so far, especially the one about doing a retro right now.
Where is the team failing? what problems are you having as a team, as individuals? What are team members ideas for solutions and/or making things better?
Tools are garbage. you can use post it notes or a google spreadsheet to manage tickets and progress if you really want to - sounds like the problem is bigger than what software you’re using.
Good luck!
3 Likes
Regardless of what process you want to use. you should constantly be working to figure out what’s best for the team. Don’t try to do all the changes at once.
Talk to the team about the framework. See what they like and dislike. Start with the processes people really like. Postmortem after each sprint. Gather feedback and agree to process changes as a team.
Repeat/iterate until the team feels comfortable - might kill the sprint postmortem part after a while. But still work with the team overtime.
It’s great you want to use ClickUp (don’t know it), and there are practical ways to roll out new software to a team… but don’t expect your teams to like doing it. It’s a administrative thing, but necessary for process. Work with engineering to make their use of tracking software minimal. It’s not their job to spend time in it.
2 Likes
I wished they had any ideas. They are just like robots, following instructions.
True, agree to some extent, but the management would think it otherwise. The more technology usage they see, they feel the more efficient their employees are. This is a big problem we are facing.
1 Like
Agreed with others here that it’s not about the tool; adoption will be effortless when the tool is right and supportive with a natural, no-BS, agreeable way of working. You might read a book called Extreme Programming Explained and see if it gives you any ideas that maybe aren’t working in scrum. The whole team might benefit from coaching / calibration in a framework from a boot camp or consulting firm. My team did this at Pivotal Labs — not cheap but totally transformational.
1 Like
Thank you for your answers. Perhaps I could’ve phrased my question better. In any case, I got some helpful answers and I know now that I must look into improving our processes and stop worrying about the tools we’re using. All I hope to do is bring some positive change. 