Development solution rushed prior to agreement on requirements - is this a healthy project management?

Question

I've been working for 4 years in IT field (as Developer and QA Lead) and I've just joined this company on Sept 2018 as System Analyst.

Here are some background of the company and the project we are doing at this moment:

1. Company has CMMI Level 3 certification.
2. The team are consists of developers who just joined the company 2 months ago, while the PM been working for the company for 8 years.
3. Project initiated 2 months ago.
4. This project has no fundamental concepts / base for demo
5. The team is practicing agile methodology (My first time with agile)

This is what I noticed about current SOP/Workflow of the team:

1. All user requirements has not been properly documented and signed-off so far.
2. After gathered requirements, the PM instructed developers to code the solution (according to PM's idea/visualization), while the solutions has not been documented yet and discuss with client for confirmation.
3. While solutions are either still in development stage or has been completed for demo, PM send the designed process flow to client for reviews. Client feedback with changes (sometimes minor, sometimes major) and PM requested the team to modify according to feedback within next few hours / days.
4. PM always received call from client, after the call, 90% of the time there will have some changes (modify existing features or add new features) on the system, and sometimes the team need to get it done in next few hours / days.
5. Today the PM discussed this Idea A with me and the developers. I've documented it and send to PM for reviews. After next few days, when we mentioned about Idea A, the PM will questioned why are we using Idea A as it is wrong, and requested us to change to Idea B.

Is this a healthy project management? I've voiced my concerns to the PM that we should have proper documentation (URS, FRS and etc) and sign off to prevent frequent changes of ideas/request and to buy time for developers, but the PM said this client does not bother about it and will not follow the procedures. What should we do to handle these scenarios?

Answer 1

Certainly doesn't seem healthy as described :/. I can't speak to all the points, but one piece:

• If you're churning on features without having demoed anything, this isn't great. I'm not sure you need more documentation, but you do need to get into a repeatable cycle of "Build a working piece, show it to the client, collaboratively decide the next most important thing to build."

  If they want changes after seeing it, fine and good -- they need to be prioritized with the rest of the items on the list.

If you're not getting to working/demoable software before the client or PM is asking for changes, OR if the changes are always top priority, then you'll never get into a rhythm of delivering working software, and the project will be predictably fragile and stressful. :(

The fast turnaround demanded for changes and additions is also sketchy -- it's impossible to get into a sane dev cycle if every new whim is top priority.

I'm sure others can chime in with more specific insight -- best of luck though. Don't over-worry about documentation, but do insist on a sane dev cycle, prioritized reqs, and frequent demos.

Answer 2

The team is practicing agile methodology (My first time with agile)

Agile isn't really a methodology. It's an approach to doing software development that includes valuing responding to change over following a plan.

It seems likely you are following an agile framework, possibly Scrum or Kanban? If you are working in sprints, then you are likely to be using Scrum. It would be worth finding out more from your organisation about what framework they are following as this will allow us to respond in a more specific way to your question.

There are some issues with the current approach:

the PM instructed developers to code the solution (according to PM's idea/visualization)

This is not an agile practice. Typically we encourage the people that do the implementation to produce the design.

Client feedback with changes (sometimes minor, sometimes major) and PM requested the team to modify according to feedback within next few hours / days.

Client feedback is valuable and is very much part of the agile approach. However, it is unusual to respond to all feedback immediately. A common approach would be to receive the feedback, review it, prioritise it (alongside other existing requirements) and then bring it to the next planning session if required.

PM always received call from client

It is not unusual to have a primary point of contact with the client. However, there is usually a lot of value in having members of the delivery team talking with them as well. It would certainly not make sense to put up barriers to communication between the delivery team and the person providing requirements/feedback.

the PM will questioned why are we using Idea A as it is wrong, and requested us to change to Idea B

This is clearly a disfunction. It would be worth getting the delivery team together and speaking with the Project Manager. Suggest a different approach, where the team takes more ownership of development. If you have an agile coach in your organisation, this would be a good opportunity to get them involved.

Answer 3

"Believe it or not, the real-world answer might be – maybe not, but we have to do it anyway."

"Agile," first of all, is an ideal. (A valuable and useful perspective, but "an ideal" nonetheless.) As such, it contains certain simplifying assumptions – which might or might not be true – both with regards to "the client" and with regards to the circumstances with which "the client" might be dealing. Fortunately, your team has a PM who has "8 years of experience with this company." ("Hallelujah.")

Computer software is very exacting and it takes a long time ($$$!!) to develop. So, the team might be sent forward in a particular direction before that direction is fully understood, knowing that rework will be the result. Client requirements might be acted-upon before the client(!) fully knows what the final requirements will turn out to be, or has made (or learned of) the final business decisions that will determine them.

What's happening here – and this is something that a methodology really is too simple to understand, despite its merits – is a series of educated guesses that are simultaneously being made at several different levels, both within and above the team.

"Computer programming" necessarily demands "absolute certainty" since the machine in question knows only 1 and 0, but this "guessing" is being applied to match the effort against real-world business uncertainty with – we hope – as little waste and rework as possible.

Also – "once the software is finalized, it will be fixed-in-stone and therefore much harder to change." This is another argument for the "fluidity" that programming methodologies have so much difficulty understanding. The business might commit to certain aspects of the overall project, as it were, speculatively, knowing that some portions will need to be reworked but not all of them.