Agile? Or waterfall, actually

1

I’m interested to learn how many development teams in Tokyo work in a genuinely agile (as in Agile Manifesto) style, as opposed to traditional waterfall styles, or fake / “dark” agile styles.

How is your workplace?

Mine is deeply entrenched in waterfall thinking, and I see many jobs for Project Managers - so I’m wondering where all the actual software developers are :slight_smile:

2

most likely is “waterfall agile hybrid” style where they most likely still do the task based on the waterfall style but the project management part will be agile where the deadline can still be changed, task can be shifted priority etc etc…

3

Hi tyo07, thanks for chiming in.

That was an interesting response! What I have experienced a lot is kind of the other way around, where the management style is essentially waterfall, with some agile-looking elements thrown in.

E.g. 1) everything starts with someone plucking a date out of a hat and calling it the “deadline”
2) project management demands someone someone else produce perfect requirements documentation
3) people who do the work start to understand the scope (and sometimes that the deadline is out of whack with reality)
4) at this point project management types are happy to start talking about having “sprints”, I guess because it sounds like that will be fast that way :slight_smile:
5) as the sprints go on, it’s apparent that things are behind schedule and some people suggest that the lost ground can/will be caught up “in the next sprint”
6) … :frowning:

From discussions with people in some other organizations, I gather that many places are still struggling to become more genuinely agile (in particular, operating as learning organizations that adjust course based on feedback loops), but perhaps older ones especially are struggling to change older, traditional IT processes that have become firmly entrenched due to various reasons.

Your experience sounds different to mine, and it’s good to hear.

4
  1. quite true, we call this “Business Deadline” because deadline came from business side or PDM
  2. not possible in software engineering I guess because there are always uncertainty. At best, 75% of our estimation is quite right.
  3. Exactly and it’s very difficult to distribute the “subject” or “topic” because the knowledge is not shared quite well, this will lead to another problem some time later.
  4. Sprints in my place is a “time box” for project management. There is no feedback given everytime sprint end so it is quite sub optimal.
  5. It’s better to acknowledge the delay and not promising the delay can be caught up IMO…but sometimes people wants to give “sweet promise”. What I think, that is “false promise”.