Is it possible to switch from Waterfall to Scrum
I have a team of about 20 people working on a product (an app). Every 1.5-2 months, we release a new version with new features. I think it's possible to treat each version as a small project. In the ideal situation, we create a plan at the beginning of each cycle and put it into the calendar, so each developer can see what to do and when it should be done. Most tasks have dependencies, and most of the tasks should be done by a particular team member or one of the few (because of specialization).
We're also required to know the next release date and the list of new features in advance.
So, we assign each task to a developer, draw a critical path for the most important feature, then plan all other tasks.
Unfortunately, the situation is never ideal, so creating a plan for each version takes a considerable amount of time from these 1.5-2 months, so at some point, we stopped planning before the development and now planning in parallel with the development. Obviously, it didn't help us solve any problems, and created some new.
Some team members suggest switching to scrum ar another agile methodology, but as I can see, scrum doesn't work well with specializations and can't help in calculating the release date. Am I wrong?
Is there a way to use scrum in this situation?
scrum doesn't work well with specializations and can't help in calculating the release date. Am I wrong?
A Scrum Development team ought to have all of the skills needed to produce "Done", finished increments of work, ready for immediate release, every Sprint. Where there are necessary specialists, they ought to be in the team.
At least one release will be planned every Sprint. That should help with the calculation of dates.
Is there a way to use scrum in this situation?
Would the product benefit from the empirical process control Scrum provides? Is it a complex product, with many emergent challenges and unknowns, that can only be resolved iteratively & incrementally by a creative and cross-functional team?
It is possible to switch from a plan-driven, sequential model (Waterfall) to an adaptive, iterative, and incremental model (Scrum or any of the other agile methods or frameworks). Truly embracing agility, however, is a drastic shift in mindset.
Based on your description of the situation, a few comments regarding migrating to an Agile approach:
- Some key values and principles of Agile Software Development are self-organizing teams and collaboration between different groups of stakeholders. 20 people working on a single product is a lot. Most agile methods focus on smaller teams, with Scrum recommending (but not mandating) a Development Team of between 3-9. You may end up with 2 or 3 teams and it's hard to switch three teams from a plan-driven approach to an agile approach quickly and without a lot of pain.
- Specialization can greatly impede a team. It's not expected that everyone is equally skilled in everything, but that most people can pick up any work item and bring it to completion. If you have a high amount of specialization, you may want to consider cross-training and building up skills first. The first step would be to have enough skills to have teams that have all the skills necessary to deliver (cross-functional teams). The second step would be to build skills within each team.
- Agile methods focus on delivering software frequently and prefer shorter iterations. Scrum calls for a Sprint length of no more than 1 month. Your planning window will be smaller, but it's important to realize that you don't necessarily need to release every iteration. Scrum, for example, calls for a "potentially releasable Increment" at least once per Sprint, with a release at the discretion of the Product Owner.
- The Agile methods are better suited for delivering regularly with variable scope. If you're delivering regularly, having fixed dates to deliver something isn't a problem. However, if your scope is fixed, then you may not achieve as many benefits in adapting the plan to get valuable work done.
Thanks for the detailed description.
I think it's possible to train front-end programmers to be able to complete any front-end tasks. But training front-end programmers to work on the backend, I'm afraid, is out of the question: different technologies, different programming languages. Training an artist, QA, or designer to write code also seems impractical. Just like training programmers to draw pictures. It can be possible, but we hire artists to do the drawing and programmers to write code. Why force them to do things outside of their profession.
So, what's the possible approach?
It's possible to treat the whole team as several mixed teams working on different features. We do it already.
It's possible to divide the team into the front-end team, backend team, artists team, etc. These teams can become cross-functional, but then every new feature will require tasks from different teams, and these tasks will still have dependencies.
The second one seems closer to Agile methodology, but I have no idea how to plan the iteration if one team should wait for another team to finish the task before they can start working. If the next task should have to wait for the next iteration, we will need very short iterations (like a week or less), and it would seem more like working without a plan.
The second one seems closer to Agile methodology,
I disagree with that statement. If each team is made up of specialist in a particular domain, they are not cross functional. That approach is extremely waterfall as it requires a handoff from team to team for every type of work to be done. Agile is about taking a body of work, breaking it into small units that can be delivered alone and still provide value to the stakeholders. For example, if you are creating an application that allows maintenance of a general ledger, you could break that down into the ability to enter data, update data, delete data, view data, print data. All of them can be done in totality by a single team by introduce one piece of functionality per iteration. The team would consist of someone to do backend code, frontend code, user interface design, and validation. This could be a backend developer, frontend developer, artist, user experience engineer, QA. That is a cross functional team because it has all of the functional skills needed to deliver a solution. Over time, people on the team can help others learn their craft and the team can become deeper in their shared knowledge.
The trick for you will be breaking the work into independent units that could be worked on by different teams. The example I stated would not be something worked on by multiple teams at the same time because there is inherent dependency in the work. This also brings up the point that your organization's definition of "product" may need to adjust.
Moving from waterfall to agile is possible but it requires a lot of work and understanding that more than just the stuff a developer does will have to change. It will require wide and deep organizational changes.