This comparison is different, coming from the point of view of a WordPress specialist.
JIRA vs Trello vs Asana vs TeamClerk vs WordPress: Conclusion
JIRA: Use it when working with a team on larger software projects, and if you’re utilizing things like scrum for managing your work.
Trello: Use it if you’re looking for a tool that you and your team can use for free, and that gives you ultimate freedom to manage your projects however you wish.
Asana: Use it if you expect your project management tool to introduce some structure into your workflow, and if you prefer list-based tools, rather than card-based.
TeamClerk: Use it to track your progress in real-time, and to get a good overview of a handful of projects running in parallel from the same dashboard.
Managing projects with WordPress + plugins: Not really.
Author = Karol K (codeinwp)
Always interesting to read a pro/con analysis between Waterfall & Agile methodologies.
It is easy to understand and manage as stages are clearly defined.
Meticulous record keeping and documentation.
Client knows what to expect. Client will have an idea of the size, cost and timeline for the project. The client will have a definite idea of what their product will do in the end.
In the case of employee turnover, waterfall’s strong documentation allows for minimal project impact
It often becomes rigid and resistant to change.
It relies heavily on initial requirements. However if these requirements are faulty in any manner, the project is doomed.
The whole product is only tested at the end. If errors are discovered late in the process, their existence may have affected the rest of the project.
The plan does not take into account a client’s evolving needs throughout the project cycle.
It allows for changes to be made after the initial planning stage. It follows client’s requirements changes.
It is easier to add features that will keep the product up to date with the latest developments in the industry.
At the end of each sprint, project priorities are evaluated. This allows clients to add their feedback, so that they ultimately get the product they desire.
The testing at the end of each sprint ensures that the errors are caught in each cycle.
This dynamic methodology is not suitable for processes that require a complex decision making of formal planning such as construction, manufacturing, military, health care system among others.
As the initial project does not have a definitive plan, the final product can be grossly different that what was initially intended.
Author = Liz Parody (Moove-it, via Medium)
Here’s how to get more positive results from your retro meetings, and build a stronger team while you’re at it.
What’s a retro supposed to look like?
When retros implode
8 tips for better retrospectives
- Amplify the good! Instead of focusing on what didn’t work well, why not begin the retro by having everyone mention one positive item first?
- Don’t jump to a solution. Thinking about a problem deeply instead of trying to solve it right away might be a better option.
- If the retrospective doesn’t make you feel excited about an experiment, maybe you shouldn’t try it in the next iteration.
- If you’re not analyzing how to improve, (5 Whys, force-field analysis, impact mapping, or fish-boning), you might be jumping to solutions too quickly.
- Vary your methods. If every time you do a retrospective you ask, “What worked, what didn’t work?” and then vote on the top item from either column, your team will quickly get bored. Retromat is a great free retrospective tool to help vary your methods.
- End each retrospective by asking for feedback on the retro itself. This might seem a bit meta, but it works: Continually improving the retrospective is recursively improving as a team.
- Remove the impediments. Ask how you are enabling the team’s search for improvement, and be prepared to act on any feedback.
- There are no “iteration police.” Take breaks as needed. Deriving hypotheses from analysis and coming up with experiments involves creativity, and it can be taxing. Every once in a while, go out as a team and enjoy a nice retrospective lunch.
Author = Catherine Louis
Retromat is a great free retrospective tool to help vary your methods.
DoD = Definition of Done = a clear and concise list of requirements that software must adhere to for the team to call it complete.
8 steps to a Definition of Done in Jira
- Create a DoD in Jira
- Break it down
- Make it Global
- Manage it over time
- (No 5)
- Make the product owner responsible and the team accountable
- Enforce it
- Create an acceptance criteria list in Jira
Author = Dave Meyer (Atlassian)
Atlassian Video – Duration = 32:55
• JIRA and Confluence’s deep product integration
• Using Confluence for application design and team collaboration
• How to empower developers, promote open communication, and drive continuous improvement
• How to unite distributed teams
Author = Liz Heier & Ryan Anderson (Atlassian)