At least 1 Software Engineer's Recommended "Things for BAs, PMs, SMs, and POs to Know About Software Development"
-
Gerry Schmitz wrote:
Or, main point: I don't need (want) a middle man to the "real" user.
Sometimes a middle finger is better than a middle man, and that not always towards users / customers. :rolleyes: ;P :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
A have been known to take a "superior" aside and tell them never to blind-side me in a meeting. No "or else".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
This "list" (prescription) has been circulating for years; only the phrasing changes. It makes you think change is possible, when it isn't. Office politics. You will never be allowed to be "smarter", or make a bigger contribution than your PM, BA, DBA, whatever. The result: grinding boredom while you wait for someone else to come to a bad decision; and then having to live with those decisions. Most of the people "involved", except the lowest levels, don't really care whether a project succeeds if it doesn't directly advantage them.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
What you describe is the painful reality too many have to experience, including me on more than one job. FWIW, I have been able to make this work in a few organizations. The largest pushback comes from BAs because of the very reasons you cite (the others do, also, but my experience was they pushed back less once they knew they were getting what they wanted). One tactic that I used successfully was to pick a project that I convinced the management above the BAs would be a "trial run" or "proof of concept". Once management saw how well it worked, they expanded on its usage. That may not work everywhere, but it is worth a try.
-
What you describe is the painful reality too many have to experience, including me on more than one job. FWIW, I have been able to make this work in a few organizations. The largest pushback comes from BAs because of the very reasons you cite (the others do, also, but my experience was they pushed back less once they knew they were getting what they wanted). One tactic that I used successfully was to pick a project that I convinced the management above the BAs would be a "trial run" or "proof of concept". Once management saw how well it worked, they expanded on its usage. That may not work everywhere, but it is worth a try.
Yes, of course there are exceptions; and I've experienced a few. Unfortunately, even the good is always followed by the bad: in-fighting about who gets to build a department around the new system (Director, couple of supervisors, maintenance programmers, librarian, receptionist, office space, ...) We implemented a Revenue and Royalty System: REVROY. I would later hear stories about people asking: "Who is this Rev Roy and why is everybody always talking about him"?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart. 1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery. 2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals. 3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA. 4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead. 5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers. 6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project. 7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning. 8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster. 9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then. 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work. 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion. 12 - Don
This deserves a more permanent place than the Lounge. At least on your Profile page, at the bottom, as something which others can more easily bookmark.
-
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart. 1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery. 2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals. 3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA. 4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead. 5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers. 6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project. 7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning. 8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster. 9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then. 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work. 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion. 12 - Don
MSBassSinger wrote:
2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals.
Surely, we should all be treated the same! Our aim should be to treat blue-collar/any-collar/no-collar workers how we would like to be treated ourselves. Not to look down on them and expect preferential treatment. Your job, salary, bank-balance, house doesn't give you the right to be treated better than anyone else.
-
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart. 1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery. 2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals. 3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA. 4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead. 5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers. 6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project. 7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning. 8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster. 9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then. 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work. 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion. 12 - Don
MSBassSinger wrote:
The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
All these years I/we/our team took "standup" as to mean, the meeting is supposed to be so quick that you don't need to sit down (15-20 mins tops, based on team size). A standup meeting is this (per person on the team): state the following: What work I just finished, what I am working on now, and if I have any road blocks. If there are road blocks, then identify who on the team can help clear the roadblocks. I have never, ever known a standup meeting to be presenting my work to the team for examination. ------------ A lot of key points you listed. most I agree with completely, some not so much. Thanks for posting.
-
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart. 1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery. 2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals. 3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA. 4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead. 5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers. 6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project. 7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning. 8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster. 9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then. 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work. 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion. 12 - Don
Excellent list!
-
MSBassSinger wrote:
The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
All these years I/we/our team took "standup" as to mean, the meeting is supposed to be so quick that you don't need to sit down (15-20 mins tops, based on team size). A standup meeting is this (per person on the team): state the following: What work I just finished, what I am working on now, and if I have any road blocks. If there are road blocks, then identify who on the team can help clear the roadblocks. I have never, ever known a standup meeting to be presenting my work to the team for examination. ------------ A lot of key points you listed. most I agree with completely, some not so much. Thanks for posting.
Quote:
presenting my work to the team for examination.
Yes, that is called a Code Review and has nothing to do with the stand up. I have found the stand-ups very useful. No stand-up went beyond 15 minutes for the entire team and often was done in 5 minutes or less.
- I would love to change the world, but they won’t give me the source code.
-
This deserves a more permanent place than the Lounge. At least on your Profile page, at the bottom, as something which others can more easily bookmark.
Thank you. I will look into that. Assuming I don't get "cancelled" by a BA somewhere. :)
-
I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart. 1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery. 2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals. 3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA. 4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead. 5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers. 6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project. 7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning. 8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster. 9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then. 10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work. 11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion. 12 - Don
-
MSBassSinger wrote:
2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals.
Surely, we should all be treated the same! Our aim should be to treat blue-collar/any-collar/no-collar workers how we would like to be treated ourselves. Not to look down on them and expect preferential treatment. Your job, salary, bank-balance, house doesn't give you the right to be treated better than anyone else.
My statement was not in the context of "looking down" on anyone. You should know, perhaps, that I had my first job working in the fields at 13 years old. I have since worked, full time, as a bagboy, machinist's mate, drill press operator, welder, electrician, pipefitter, among other blue-collar jobs. I look back on cropping tobacco and cleaning bilges, and I am always reminded not to look down on anyone. I think you misunderstood the context. Thanks for sharing your point of view, though.
-
MSBassSinger wrote:
The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
All these years I/we/our team took "standup" as to mean, the meeting is supposed to be so quick that you don't need to sit down (15-20 mins tops, based on team size). A standup meeting is this (per person on the team): state the following: What work I just finished, what I am working on now, and if I have any road blocks. If there are road blocks, then identify who on the team can help clear the roadblocks. I have never, ever known a standup meeting to be presenting my work to the team for examination. ------------ A lot of key points you listed. most I agree with completely, some not so much. Thanks for posting.
Slacker007 wrote:
so quick that you don't need to sit down (15-20 mins top
That, in and of itself, can be an ADA violation, and drive off a team member who has difficulty standing. If your team members are so undisciplined that simply asking them to keep it "short and sweet" doesn't work, then perhaps there is a separate problem that needs addressing.
Slacker007 wrote:
state the following: What work I just finished, what I am working on now, and if I have any road blocks. If there are road blocks, then identify who on the team can help clear the roadblocks.
Hence the definition of "standing up your work" for examination. I did not mean, by "standing up your work", a demo, since what I wrote was in the context of a short scrum meeting. What you wrote also speaks to training team members not to sit on roadblocks or even hindrances until a scrum meeting, but to reach out in real time for help when needed. Think of the accumulated time you gain back that would have been wasted by waiting for the next scrum meeting. I appreciate that you took the time to respond, and if my choice of words and phrasing was not clear, I apologize.
-
Quote:
presenting my work to the team for examination.
Yes, that is called a Code Review and has nothing to do with the stand up. I have found the stand-ups very useful. No stand-up went beyond 15 minutes for the entire team and often was done in 5 minutes or less.
- I would love to change the world, but they won’t give me the source code.
Which, of course, is not what I meant. On teams I have run, we worked our way out of daily standups (redeeming the time for actual productive work), so it would be moot for my teams anyway.
-
Yes. Yes. So much yes. Although I wonder if the train to treat developers as professionals has already left. After 30 years of being treated like janitors, I don't know if younger developers even know what it is like to act as professionals.
SeattleC++ wrote:
I don't know if younger developers even know what it is like to act as professionals.
I think you have a valid point. But, they are teachable, so it is up to team leads to help them grow as professionals. Such a task can be a long and difficult one, but think of the value given to one who would learn.
-
Slacker007 wrote:
so quick that you don't need to sit down (15-20 mins top
That, in and of itself, can be an ADA violation, and drive off a team member who has difficulty standing. If your team members are so undisciplined that simply asking them to keep it "short and sweet" doesn't work, then perhaps there is a separate problem that needs addressing.
Slacker007 wrote:
state the following: What work I just finished, what I am working on now, and if I have any road blocks. If there are road blocks, then identify who on the team can help clear the roadblocks.
Hence the definition of "standing up your work" for examination. I did not mean, by "standing up your work", a demo, since what I wrote was in the context of a short scrum meeting. What you wrote also speaks to training team members not to sit on roadblocks or even hindrances until a scrum meeting, but to reach out in real time for help when needed. Think of the accumulated time you gain back that would have been wasted by waiting for the next scrum meeting. I appreciate that you took the time to respond, and if my choice of words and phrasing was not clear, I apologize.
MSBassSinger wrote:
That, in and of itself, can be an ADA violation, and drive off a team member who has difficulty standing. If your team members are so undisciplined that simply asking them to keep it "short and sweet" doesn't work, then perhaps there is a separate problem that needs addressing.
:confused: Overreacting a bit with this comment, don't you think? We have multiple team members with various disabilities, which are accommodated for.
-
SeattleC++ wrote:
I don't know if younger developers even know what it is like to act as professionals.
I think you have a valid point. But, they are teachable, so it is up to team leads to help them grow as professionals. Such a task can be a long and difficult one, but think of the value given to one who would learn.
I spent much of the last 3 years working as a Scrum Master/Developer. I volunteered to be the Scrum Master which is scary in itself. The strength or weakness of the "AGILE" Process is determined by how well the PO and SM and TL's do their jobs in concert with the other members of the team. Luckily, the people I was working with worked to accept the process and it worked out fairly well. The meetings were first thing in the mornings so it wouldn't disrupt the flow of the developers or BA's. I would say 95% of the meetings were 15 minutes or less once everyone got into the flow of things. Some people complained (to be expected) but carried on. The were a number of times where people or resources were redirected based upon information provided at these meetings was surprising. Is AGILE for everyone? No. Does it work? Yes As they say , your mileage will vary....
Cegarman document code? If it's not intuitive, you're in the wrong field :D
-
MSBassSinger wrote:
That, in and of itself, can be an ADA violation, and drive off a team member who has difficulty standing. If your team members are so undisciplined that simply asking them to keep it "short and sweet" doesn't work, then perhaps there is a separate problem that needs addressing.
:confused: Overreacting a bit with this comment, don't you think? We have multiple team members with various disabilities, which are accommodated for.
Slacker007 wrote:
Overreacting a bit with this comment, don't you think?
No, not at all. Requiring a disabled person to stand, or even putting focus on the person that is excused from standing, opens the company to a significant liability. If that disabled person was motivated to do so, especially because standing provides no real value, it could cost the company a lot in a lawsuit. The point is that standing up has no real benefit a software project when working with adults. Simply ask the group to be concise, stay within their time, and if more time is needed, take it to another meeting or discussion. I've been at this for over 15 years with agile (this is the 20th year of the Agile Manifesto, btw). I never had a problem with getting adults to work together to accomplish the purpose of a stand up, keeping it short, while seated. If standing is the style you prefer, then go for it. I would recommend talking to HR, if you have not already, to find out how to mitigate liability. I am sure the HR folks and their lawyer can figure out some way to protect the company.
-
I spent much of the last 3 years working as a Scrum Master/Developer. I volunteered to be the Scrum Master which is scary in itself. The strength or weakness of the "AGILE" Process is determined by how well the PO and SM and TL's do their jobs in concert with the other members of the team. Luckily, the people I was working with worked to accept the process and it worked out fairly well. The meetings were first thing in the mornings so it wouldn't disrupt the flow of the developers or BA's. I would say 95% of the meetings were 15 minutes or less once everyone got into the flow of things. Some people complained (to be expected) but carried on. The were a number of times where people or resources were redirected based upon information provided at these meetings was surprising. Is AGILE for everyone? No. Does it work? Yes As they say , your mileage will vary....
Cegarman document code? If it's not intuitive, you're in the wrong field :D
Keep in mind that daily standups are not inherent to Agile. Nowhere in the Agile Manifesto is anything like a standup mentioned. That was an idea added later that caught on. As I mentioned in the OP, a team can meet together once a week, and then ad hoc peer-to-peer discussions as needed the rest of the week. Even though the standup might occur first thing, you still lose all that accumulated time each week that could be focused on productive work. I am sure there are use cases where a daily standup is needed. My contention is that in most cases they are not, if the team and the project are managed differently.
cegarman wrote:
The were a number of times where people or resources were redirected based upon information provided at these meetings was surprising
Is it possible that the same redirections could have occurred had team members communicated, peer-to-peer, in real time instead of waiting for a standup? In my experience, yes. In your and other's experience, only you can say.
-
Keep in mind that daily standups are not inherent to Agile. Nowhere in the Agile Manifesto is anything like a standup mentioned. That was an idea added later that caught on. As I mentioned in the OP, a team can meet together once a week, and then ad hoc peer-to-peer discussions as needed the rest of the week. Even though the standup might occur first thing, you still lose all that accumulated time each week that could be focused on productive work. I am sure there are use cases where a daily standup is needed. My contention is that in most cases they are not, if the team and the project are managed differently.
cegarman wrote:
The were a number of times where people or resources were redirected based upon information provided at these meetings was surprising
Is it possible that the same redirections could have occurred had team members communicated, peer-to-peer, in real time instead of waiting for a standup? In my experience, yes. In your and other's experience, only you can say.
Actually, communications between Dev Team members was very good, the usual cause was changes being formulated by the clients. These were changes as a result of legislative changes to existing regulations et al. The PO was very good at corralling the users requests and requirements. Once the external users were provided training on the AGILE method, the changes were presented in a clear format and in a timely manner (as much as possible). Agile did help clean up the communications between Clients. BA's and Developers. Was it perfect? No. Did it help? Yes.
Cegarman document code? If it's not intuitive, you're in the wrong field :D