Do you know of any alternatives to Agile methodology?

In addition to what the others have said, keep in mind that agile isn’t appropriate for EVERY project. At times it can add complications that are easily addressed using other approaches.

If your firm has a mandate that “all development is agile” ask yourself why? Is it a buzzword mandate that didn’t anticipate every possible project you may encounter?

Tired, bored or frustrated teams are - in my experience- a failure on some level of the management. Look at the environmental factors… are they working for money or do they own a part of the success of the business…

look at the organizational factors… do you have all captains and no cooks…

Again, look at the management factors… is this even the right way to approach it…

And to amplify the other comment… ASK the team why they feel that way. Do it non attribution if needed… but find out!

3 Likes

Continuing with my comment above, I’d like to add more to it.

Scrum* is all you know.

Agile is a set of guiding principles that are not prescriptive in their implementation. Agile has never been about deadlines or commitments. It is about iterating, delivering value, reflecting, learning, then applying those learnings to your next iteration as “fast” as you can. It is the most malleable development framework out there.

Instead of prescribing a way for these people to work, have you considered asking for input from the team?

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
2 Likes

I don’t even know where to start with this, because you’ve just described my nightmare scenario, but I’ll start with this:

Estimates are not commitments

They are exactly what the name implies: estimates. Neither you nor any of your stakeholders should be holding the team accountable for “missed story points.” They’re made up.

When used properly, estimating can be a useful thought exercise to get the team to break down complex work into small, deliverable chunks. But there will always be unknowns and speed bumps that team did not anticipate.

Don’t just follow scrum to say you’re following it. What is the team getting out of it? Are you delivering value? That’s way more important than meeting an artificial deadline or completing all your story points.

1 Like

Thank you @RohitKumar, @MariaWilson for your valuable inputs. A big Thank You to @MichaelYoffe for taking the time to give such a detailed explanation.

Agreed that estimates are not commitments. However, our devs do make a commitment at the beginning of every Sprint during spring planning. For example, they may commit to complete 10 user stories, which are estimated at 30 story points.

If they do not complete those 10 user stories by the end of the Sprint, the commitment has not been met. This happens every Sprint.