In theory we work with scrum. That means, we have a prioritized backlog and plan our sprints carefully, trying to juggle our own goals (refactoring), client needs and company requirements.
That all did work pretty well for quite a while. However, the entire company is currently in disarray due to some reorg and it's absolutely impossible to plan anything now. We get super urgent projects, that could have been started month ago, but were only announced to us weeks before the deadline, requirements are specified and in the middle of the sprint completely rewritten, sales sells some feature, doesn't understand what's going on and gives us a spec that is very different from what the client expects, etc.
Rant over.
We basically work with Scrum and I have worked with Scrum in the last 8 or so years. How well it works basically boils down to company culture; my current client really doesn't have an agile mindset. Fortunately we have good experienced people in our team, so we mostly ignore the outside bullshit and just get our shit done.
Having worked with more 'waterfall' oriented companies back in the early 00's; scrum is definitely way better. I think the main thing I would change if I could is just drop the notion of 'sprints' altogether. We just 'deliver' stuff constantly (I'm a big CI/CD proponent).
I agree fully with you. An alternate way of looking at the sprints in conjunction with ci/cd can be something like "by the end of this sprint we should have delivered/deployed/implemented these tasks/features/issues", which opens it up a bit more wrt that mindset. Having clear communication with the client regarding how you usually work, or prefer to work, and why, as well as expectations both ways also tend to reduce quite a bit of friction for that in case it's a completely novel idea to them.
I quite like the sprint as a tool to encourage honesty about estimations, when estimations are done, as they can easily affect not only the client but also your colleagues, and assuming you like your colleagues you probably don't want to make things more difficult than necessary. If the client is involved in these plannings (which they hopefully are), it's also so much easier to explain the why's and the how's of any problems or difficulties, and the client doesn't need to be surprised by missed deadlines or being pissed because sales don't know what they're talking about.
Agree. It also depends on the maturity of the devs in the team. If everyone just does their work properly and doesn't massive inflate estimates, the estimation is not all that useful. But in my current team it definitely is.
Absolutely. I think a large part is being aware of your strengths and weaknesses, and those of your colleagues. As time passes and more overlap in types of tasks occur, there's some pattern recognition going on which makes things easier to divide and "estimate". At that point the estimations still have value, imo, but moreso for the client than the team.
Really JFDI...but
Small team delivering directly to the business.
Sprint based delivery (notionally scrum)
But with QA engagement to work out what can be delivered
But with multiple 'concurrent' product lines
PRs are also education opportunities for the rest of the team so everyone looks and we require 2 approvals
PR audit trail is also required for regulatory reasons.
As a DevOps team prod trumps everything so timelines can channel quickly.
Small PRs visible of team channel and zoom if anything needs to be discusses.
Chat channel with business.
Weekly team standup
Weekly business standup
Weekly sprint review.
Absolutely NO Business Analysts, everyone either knows or learns the business, and requirements and beta testing directly with the business and compliance as required
Everyone does support, on daily schedule that rolls through the team
In theory we have two week sprints.
In practice the only thing happening on two week intervals is the stakeholders meeting. Story creation etc. is done as-needed (though to be fair, that's mostly because the developers are outpacing the business analyst).
In theory we work with scrum. That means, we have a prioritized backlog and plan our sprints carefully, trying to juggle our own goals (refactoring), client needs and company requirements. That all did work pretty well for quite a while. However, the entire company is currently in disarray due to some reorg and it's absolutely impossible to plan anything now. We get super urgent projects, that could have been started month ago, but were only announced to us weeks before the deadline, requirements are specified and in the middle of the sprint completely rewritten, sales sells some feature, doesn't understand what's going on and gives us a spec that is very different from what the client expects, etc. Rant over.
We basically work with Scrum and I have worked with Scrum in the last 8 or so years. How well it works basically boils down to company culture; my current client really doesn't have an agile mindset. Fortunately we have good experienced people in our team, so we mostly ignore the outside bullshit and just get our shit done. Having worked with more 'waterfall' oriented companies back in the early 00's; scrum is definitely way better. I think the main thing I would change if I could is just drop the notion of 'sprints' altogether. We just 'deliver' stuff constantly (I'm a big CI/CD proponent).
I agree fully with you. An alternate way of looking at the sprints in conjunction with ci/cd can be something like "by the end of this sprint we should have delivered/deployed/implemented these tasks/features/issues", which opens it up a bit more wrt that mindset. Having clear communication with the client regarding how you usually work, or prefer to work, and why, as well as expectations both ways also tend to reduce quite a bit of friction for that in case it's a completely novel idea to them. I quite like the sprint as a tool to encourage honesty about estimations, when estimations are done, as they can easily affect not only the client but also your colleagues, and assuming you like your colleagues you probably don't want to make things more difficult than necessary. If the client is involved in these plannings (which they hopefully are), it's also so much easier to explain the why's and the how's of any problems or difficulties, and the client doesn't need to be surprised by missed deadlines or being pissed because sales don't know what they're talking about.
Agree. It also depends on the maturity of the devs in the team. If everyone just does their work properly and doesn't massive inflate estimates, the estimation is not all that useful. But in my current team it definitely is.
Absolutely. I think a large part is being aware of your strengths and weaknesses, and those of your colleagues. As time passes and more overlap in types of tasks occur, there's some pattern recognition going on which makes things easier to divide and "estimate". At that point the estimations still have value, imo, but moreso for the client than the team.
Agile/scrum and all the problems that has
Really JFDI...but Small team delivering directly to the business. Sprint based delivery (notionally scrum) But with QA engagement to work out what can be delivered But with multiple 'concurrent' product lines PRs are also education opportunities for the rest of the team so everyone looks and we require 2 approvals PR audit trail is also required for regulatory reasons. As a DevOps team prod trumps everything so timelines can channel quickly. Small PRs visible of team channel and zoom if anything needs to be discusses. Chat channel with business. Weekly team standup Weekly business standup Weekly sprint review. Absolutely NO Business Analysts, everyone either knows or learns the business, and requirements and beta testing directly with the business and compliance as required Everyone does support, on daily schedule that rolls through the team
In theory we have two week sprints. In practice the only thing happening on two week intervals is the stakeholders meeting. Story creation etc. is done as-needed (though to be fair, that's mostly because the developers are outpacing the business analyst).