Do you know Scrum? Are you using it? Are you sure?
All the dev teams are using Scrum. Are they all successful? I don’t think so.
Nowadays, every dev team is talking about Agile or Scrum.
Nowadays, every dev team is working with Agile or Scrum.
Nowadays, every dev team is running in Sprints.
Question: what’s the key point? How does Scrum embrace ‘Change’?
Forget the theories and those nice stories, those are totally non-sense.
Do you really think two-week Sprints could embrace ‘Change’? Non-sense!
In most cases, I did not see any actual differences between a 2-week Sprint and 2 weeks in the water-fall process.
I did not see the iterations.
What I can see is just move, move forward, move faster!
Any iterations? No.
It happens only when the defects were found. It happens only in the last 2 Sprints when integration tests raised more defects.
Change?
Oh, come on, man. What are you talking about? Last time you told me 1/2/3. Why do you want to change it to 1/3/4? That’s too hard. The schemas of the tables have to be modified. Consequently, lots of data models have to be changed. Endpoints, UI and front-end behaviors must be updated accordingly. I reckon it would take at least 6 working days. The current sprint would not be done as planned. The deadline would not be satisfied … Is it really worthy to make these changes?
Okay, forget it. No changes.
That’s what I can see in many teams in the real world.
Changes? No, no, no.
No changes, at all.
Problem: Where Is The Product Owner?
In the Scrum process, the Product Owner is the key role in the team. Without this role, it’s impossible to ‘Embrace Change’.
In most dev teams, it’s always one of the dev members (normally the technical leader) who takes this role. But dev members cannot make lots of decisions on behalf of the Product Owner, because they don’t really understand the business logic in practice. DDD (Domain Driven Development) becomes a theory because domain knowledge is key to the projects. All the details decide how the workflow should be like and how the data models should be organized.
Developers are always blindly confident after several visits or even a couple of video conferences. It’s dangerous but they have no choices because the real Product Owner has his own daily work and it’s not possible to ask them to have a stand-up meeting every morning with the team.
Dev teams are often confused: the Product Owner said OK last month, why he said NO today?
Why? It’s simple. They said YES just because did NOT see anything last time. And, they said NO because they found the thing you’re building is not what they want.
What is happening? Waterfall process. We’ve been back to the waterfall process with Scrum and Agile tools. No changes.
Someone might argue that it’s not too late since it changes just after 2 sprints.
Theoretically, it’s true and sounds not that bad. But, do you know lots of projects have to be done in 3 to 6 months, especially in small teams?
Summary
I really don’t think we have to lie to us that we’re using the cutting-edge development process!
It’s not a shame to use the waterfall process. Software Engineering provides us lots of useful methodologies.
If we cannot embrace change limited by reality, just admit it, and then try to find a way to do things better. That would be much better than practicing the waterfall process but without any detailed planning and documents. I believe it a shame for developers to deliver a rubbish project.
