I'm part of a large team developing a hardware project.

Initially, our team worked according to the waterfall methodology, but several years ago the top management began an “Agile transformation” in the company. Now we are trying to follow the practices of Large Scale Scrum.

But it seems to me that classic agile methodologies are not very suitable for our team/product. The team management also partially agrees with this. (Note: I am not a manager in this team, but I can and want to influence its processes.)

The main problem we faced was how to combine an agile approach with a long release cycle. Do you have any thoughts on this? Or maybe it’s worth looking towards alternative methodologies?

Below I will describe several aspects of our product and team that I think are important to answering these questions.

  • Although top management constantly talks about Agile, they also force us to use annual planning, with some adjustments at the end of each quarter.

  • Our product is released approximately every 3 months. It is difficult to speed up the release process due to the long process of manual testing, which currently cannot be automated. Also, product testing depends on the releases of products from other teams, which also have a release cycle of more than a month (but does not perfect coincide with ours).

  • The product is about 5 years old, a team of 50 people (programmers, analysts, testers and management) is working on it. Most participants are not multifunctional (a manual tester will not be able to write code or do analytics).

  • Also some modules have a bad bus factor - only 1 in 50 people can maintain this module.

  • Right now this reads like an opinion poll, but it isn't even clear what problem you're actually trying to solve for. What (and quite likely "who") is driving the desire for business process re-engineering here is missing from your question. In other words, who's asking for a new project or program management framework?
    – Todd A. Jacobs
    Commented Feb 26 at 22:47
  • Thanks Todd (@todd-a-jacobs), I've updated my question based on your comment.
    – nektoNick
    Commented Feb 27 at 18:40

1 Answer 1


I don't think an out-of-the-box methodology is going to work for you. If anything, a toolkit, such as Disciplined Agile, is more likely to add value. Using a structured technique to identify process goals, decisions, and options (both current and potential future states) can help you build your own approach.

If I were working with this organization, there are a few places I'd consider starting:

  • Test automation. I have yet to see tests that cannot be automated. There are often things that block the testing. For example, a lack of robust simulators and emulators can slow down software development when dealing with hardware. Poor architecture and design can impede automated unit testing, but you may still be able to write automated tests using a characterization test approach. Figure out what is slowing down automated testing and invest in solving those problems.
  • Alignment of releases. Although some test automation techniques, such as simulating, emulating, or mocking external dependencies can unblock teams, if you're releasing products that need to work together, you want some level of coordination.
  • The most important thing is not cross-functional individuals but a cross-functional team. It seems like you have that, which is a good start. The next step I would look at is reducing the bus factor. Start training people in their functional area across the product so every component or module has at least a few people confident enough to work on it independently. There may also be opportunities for cross-training across roles, but this depends more on your context and technologies. Dynamic Reteaming could be an option - FaST Agile implements some of these ideas. FaST Agile may not be appropriate for your context but it could give ideas.
  • Planning and planning horizons. In my experience, the biggest problems with planning are trying to plan too far into the future, planning in too much detail, or a combination of both. Although the organization may function well with annual planning cycles, once you work down to a team, you may be working in weeks, especially with 3-month release cycles. Thinking about multiple levels of planning, the granularity of plans, rolling wave planning, and other techniques may streamline planning, remove waste, and build confidence.
  • Thanks for your answer, Thomas! I also agree that test automation is very important for this product and I am currently working on hardware emulators for this team to make this possible. However, I don’t quite understand how to properly organize the work in weekly cycles, as you advise. What will be the main artifact of such a cycle? (In classic Scrum, after the sprint, the product increment is released, as far as I understand) What, in this case, can motivate the team to decompose tasks so that they manage to complete the tasks in one cycle?
    – nektoNick
    Commented Feb 27 at 19:01
  • @nektoNick Where did I say anything about a weekly cycle? You need to figure out what makes sense for you. You can consider how frequently you can plan, deliver and review the product, and review the process. Maybe you can plan in 2 or 3 week increments, deliver and review the product in 4 or 6 week increments, and review and improve the process once a month.
    – Thomas Owens
    Commented Feb 27 at 19:06
  • Yes, my bad. I understood "working in weeks" statement incorrect. Now this all makes perfect sense, thank you!
    – nektoNick
    Commented Feb 27 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.