Things like:
1. Know what each other are working on? (progress/blockers)
2. Know what is currently deployed to production and staging? (heroku)
3. Keep track of larger goals (milestones)?
I believe the most important task is to teach your team members those project management skills.
Teach them the skills to recognize unexpected events and know to communicate those bad news proactively. For example, an assigned task turned out to be much more difficult or larger scope than previously thought? Communicate. Uncertainty whether things can get done in time? Communicate. Feeling even the slightest uneasy about anything? Communicate.
Understanding of the business goals? You have to teach it and make it clear. You're not gonna have a textbox, type it in and expect the team to just get it. There's a difference between reading something, and understanding something.
Again, tools are "tools". No tool can allow your team to just be in zombie mode and not use their brain to think. Tools are there as an aid, not to fill in a hole in competencies.
Choose whichever tool that works for you. Observe how your team members are doing and teach them the necessary skills as needed.
At my company we've used simple Google doc, Asana, Trello, and now we're on JIRA. They all have pros and cons, but so far JIRA is working out alright and I think better than Trello.
Great comment.
Good methods are more important than tools, to keep projects on track. As in, methods of doing things, not OOP methods.
Tools, while they can be useful (though no panacea), are secondary, and also, some tools bind you into fixed ways of doing things, which may be a hindrance at times.
You might end up using it for a few days but then you quickly fall back to the tools you usually use.
I've seen this with email clients, todo apps, project management tools, etc.
Many managers view incursions of reality upon there vision as a personal attack.
You are right though, good communication is the best approach.
> In my experience, what matters most is good communication.
> Whatever tool you use, what matter most is making sure your team are diligent about updating it, and about responding to updates by others
> If you can get them doing that, then using a spreadsheet or a wall of post-it notes will give you 80% of the benefits of using the most advanced dashboard/kanban/IM tool.
> If you can't get them doing that, then even the most advanced tools won't save you.
I know there's also a lot of scorn for agile, but the core tenet is really just writing well-defined stories. Make each ticket the smallest possible feature with incremental value than can be built, tested and deployed. Then stack your tickets in priority order. Everything else about the process is for communication and visibility, but if you write your stories well, they are less important.
A lot of solutions posted so far (post-its, E-mail, whiteboard) work well for 2 person projects, with discipline scale to 20 person projects, are problematic for 200 person projects, and are totally inappropriate for 2000 person projects.
Specialized tools are recommended when projects scale beyond 10-20 people. Formal process helps. You also need to track risks as another poster pointed out. If your project is a part of a larger whole, you need to track dependencies and their schedules (other teams at your company, vendors/suppliers, 3rd party open source dependencies, etc.)
You can monitor this for basic uptime monitoring and refer to it to sanity check which version is deployed. We do this at my place and it's super convenient.
> Know what each other are working on? (progress/blockers)
a. Gantt chart = Asana + Instagantt
- Instagantt is great. It allows you to create a Gantt chart from multiple Asana projects. I have an Asana project for each customer project with the deadlines/milestones. I also have a project for Ops/Refactoring "projects" (changing ORM, dockerizing, etc.), a project for Releases, and a project for Meetings.
- I use to think Github could do everything but business-folk seem to struggle with it, and Asana is more flexible. Assigning tasks to people in Asana is great.
b. Kanban board = Github + Zube
To actually get things built we work in loose two week sprints. We create Github Issues for tasks we are working on usually keeping them quite broad as usually a lot of details emerge once we start working on them.
We estimate time based on Planning Poker with the goal being to become better at estimating time and scoping tasks.
> Know what is currently deployed to production and staging? (heroku)
I've started keeping details of releases in Asana. Could also use Github Milestones. We feature freeze releases to a branch called `release/0.5.x`, when we ship we use a tag called `release-tag/0.5.0`, and then tag our deploys with `deploy/staging`, `deploy/prod`, or `deploy/<on-premise-customer-name>`.
> Keep track of larger goals (milestones)
We use a Gantt chart is visualise this, and usually some high-level strategy docs in Quip.
1. We do all of this from Github using issues, milestones and projects. We have a GitHub Slack integration which can also give a feel of what everyone's working on. We also have a meeting every Monday where everyone says what they'll be working on this week.
2. Master branch is always in production. Staging branch is always in staging. We use CircleCI for CI/CD.
3. Milestones in GitHub.
1. How do we know what each other is working on?
All of us (~15 people, 5 of which remote) participate in the daily at 10 o'clock. The daily takes around 15 min and it is focused on the stories and every one has a good overview on what is everyone doing. Other meetings are usually organized in the daily. Typically like
A) "I have this and that problem with X, I would like to talk with B)"
B) "Okay, let's talk after the daily."
C) "I have also interest in this"
Every day the daily is lead by another person. At the end of daily we ask questions regarding if everyone has enough/to much to do, knows what to do and so on.
2. How do we know what is currently deployed to production and staging?
Version numbers ;) And Bamboo deployments.
3. Larger Goals
Big releases every few months with planning directly after each release.
It's simply to early to think about the solution at this stage.
(With that said I manage a remote team and we use kanban on trello, heroku and slack. We only meet as needed)
We can see what everyone is working on just by looking at the stories in our 'in development' list which show who picked up that story.
We can also group stories into epics and milestones to track progress towards larger goals
Tracking the larger goals is often not well formalized, but I like this podcast episode about levels of planning in agile projects: http://deliveritcast.com/ep33-always-be-planning. It's often included in frameworks for scaling scrum, like SAFE of scrum of scrums.
2. is a purely technical problem. If I remember correctly, stuff deployed to heroku corresponds to git branches, so it should be pretty easy to create some visualization about what's deployed right now from looking at git repos. I could be wrong here.
For example my dashboard I has a 2 column layout, on the left top is my in-progress stuff and down the left side is the other team members in progress stuff. On the right top is my assigned tasks and below is monitored tasks. This layout is useful to me for tracking my work and I get to stay aware what the others are working on. It helps a lot to keep tickets small in scope, so you can rotate them fairly often.
Of course what works depends on the nature of your teams work. Anyways, just some ideas.
For the task spreadsheet, you can have a twice-a-week stand up where everyone goes around and updates their own tasks on a google sheet in turn.
For the milestone spreadsheet, a period between one month and one quarter works well.
Although meetings are often eschewed by software engineers, they really do help to keep projects on track.
Also appoint someone to be in charge of tracking the "health" of various milestones, red = needs course correction, orange = at risk, green = on track, etc.
The closest thing I've seen to a nice solution to this is to e-mail a brief report of what you've been up to to the manager at the end of the week, who collates into a summary at the start of the following week. Lightweight, avoids superfluous detail (because the coordinator can edit it out), and not so fine-grained that individuals can't sit on a problem for a day or two while thinking it over if that's their preferred style.
Obviously, this doesn't preclude talking about individual issues during the week! But daily check-ins force this too quickly in my view.
Start with Trello. You can easily bend Trello to work with any productivity/PM system. Easy to get started and easy to evolve your process over time. Lots of great examples of how people are using it and some cool plugins to extend it.
#1 is extremely easy to implement in Trello. #3 is definitely possible but takes some time and buy in.
I would add that visibility into what everyone else is working on is also super helpful to avoid stepping on other's toes or duplicating work.
Once you've got communication down, you might find one of these tools useful:
1) Team members have to reply to a thread on "What are you working on?" at the end of the day. This keeps everyone informed of progress and blockers.
2) We use the CI dashboard to answer this (any changes to the master branch are auto-deployed to staging, and then staging is manually promoted to production.)
3) We use a Gantt chart to track high-level milestones (usually we go through it once a week to see where we are at).
Project Management (Campfires), ability to set To-Dos, keep track of Docs & Files, and look at a master schedule is awesome.
You can quickly go from an overview to nitty gritty, and its easy to see what you and your team have accomplished.
Responsible people who care about the work and have a spine when required are what keep projects on track.
Process is key. Tools should serve the process and the team. First thing I did was to put together a basic scrum process. This had an immediate positive impact that has persisted. Some recommendations:
- Respect your team members. Give them the benefit of the doubt. There have been some good threads on HN about the distinction between being a dev and a manager.[0]
- Short daily standups: no more than 10 minutes, just the three questions: Did? Doing? Blocks? We do them in-person in the office, but I also do them over email with some of our contractors.
- Regular sprints (I like two-week sprints) with focused, structured demo, retrospective, and planning meetings.
- Retrospective meetings with developers and product owners that identify pain points but emphasize fixing the process not blaming or fixing individuals.
- One-on-one meetings every other week with members of my team and with my manager.[1]
- Weekly grooming meetings: product owners and developers together review, size, and prioritize stories.
- Projects are managed in Trello: cards are either user stories or defects with acceptance criteria.
- Issues are tracked and documented (in Github). I set an example for my team by thoroughly documenting issues and emphasizing best practices.
- Developers don't work on anything that doesn't have a Trello card (we have an action item card for small one-off tasks.)
- No burndown charts!
A lot of these practices I carried over from my previous job, where we used scrum but, because of laziness and laxity on a few points, ended up with a pretty dysfunctional team.
My only real innovation was the "No Card/No Work" rule. I think it's essential. It both stops managers and stakeholders from derailing the process. And it provides a record and reference for the team's accomplishments. Coming into an existing team, I made sure I was flexible and accommodating in implementing the new process. But this is the one point on which I told my manager I needed to be firm. We agreed to leave a little bit of room in each sprint for any urgent stories that might come up. It's worked out well.
Finally, my managers support and respect the process. Commitment was one of the keywords that was emphasized when I was first trained in Agile Scrum and I appreciate the significance of it now. Without the investment and commitment of management, this would probably all be futile. For larger goals, we created an Epic board that my manager likes to use with senior management. Trello is great because it visually reinforces the reality that priorities are a queue and if you push some urgent new job to the top, everything else in line is going to get pushed down and delayed. It's funny how easy it is for people on high or under stress to ignore that basic law of nature.
[0] https://news.ycombinator.com/item?id=3407643
[1] https://workplace.stackexchange.com/questions/32765/what-is-...
How involved are yiur developers in the design process? Do they work in a whole story from a to z or do they get handed over requiremebts, ux and ui and then only work on the inplementation? I am trying to get a real a to z process in place, but its quite hard
In teams without a designer, I'd recommend picking a well-documented frontend framework like Bootstrap to establish a baseline and make sure there's a functional UAT process in place.
As far as getting a process in place, I agree it's challenging. Scrum provides a great foundation. But as the regular threads on scrum in Hacker News show, many orgs adopt it without really appreciating how it all fits together and as a result there's a good amount of well-earned resistance to it. At a previous company, we initially brought in a consultant for three days of in-house training. I believe it was money well spent. But we still managed to screw it up in critical ways.
I think establishing and documenting best practices is important, for both process and coding. I'm a big fan of checklists and transparency generally. A lot of my effort goes toward establishing consistency and eliminating surprises.
There's also the Joel Test, which is another good way to measure dev team health and smooth out some aspects of the dev process:
https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
it is quite interesting to see that no one has yet created one that combines all three in a simple / minimal interface.
> How do you guys manage large backlogs?
Try not to.
If PMs insist on logging ideas or keeping rejected projects i have a backlog board where ideas can have several stages. They can go from "spark of an idea" to "concrete details" there. In reality they go there to die
> Tiny bugs or nuances with low priority.
If they come from customers have a customer care person aggregate them and present a summary weekly or two weekly. Don't look at single events unless they seem important.
> …that just accumulate and are a pain to review again because you are not even sure they are still reproducable.
If they can't be reproduce remove it.
Important stuff will pop up by itself.
It is very flexible - you can label tickets, assign them and you even have git integration!
For remote teams that run on Slack, give http://www.slash-done.com/ a try - a good friend of mine had this built after missing a simple way of having everyone check in once their tasks were completed.
You could call it a trelloscope
If you have stringent rules in place like "only the project manager can add cards, they can only add them in the sprint planning session on Monday morning, and we are keeping strictly to Kanban", then Trello will work fine - but any competent project manager should also be able to use JIRA, and will surely benefit from its extra functionality (and any non-technical stakeholder should at least be able to log into JIRA and click the requisite few buttons to see the current sprint and the backlog, if they care enough).
But hey, each to their own.
So I actually am having trouble following your example.
1 - Do you mean that the landed contract is actually really big and important (basically it's now paying for all of the development) or just another signup?
2 - you called them hyperbolic but picked two examples that can keep clients from taking the software seriously: both examples seem to be something that might be much more important than whatever the team was working on.
What I mean is that if the client is trialing the software, and has a certain process in place but trying yours, then if their search is too slow they might go back to whatever process they had before; you can lose the client. Likewise blurry profile pictures might cause them to decide that it is not polished software they can use.
You did not use examples like "unclear icon on search label!!!" or "client logo NOT on their dashboard" or something stupid.
I also thought that anyone could talk to the stakeholder who added to your board and figure out why it is so important (if it is) or immediately move it if it's not (Assuming it's a big, important client.) Or edit it as appropriate.
Obviously this might mean totally rewriting the feature: perhaps slow search can just be rewritten as showing a recent list of the last ten (whatever) and allow them to be pinned, as the client doesn't really care about search but just wanted to bring up (whatever). I say this because for really old searches from archives people wouldn't care about waiting a few seconds, whereas for workflow type things done lots of times all the time it really matters.
Obviously a PM is supposed to stand between such a client/internal sales director and the developers but I am having trouble understanding why the PM can't move and translate from the board - assuming these issues and the client is big/important enough.
Emails often get lost or not handled with appropriate urgency for the case at hand (and can even be marked wontfix or feature request simply due to lack of communication) so if you wrote a bit more about your example I might understand better.
As I said upthread, Trello is adequate if you've got a project manager vigilantly pruning the board - but if you have the resources for a project manager able to do that, then why not just get them to use something that's really much better suited to the purpose?
Anyway, this is just my opinion based on my experience. Trello is a good tool for certain things. I don't think it's a great tool for managing a software project with a team of more than about three people, and even if you can make it work, I think most teams would really just benefit from using either JIRA or equivalent, or maybe GitHub Projects (which I haven't tried, but it looks quite good).
Thanks for your reply.
What do you think about this:
Based on what you've written, for companies that are married to Trello it almost sounds like there should be a 'staging' board and a 'production' board where the process failures you allude to can happen on 'staging', but the devs really just see 'production' -- and as soon as stakeholders stop interfering for a while they start matching. :) Then the vigilant PM can move things over to production as they figure out wtf just got 'committed' to staging. (This sync and the fake access may require some kind of automation).
Thoughts? (I know this is off-hand. But in a way I kind of like the power of important people to directly fuck with a todo board. There are so many broken processes where unimportant things are worked on and important things get pushed into a backlog. I mean there's a reason the people you mentioned got the access to fuck up the board in the first place, isn't there?)
This is veering kind of off-topic and I do feel I understand your point very well now, so this is just kind of a hypothetical. Thanks for your answers.
As long as that board doesn't interfere with an actual development sprint board, I would be totally happy!
Give me an online tool any day, I work in software development, not in arts and crafts
Trello, jira, aha, whatever won't help if you don't have clear lines of communication and a chain of command