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?

  • What is your role? How is this issue affecting you? Why is this problem yours to solve?
    – Todd A. Jacobs
    Nov 4, 2018 at 1:04
  • Hi Todd! My role here is a System Analyst. This issue was affecting me because I was from a waterfall method background for the past 4 years working in previous company. In this current company/environment, there is no standardization / SOP defined as the team newly joined. I've talked to the PM regarding these as I'm afraid if it these scenarios continue to exists, it will affect the team performance. It will also affect me to think if I should stay working in this type of environment.
    – VincentPzc
    Nov 5, 2018 at 0:48

3 Answers 3


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.

  • Hi Taylor! Thanks for dropping your opinions! I've read up some information about agile methodology today and I agree with you regarding the documentation. I was worry of it as I was practicing waterfall previously and I'm still trying to adapt with agile environment. I'm not sure why the company doesn't have a demo version of it, but I believe they are taking a big risk so they can grab the opportunities of doing this project.
    – VincentPzc
    Nov 2, 2018 at 7:19

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.

  • Hi Barnaby! Thanks for your valuable information! I agreed with implementation for design. But isn't it better if we draft the solutions and present to client before the developers begin the coding? I'm not sure if this is applicable in agile. Hope you could advice me!
    – VincentPzc
    Nov 5, 2018 at 1:04
  • I've also suggested to the PM to let the developers take more ownership of development, e.g: let them decide/plan how the functions/database should work since they know what's the best for it. But the PM seems to be doubting their capabilities and would made the team to design based on the PM suggestion. Sometimes, I do feel that the PM is crossing the line by being micro-managing the technicalities aspects. Occasionally, the dev. team solutions seems complicated (they wanted to ensure the base coding has scalability in future), but the PM would insists to make things simple.
    – VincentPzc
    Nov 5, 2018 at 2:05
  • There is nothing wrong with doing some up-front design. However, it is important to realise that people are usually much better at giving feedback on a working application than they are on a design. The trick is to find the right balance for your team - enough up front design to get started, but then also allowing room for changes resulting from feedback once the client sees the application. This is what agile is all about - anticipating and adapting to change. Nov 5, 2018 at 8:02
  • 1
    To chime in on the "design before code" question: there's an agile slogan, "Build the wrong thing fast" (I would add, "and cheaply"). The idea is that the first thing you build will inevitably be not quite right, and that it's more cost effective overall to build something quickly that people can actually use and give meaningful feedback on, so that the next iteration will be closer to what they want. Nov 10, 2018 at 3:19

"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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.