3

Possibly related to How to communicate technical obstacles?.

In my current position I have found myself in difficulty when it comes to communicating technical difficulties or project management difficulties.

A bit of context: I work in a startup of 15 people, out of which 4 is our development team with me as the oldest one in the project (2 years), but the youngest in terms of age. There are often situations where I am asked to estimate the time of a given task where the difficulty level varies wildly. The code base was built by me over a 1 year period. Because I was the one always in charge of it, it is assumed that somehow I know every single aspect that can go wrong and that changing things is a linear process. Recently, our team grew and now I have the responsibility of managing the new team members as well as partially overseeing our project. For this we decided to use scrum. I have no issue with scrum, I have worked with it before and know my way around it. The COO and CEO however have never worked with it before and they are learning it now. Because of this, we did a half-way implementation of scrum where they decided what features to use or not. The problem is, they decided to remove user stories completely which is a massive mistake in my opinion as it removes a whole layer of validation of our progress.

The problem that I am facing is very often, I am unable to communicate clearly what the problem is. Although I can give clear answers and solutions when prompted too, a lot of the times I am faced with open questions from them such as "Why are user stories important? It's just a phrasing of a functionality." Or "Why does it take so long to change one text field?"

What are some ways to improve my communication to reach out the people that are not so knowledgeable in a topic? A lot of the times I feel that I am met with skepticism because I am relatively young (26 years), which seems to be more important than the fact that I have been working in software development for 5 years.

  • Allow me some questions to better understand your situation: 1) how were you working before switching to scrum? 2) do you have a product owner? Do they have experience with scrum? 3) are you acting as the scrum master also? From your question it seems that you are. 4) how has been your relation with the CEO and COO so far? Are they open minded individuals or the stubborn commanding type? – Bogdan Aug 11 at 18:05
  • 1) Before scrum we did not have a managing system, I would constantly get get my priority and work on it from the CEO; 2) The product owner is the CEO theoretically, practically however he does not act as one, does not understand scrum and it's mechanisms. My guess is that he views it as a tool for managers to delegate work, without considering the concept of self-managed teams – Iustinian Olaru Aug 11 at 18:26
  • 3) I am acting as scrum master for the software team, however there is another that is "General scrum master". We have only one scrum board for everybody involved(software, hardware engineers, electrical engineers) 4) CEO is stubborn. Did some programming in matlab some time and somehow assumes everything is linear like that. COO is new and non technical, however is stubborn on managing side – Iustinian Olaru Aug 11 at 18:29
  • One thing to note: User Stories are not part of Scrum, even though they are frequently used in a Scrum context. Scrum only requires that you have a backlog of "Product Backlog Items" without defining what form they take. – Bart van Ingen Schenau Aug 12 at 8:18
  • To answer "Why does it take so long to change one text field?" see what I wrote at blog.expertpjm.com/2011/07/quick-small-change.html – Danny Schoemann Aug 12 at 12:14
2

Self-checkup

First of all, I would suggest you do a self-checkup. You seem to be handling a lot of things all of a sudden. If you juggle with to much stuff, you will inevitably drop some on the floor. So first thing you need to do is to sit down with yourself and see how much you can realistically do, which are the things you need to handle, and which are the things you cand delegate or let someone else handle. Be also aware that you will probably need to train the new developers for them to learn the code base, be available for questions, etc., so even more work comming your way. You mention you have a "general scrum master" so ask them for help. You don't need to be the only one dealing with the Scrum situation.

Patience

You will need patience. People don't know what you know so you need to explain. There isn't a magical formula for how to explain, so you will have to develop this skill in time, with practice and patience. People will have a lot of questions, some will be annoying, some will be silly, some will be completely dumb, but you need to stay calm and have patience. If you think about it, it's kind of good that people ask questions, because that's how they learn. I've been in situations where ignorant people in high positions just uttered complete nonsense as instructions to follow, without asking for clarifying questions. So questions are good.

It's a learning opportunity

You will not have all the answers but you are expected to have all the answers. You built the code base, you manage the team now, you handle the Scrum process, so you need to have all the answers, right? That's what people expect from you. You will have to take note of things you get asked about and you don't know the answer to, and learn or find out the answer. "Why are user stories important?" Well, you should know. "Why does it take so long to change one text field?" This you should definitely know. For some of the questions you can say "I don't know, but I'll find out", from other questions you might not be able to back yourself out so easily. Accept from now that you will make mistakes and have some awkward conversations. Use it as an opportunity to discover knowledge gaps that you can then fill. For example, Scrum doesn't prescribe the use of User Stories, you have product backlog items. As long as everyone understands what needs to be built you can use anything. User Stories don't guarantee understanding.

Pick your fights carefully

When people don't understand something, they will be unaware of the consequences of their decisions. There will be things to disagree and fight for, and others you can let slide. Doing a half-way implementation of Scrum where they decided what features to use or not was a bad idea and you should have fought for keeping what's prescribed in Scrum. I'm not a big fan of follow the process and fake it till you make it, but having some structure in place to limit your choices is better than throwing away stuff or cherry picking on things they don't understand. Compared to this, fighting over User Stories becomes less important. Another important fight would be to make the CEO act as a product owner and actually manage a product backlog, properly. Otherwise work will be thrown at you whenever they see fit. That might affect your sprint, your planning, etc. They were used to work a certain way and they will not change their ways all of a sudden just because of this Scrum thingy. It will take time. At some point you might even discover you can't do Scrum properly if you don't have their collaboration. Think then if you want to fight for keeping Scrum or do something else (Kanban on top of what you were already used to might have been a better approach, for example).

