It’s been a while since I posted, and it’s funny how my posts tend to reflect the problems I’m facing on the projects, so, when those problems becomes less technology related… the posts become less technology related as well.
So the next one up: I see it over and over again that on the government projects where scrumfall is how the projects are done. There is nothing I can do about it, it’s above my paygrade to change that, but this leads to another problem which is who is responsible for what on such projects?
As in:
- It’s not unusual to see that, at the start of the project, the “requirements” are not too detailed yet. That’s the legacy of scrum in the scrumfall
- That’s also not unusual to be asked for an estimate / plan of the whole project from start to end, and that’s the legacy of the waterfall
- And that’s not unusual to see exactly the same roles involved on such projects which we are used to in the classic waterfall
So we get to the situation where we have business analysts, developers, QA, business stakeholders, and, also, product owners each trying their best without exactly knowing what the best is.
Don’t get me wrong, with the scrumfall I don’t know either. For example, close collaboration, bein the pillar of agile, tends to be somewhat limited in the scrumfall, since requirements are expected to be provided to the dev team in the ready-to-work-on form rather than in the need-to-discuss-with-the-business form. So, it’s often the case that a business team will be somewhat separated from the dev team in terms of how they collaborate.
No matter how we do it, though, we need to be able to
- Understand what the business wants
- Figure out how it can be implemented
- Document what-s and how-s, get to the agreement that “how” covers “what”
- Then implement the “how” part and release the solution
It’s all the same whether we follow scrum/agile/waterfall/some sort of scrumfall.
However, where waterfall implies that (1) has already been done, and where scrum implies that this whole process above is highly iterative between 1 and 4, scrumfall tends to get stuck trying to figure out team’s whereabouts.
It’s still scrum, though, the requirements are not there initially, so it still has to be iterative, and the next question is who is doing what since the set of roles in scrumfall is very similar to the waterfall projects.
What do business analysts do?
What do developers do?
What do the architects do?
When does the business do their UAT testing?
And QA seems to be the most straightforward of all.
Now, with all that said, here is, perhaps, how it may work on such projects:
1. Business stakeholders
There is no argument these folks are responsible for telling everyone else what needs to be achieved on the project. However, they may have no time, no experience, or simply no desire to fully document everything they do or everything they want to change
2. Business analysts
BA-s are supposed to dig into the business asks and put those asks into requirements. The tricky part of the BA work is to be able to do their work without venturing into the actual design/development while still capturing the requirements. So they likely need to focus on writing down what the business is asking for, drawing process-flow diagrams, making sure everyone else understands those… but they need to stop short of starting to design the data model, to create screens, etc.
BA-s do need to talk to the business.
3. Solution architects/designers
Solution architects need to decide on how to achieve desired outcomes. On the Power Platform projects specifically, and, in general, when configuring “off the shelve software”, solution designers need to know what capabilities are provided by the software to be able design properly. There is still an element of the “enterprise architecture” there, but this is where the job of solution architects can be quite different from the job of enterprise architects.
Either way, BA-s job is to provide “requirements” to the solution architects. Solution architects job is to architect the solution around those requirements.
None of that can be done in isolation from the business stakeholders, though. So, both the BA-s and the solution architects need to be able to talk to the business. When designing a solution, a solution architect will likely be suggesting design options, and the business will likely be adjusting their requirements based on the proposed designs.
Designs, however, are not offered out of a blue. They need to be feasible, so a solution architect needs to make sure that there are viable implementation options, which is where they can rely on their experience, or, if needed, they can ask others on the team for help.
4. Developers
Developers should be able to see requirements and design before they start implementing. It does not matter if it’s done as user stories or if it’s documented in the excel spreadsheet and word documents. What matters is that developers need to develop, and they can’t if they don’t know what to develop. However, developers can still run into issues while implementing something, and, if that happens, the whole design may need to be updated, in which case everything need to go back. From the developers to the architects, and from the architects to the business/ba-s.
Those are the roles, though. On any given project the same person can be wearing different hats at different times, and that, sometimes, becomes really confusing, especially when it breaks the sequence. As in, a BA can decide to start designing the solution. A solution architect can somehow decide to bypass the BA-s when capturing the requirements (which is highly possible since both BA-s and architects need to have discussions with the business). A developer can choose to change the design, or, perhaps, to go straight to the business to reopen design discussions without the architect being on the same page.
Which is where it seems to be important for everyone to know which hat they are wearing in regards to a specific requirement to approach it from the proper angle without stepping on each others’ toes.
Well, as usual with this kind of questions, there is, likely, no single answer, but, hopefully, this makes some sense.