We began using this product in 2014 as a work management tool. After that, we gained knowledge of the Agile framework and implemented these features in Rational. We now have five scrum teams, all of them using this solution for scrum planning. This includes dashboards and the Kanban view in order to support them.
Application Lifecycle Management (ALM) Suites scrum Reviews
Showing reviews of the top ranking products in Application Lifecycle Management (ALM) Suites, containing the term scrum
IBM Rational ALM: scrum
They should have design patterns in TFS for the development team, and design patterns for the QA. QA around the world basically does the same thing, and also development. Similar to Scrum, they should have something already built-in.
I would like to see templates for design added, and the option to make it more complicated.
We mainly use it for source control.
In the past, I've used it throughout the whole CI/CD. I've worked with Scrum and Agile methodologies. From the user story, from the product backlog to the CI/CD and deployment. I've used it for everything — the whole nine yards.
At my previous company, there were a lot of employees using this solution; it was the only system that was being used.
- Agile, scrum project/sprint planning
- Bug tracking
- Workflows which help track the current state of tasks.
The features that we find most valuable are the Workflow, Scrum workflow, and Dashboards.
We use this solution for our scrum team and user story management.
We use Jira to manage scrum projects for the different projects in our company. Our business is a development company that uses the cloud version of Jira to manage the sprint and releases for each project for each client. We manage scrum and cascade projects with our clients.
We have a development team and we use Jira to manage our projects. We use several products by Atlassian whenever we create and work on a new project.
We have scrum masters who write new project stories, which are tracked by Jira.
The solution offers up great transparency that makes it possible for everyone inside the departmental organization to see what's happening.
The prompt board really helped us out on projects. The scrum boards and the representation of the product backlog that helped us a lot as well. It's great for project management.
There are a lot of different plugins for Jira. Unfortunately, we did not test so many and the big pain point for us is the rigorous handling and the roadmap of Jira. We have a portfolio and structure plugin and we have our story map plugin in Jira. I am a scrum master and coach in my company. My colleagues aren't so educated on these plugins. So first we have to improve all knowledge with these plugins in Jira, to improve or efficiency in the roadmap and for these topics.
I am the software developer manager and I use Jira to manage team performance. We're also starting to use Jira for our drives. I used Jira before, for creating user stories from boards, to discuss issues, and many other tasks. Today we use Jira, Confluence, and BitBucket in our work. We practice scrum in our organization.
Virtually every day we have our daily scrum. Our team gathers around the board, which has all the columns showing where the tasks are standing: requested, planning, ready-coding, review, etc. Together, we view one task after the other and update the statuses. It's really a focal point of the team to know where the work stands, and what's the progress of the work since the last time we checked.
Within my company, there are roughly 25 employees using this solution. We have a scrum master, who's the most knowledgeable person on the tool. usually, they're the ones organizing the tasks, creating new tasks, and then creating the report at the end of the sprint or the quarter. They're the person who's creating the reports, using the more advanced features. That's the scrum master.
There are the developers, including me as a tech lead. There's the tester. There are managers — once in a while we have to present them with some reports and statistics, so they know how much work is being achieved, but they don't have in-depth knowledge of the tool. It's really an internal tool, so the customer is not involved.
We're not expanding much at the moment. We've been expanding in the past year, but now things have slowed down a little bit due to COVID-19.
I use it for project management and agile scrum projects. I am a manager, and I work with backlog tools and sprint plans. I only use Jira for backlogs, sprint reviews, and data reports. Our project manager is the person who is really working with Jira along with the team. We also have Confluence and Bitbucket. We use CloudBees and DevOps for the deployment of the environment.
The solution helps a lot with scrums.
It's great for development.
The documentation is quite good.
It has some automated software testing which is useful.
I would definitely recommend Jira for project management and similar uses, as well as other products from Atlassian like Bamboo.
Jira isn't what you would call a "coded solution" for scrum or anything like that, but it's able to do a lot of different things for people who are looking for that kind of thing. If you are looking for a custom-made solution specifically for agile or scrum, then you can go try other products like Valley or others. But if you want a good general-purpose project management system with solid integration solutions like Bamboo, then I think Jira is the product for you.
I would rate Jira an eight out of ten.
Digital.ai Agility: scrum
As an Agile coach, I have recommended the use of VersionOne to several clients.
Being the Agile coach, I work with clients to help them install it into their local environment, then conduct an initial administration to the application. Afterward, I help them use it to manage their Scrum, Kanban, and SAFe implementations.
Micro Focus ALM Octane: scrum
Do a quick scan of tools in the market and dig into your needs. Especially for a project with a lot of users with different styles of working together, Octane is the best tool because for the shared space/Workspace concept. Management is able to get a total overview of all the projects or workspaces and the teams are able to operate in their particular styles. That would be my advice.
For small teams, there might be different solutions that are cheaper, for example, JIRA, and which are more flexible. But if you need to run bigger businesses, Octane is the best because it's replacing a whole toolchain.
We are in the midst of transitioning from ALM to Octane for a all users working on the new model This includes now all parts of the company. We startet with a pilot user group of about 50 to 75 people which has already been in production on ALM Octane since June 2018. Now, March 2019, we do have 1700+ users working on Octane. My role in the company is as Product VP on the business side, so it includes defining the new working processes, how the users should work in ALM Octane, and defining all the transition stuff, etc.
We're transitioning to implementing Agile methodology in DevOps. It's a little more complex when trying to build cars because you have these little rubber and metal parts which constantly refuse to be agile and digital. But from the whole methodology, we recognize we have to be much faster than in the past and we are trying to combine both worlds. We are in a transition to what we call "Water Scrums." We cannot let go of all old Waterfall processes but we are trying to adapt as many Agile processes as possible. It will take two, three, four years to come to a stable, new process of for working with a more Agile methodology. We are digging into that and trying to adapt as fast as possible.
For example, we have a control unit which runs the software which is built into cars, and producing a control unit takes time. It requires planning and we have different teams contributing software which is running on that single processor. To combine them, it makes for more complex planning, rather than just software development. Think about the fact that you have functions in the car for the customer, like a navigation system for example, and that system is getting information from the engine, from the drivetrain, etc., so you have the complexity that different teams are working on different parts of the software on that control unit.
In terms of lessons learned in this process, the benefit is that we try to be much faster and work in smaller iterations, delivering new functionalities faster. But we always have the limitation of the physical materials which are not agile: as an example, the welding and producing of the machinery which produces the outside of a door into which you can then plug in a window, and the window needs to be of made from glass and rubber, etc. The metalwork would take 25 to 30 weeks until you get the new mold or form for the metal sheet, while software can be delivered once or twice a day. We have to combine those worlds and that is the hard part. But there is also a big chance to make a lot of partial improvements.
As for ALM tools helping with transitioning to Agile, Octane is the much better tool and we need to find a good way, supported by Micro Focus, to move data such as test cases, requirements, runs, and so on from the old ALM to Octane; to change to Octane to get the most benefit and the fastest benefit from the whole tool. Car development is a process of two or three years at least, and sometimes as much as five, for a model to hit the market, and for data migration that's a big issue. We need to dig into that, and the plans are not finalized yet.
For deployment and maintenance of the tool, there was a major team of experienced IT guys and process guys from our side, about 25 people, supported by about 60 other people just for the special processes of the different development departments. We call them "key users." They are collecting information and reporting it to the core team. For maintenance, it's a team of six people who are implementing changes requested by the core team. Depending on the workload, on average, maintenance is done by three people. There are numerous software developers working on the interface tools, perhaps some 30 IT guys working on the different tools we need to launch with Octane.
After deployment, I expect we will need two to three people to maintain it, depending on how good the tools are. For example, we use a known tool where users can request accounts on Octane, the roles they want to have, and there are guys from the business side who approve the requests. If this tool is working, you can do the onboarding, get the users' credentials into Octane, by a script, so there won't be any work for the IT guys. Right now, we need one person for at least two hours a day to add users to the different tests and integration instances and to the production servers.
Right now, Octane is at about an eight out of ten because, from our perspective, there are a couple of functions still missing. As mentioned, we are in close contact with R&D and they will implement those functions within the next year. Then, I would say, we will be at a nine, close to ten.
One of the biggest benefits is not having to wait another one-and-a-half to two years until the next major release of ALM. Even selling the weak points to the users is much easier because we can say they will be fixed in half a year or in three-quarters of a year, instead of two years, if that.
The reporting side of ALM Octane could do with a few areas of improvement. There is not enough flexibility in the way that we can cut up the data to report on certain things. For instance, with test information, we can't split that up by team, so it's quite difficult to see what coverage each team is currently working on. Some tech managers and scrum managers want to see the testing which going on within their team, but it is difficult to see. We only get a more holistic overviews of that.
I come from a testing background, and think the testing could be improved.
Microsoft Azure DevOps: scrum
Agile scrum project management of a software product in a start-up company. We are a team of 11 people located in different countries.
I like the entire tool because it is a one-stop-solution for DevOps.
The Scrum functionality in project management is helpful, as are the code repositories. It has support for pipelines.
We primarily use the solution for our Agile teams, however, we started off using it with our executive suite. Our executive team now meets in sprints every day. Sometimes it's a short 15 minutes, other times it can be up to an hour. We have two-week sprints and daily scrums associated with it. We've also rolled that down from the executive. We've got seven formal Agile teams running throughout the organization across our businesses. We probably have at least 40% of our staff now trained in Agile and using DevOps to execute the projects.
We are using this solution for CI/CD projects, for Scrum, Agile planning, testing, and business management system solutions.
We are also using it for continuous integration, and continuous delivery of DevOps.
I am also using the Git Repositories, which is the main source control for me in the organization. We were using it on-premises and now planning to move it to the Cloud.
They are calling it repository and they are supporting an old protocol, which is a popular protocol called Git repository.
Planview LeanKit: scrum
I do not know what it can do in the area of scrum. Maybe it has that functionality. I have never tried to set it up. You think of LeanKit from the perspective of Kanban. I don't know if there is a template for scrum, a scaled agile framework, or any of those scaling frameworks.
We have found that some teams get a lot more requests and work and projects than other teams. Those work-in-process, or WIP limits, are really helpful at determining if teams can take on more workload. It also helps us to see if they have roadblocks. If we have a lot of things that get in our way, it's easier to identify because we have everything in one central location on LeanKit.
Regarding a given card's status, LeanKit gives me easier access. I'm able to work more closely with my team to see what's going on with the cards that they're working on. And my manager can check in on the work that I'm doing just by looking at my cards. Everyone has a better picture of what's going on for the entire team. It also helps in project delivery. We can definitely see if our project is on-time or if we burned down too much time and are getting close to the end of the project and don't have everything done that we were supposed to have done.
While I haven't used the Card Health feature as much, when I have done demos of LeanKit to teams that are starting to use it, and I've shown it to them, they have found it really helpful. If a card has been sitting in the same lane for a few weeks, it helps them track things better to see what's going on with that individual card.
The Card Health activity stream helps business analysts and project managers to identify roadblocks, if they haven't been brought to the surface. If they have a card that's unhealthy, they're able to go to that team member and say, "Hey, what's up with this card? This is affecting the project's deadlines." Or they can even see, "Hey, we were able to get that card to the Finished lane a lot quicker than we thought," and they are able to analyze how that affected the project.
LeanKit has also reduced our cycle times. We are able to stay within our two-week sprints for those scrum teams. And for others we still have better continuous delivery; they are pretty healthy too. I would approximate that we have reduced cycle times by 20 percent, and that's just because we haven't been using it that long.
In addition, our project managers, business analysts, and scrum masters are able to use the solution's reports to determine if teams need additional help or if they can take on additional workload.