So in conclusion, there isn't a prescribed way to explain things to less knowledgeable individuals. It's a matter of practice and building experience. Stay calm, have a lot of patience, and try to build soft skills. It gets easier with time.

| improve this answer | |
  • You got some things right, that I didn't mentioned but where implied. I guess this is not the answer that I want to hear... The other scrum-master that we have gave up on the discussions basically because every discussion we have brought up is always met with extreme skepticism from their part in an area where they are not proficient in. On top of that when it does end up like we predicted, there is no credit given or acknowledgement. – Iustinian Olaru Aug 12 at 5:56
  • We can all do things better that's for sure. I guess I need to learn to post-pone discussions and get the right answers when I'm met with something I can't answer immediately, although this feels wrong in some sense. If you always have to do that than maybe you're not really improving. – Iustinian Olaru Aug 12 at 5:56
  • Conversations like these are hard, and it's hard to prepare and put in the effort to learn and get better at it, but as I said, it gets easier with time. However, from these new comments, it seems that your problem is their refusal to communicate. Your higher-ups don't really want to engage in a conversation. They are playing the "I'm the boss, I know best" card. This is a tough place to be and a tough fight to win. The options I see are: 1) do what you can with what you have, keep trying to make them understand, – Bogdan Aug 12 at 8:38
  • 2) do what you think is right without asking (the old saying of "it's easier to ask for forgiveness than for permission" - be careful though because this can really bite you if you get something wrong), 3) give up on Scrum, keep working as you used to, but stick Kanban on top without allowing them to pick and choose parts from your process, 4) give up like the other scrum master and let it be whatever it will be, or 5) and this is the last resort, give up entirely and move to greener pastures some place else. It's really sad to see such autocratic demeanor in a startup with 15 people. – Bogdan Aug 12 at 8:40
1

The correct answer to your question is "I don't know", but that's not very helpful. In the effort to be helpful, I'll provide an incomplete and potentially nonresponsive answer.

Within the context of project management (I think a great deal of the reason why I don't know the answer is that your questions seems to scope far beyond project management), successful communications rests on communicating within two principles.

The first is your communications plan - I'm going to skip a bunch of the basics here, but before you communicate with the stakeholder, have a conversation with the stakeholder about what kind of communications they want. What do they want to know, and how should it be communicated. This includes both "Do you prefer email or phone calls, or office visits?", and "What's the threshold for reporting? Do you want to be told if the deliverable is 1 day late? or a week?" and a general understanding of how that stakeholder views their role in the project. "How will the success of this project affect you?"

The second is the iron triangle. PM communication is generally most effective when you can offer two things (1) an estimated impact on the project, and (2) one or more proposed courses of action.

I don't do scrum, (ironically, because like you, my management wants the illusion of scrum without any of the work of scrum), but I imagine the script is going to have to be.

  • User stories are the way that we express requirements; they help us to manage scope and quality by expressing what "done" means in a way that everyone understands clearly. If you reject user stories, then we're going to have to spend time managing requirements differently. Based on my expertise and my research, user stories will lead to higher quality, less time in User Acceptance Testing, and less rework because people better understand the objective, and the deliverables will better match the intended use and quality. I propose that we give it one sprint doing it my way, and if we don't hit the target we can revisit the conversation. I have to warn you that there is also evidence that scrumbut is attractive but ineffective, and if you insist on pursuing that, we're going to have to spend a great deal more time on management and less time on delivery.

There is a third principle here that you're going to have to feel your way through. Are you the project manager or not? Do you have any authority? Do you choose the project management methodology? Or are the managers going to micromanage past you. In a good world they just need to be convinced that you are in control of the project, and the best way to do that is to provide them accurate, reliable, timely estimates and credible information. In a bad world, they think they know more than you do, and implicitly fail to respect you; that disrespect will quickly be evident to the project team who will learn to ignore you because the only opinion that matters is the micromanager. That's a dangerous place to be.

Good luck; that is a complicated, even wicked problem; I don't think there are any simple solutions.

| improve this answer | |
  • You raised some good points in regards to the communication, I will have to revisit this every once in a while. You also made a valid point that there needs to be accurate, reliable estimates. This is what is lacking on my part. I have constantly let myself get pressured into guestimating an estimate. Which usually ended up being very inaccurate due to misunderstanding of scope. EIther I would under estimate or overestimate a duration because I either did not request or when did, was not given the time to come up with an answer but pressured on the basis "But if you have to guess ..." – Iustinian Olaru Aug 12 at 13:36
  • Estimation is difficult, but PM:SE has some good advice. In a perfect world, train them to expect a three point estimate, "I expect to finish that within 2 weeks; if it goes beyond 3 weeks, I'll brief you. Worst case is 6 weeks". – Mark C. Wallace Aug 12 at 13:59
1

Practice. It really doesn't matter what the topic is or if you're smarter than someone else or not. It's about practicing, explaining complex issues using simple, straight-forward language, using simple and everyday analogies, exhibiting patience, asking if they understand, and pivoting to another explanation strategy if you sense you're not getting traction. Practice explaining any complex topic to someone 10 years younger than you. Rehearse an explanation to yourself over and over again. Explain something complex to a few of your friends and then ask for feedback about what was good and what needs to get improved, then do it again.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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