Zoho has added another application to its portfolio, Zoho Sprints. Zoho Sprints supports companies who adopt an agile approach to project management. The solution is available as a standalone package and is also included in Zoho One. This is yet another application from Zoho that looks to support businesses using Agile methodologies.
The solution is free for up to five projects and five users. It starts at €20 per month for 20 users with unlimited projects. Larger organisations can add users at €3 per user per month. For organisations larger than 100 the price per user drops in bands.
What is included?
The new software includes several components that are familiar to those using an agile methodology for the development of software. It follows the scrum framework and includes support for backlogs, reporting and collaboration tools. Users can also create customised scrum boards.
The solution allows three security levels, admin, manager and member. Managers and administrators can create teams and projects. Within projects, the scrum master can create three types of work items: Stories, Tasks or Bugs. They can assign users to each item and allocate an estimation to complete based on points, as well as a duration.
Users are able to use timesheets to record how long each item takes. This generates a report that displays how successful a team is for a particular item or sprint. Each item also supports a work status that can be updated by the teams. It allows a scrum master and manager to quickly identify where sprints will not meet their objectives.
The reporting functionality includes Velocity Charts, Burn-Down reports, and Cumulative Flow Diagrams. All the normal tools that a scrum master would expect at their fingertips. The dashboard accumulates all the information within a given sprint, displaying a holistic graphical view of progress.
Zoho has also included a meeting module that makes collaboration easier. This includes the ability to schedule six different types of meetings. These are sprint planning, stand ups, sprint review, backlog refining, retrospectives and general meetings. For communication, Sprints includes a feature called feeds. Users are able to view different feeds that include relevant project information, notifications and direct messages.
What does this mean
For companies using agile as a software development methodology this is a low cost tool that is worth a look. What isn’t clear is the integration that it has with some of Zoho’s other solutions, most notably project management. While it forms part of Zoho One, it is not clear how it integrates into the bigger solution. Zoho Sprints lacks the complexity of Atlassian Jira. There is no apparent support for Kanban or mixed methodologies. However, at roughly half the price of Jira some companies will consider it worth a look.
Companies that use spreadsheets to manage their sprints will see benefits to using Zoho Sprints. As Sridhar Vembu, CEO of Zoho commented: “Developing new software is nothing like making trains run on time. It’s more like laying train tracks through unknown terrain, which requires one to improvise and make decisions on the fly. Agile project management formalizes that spirit of improvisation, and Zoho Sprints brings that spirit to life for all agile teams.”
Agile is one of those concepts that – much like “pyramid scheme” or even “communism” as the more extreme examples – looks convincing on paper, but fails if/when you try to execute it without properly considering the ultimate success factors.
For any software project, there are at least 3 general “pillars” of project success; 100% resource commitment, 100% developer expertise, and 100% stakeholder feedback.
There are many times these 3 can never be 100% achieved in the qualitative world we live in, and unless you have really great project management and/or room to fail, even the lack of or weakness in one of those “pillars” will cause the entire project to come crashing down; this failure is further amplified/worsened in Agile projects thanks to the “sprint-like” nature and hapless misunderstanding of the Agile project methodology.
While it won’t help to be critical of Agile projects currently underway, it may be useful to those managing, to constantly reevaluate and remind themselves of the pitfalls of the four concepts of Agile project methodology, while mapping them to the 3 general project success ‘pillars’ to encourage project recovery/restructuring:
1.) “Individuals and Interactions over processes and tools” – requires 100% resource commitment; eliminating a few “unnecessary processes” here and there isn’t gonna do squat unless the resources you choose have absolutely nothing else they are working on or bound to other than your project, and that usually isn’t the reality; cannot be stressed more, and it’s cringeworthy when Agile projects fail because the sprint timeframes didn’t consider the obvious reality of the resources. If nothing else, just remember, not all people perform high-quality work under pressure; quality matters to customers.
2.) “Working Software over comprehensive documentation” – requires 100% developer expertise; even if resources code/develop all week, they can only deliver within the limits of their knowledge, and if they’re not ‘comprehensively’ documenting their work, then you’re risking a lot of rework when the product fails in QA due to poor design. Be prepared in that case to spend more time/money to bring in another “expert” to ‘comprehensively’ pick your product apart and try to figure out what went wrong; or have the previous resource ‘comprehensively’ learn from their ‘incomprehensive’ planning/designing in order to fix; hopefully they document also this time.
3.) “Customer Collaboration over contract negotiation” – requires 100% stakeholder feedback; even if you had the perfect committed team of experts, you have to also manage the business and user resources to ensure your team has a continuous stream of feedback necessary to strive for perfection. This isn’t exclusive to Agile though, it applies to any project methodology. If you’re not constantly managing expectations/feedback throughout the project from your stakeholders then brace yourself for a lot of changes as you near implementation at each sprint, which leads us into….
4.) “Responding to Change over following a plan”; I’ll admit when I first read this I was literally ROFL, but perhaps that’s because I misinterpreted the meaning; contrary to popular belief the aforementioned statement doesn’t mean forgo planning, throw all your resources into a room to just wing it, and go wild with every single change that comes your way. No, It means understand that change happens in a project, and what’s important is how your team responds by prioritizing the change with your stakeholders and resources, and being able to accept changes into your project without further reprimand or risk; both of which you are otherwise prone to without a proper plan for budget, time, and resources.
Then again, perhaps I could have saved myself (and everyone else) time going with the engineer’s or consultant’s answer “it depends” on the project…as theres no “one-size-fits-all”, and its painful to witness organizations forgetting to distinguish between reality and concept, beleiving Agile is some magical “holy grail” to solve all their issues.